From adam@nostrum.com Mon Feb 1 08:57:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3B33A695A; Mon, 1 Feb 2010 08:57:14 -0800 (PST) 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=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96a5YAN0T5uw; Mon, 1 Feb 2010 08:57:13 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 626113A67B4; Mon, 1 Feb 2010 08:57:12 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o11Gvj8R028218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 10:57:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B670809.2010903@nostrum.com> Date: Mon, 01 Feb 2010 10:57:45 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: IETF Dispatch Content-Type: multipart/alternative; boundary="------------000502060803010708050500" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: RAI Subject: [dispatch] draft-mdolly-dispatch-oma-push X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: IETF Dispatch List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 16:57:14 -0000 This is a multi-part message in MIME format. --------------000502060803010708050500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The area directors for RAI asked me to review draft-mdolly-dispatch-oma-push, specifically as they relate to the ongoing revisions to RFCs 3265 and 3427. While there are some relatively minor issues with some of the 3265 concepts used in this document, there is an overarching structural issue that needs to be addressed. By my reading, what this document seeks to do is open a door for OMA to create new event packages without requiring any IETF review (and, even if such is not the intent, it would certainly be the outcome). This is achieved by using an event package type of "oma-push," and then using a new "Event" header field parameter of "event-app-id" to indicate the actual event package. In the language of object-oriented programming, this draft seeks to define an event package that is little more than a façade to wrap RFC 3265, with the only substantive difference being whether IETF review is required. The nature of this proposed "event package" as a framework (as opposed to an actual event package as RFC 3265 defines that term) is revealed substantially by the contents of two of its sections: section 10 and section 12. In section 10, the draft tacitly indicates that it is to be applied to a broad range of events: The durations of push event subscriptions, and in general the conditions under which they are terminated, vary widely with the nature of the applications as they are assumed to be application- specific criteria. Even more tellingly, section 12 simply indicates that the notification bodies can be carried either inline or via indirection, and gives no actual definition of body type or of body syntax. By contrast, consider the body of published event packages: * RFC4575 defines a new application/conference-info+xml for NOTIFY * RFC5362 defines a new application/resource-lists+xml for NOTIFY * RFC4235 defines a new application/dialog-info+xml for NOTIFY * RFC4730 defined a new application/kpml-request+xml for NOTIFY * RFC3842 defines a new appcliation/simple-message-summary for NOTIFY * RFC4354 defines a new application/poc-settings+xml for NOTIFY * RFC3856 uses application/pidf+xml (which was designed for this purpose) for NOTIFY * RFC3680 defines a new application/reginfo+xml for NOTIFY * RFC3515 uses message/sipfrag to convey the state of the indicated resource in a NOTIFY * RFC3910 defines a new application/spirits-event+xml for NOTIFY * RFC3857 defines a new application/watcherinfo+xml for NOTIFY A legitimate event package would indicate specifically and completely what state is to be conveyed. It will also define or normatively reference a formally-defined syntax for conveying the state. The fact that the draft cannot provide such a description of state and a syntax for conveying the state is a good indication that it is not an event package, but actually an attempt to wrap RFC3265 in a parallel framework. If the overall mechanism proposed by the current document is approved as an IETF-sanctioned event package, the net result will be a loophole that effectively eliminates section 4.1 of rfc3427bis entirely. By my reading of subject matter covered by this document -- and with the caveat that I am not familiar with any of the OMA applications that the mechanism is intended to enable -- the only path forward that both achieves the goals stated in this document's problem statement and conforms to the restrictions put forth in RFC 3427 (and its draft successor) is to define each of the applications as a new event package. Unless I misunderstand the mechanism defined in OMA-TS-SIP_PUSH, there appear to be approximately 23 such applications presently defined [1]. For the sake of expediency, it may be sensible to have a single document that defines the RFC3265 event packages for all of them -- that is, a single draft with 23 distinct copies of the sections required by section 4.4 of RFC3265. /a [1] A (partial?) list of defined applications appears to be published here: http://www.wapforum.org/wina/push-app-id.htm --------------000502060803010708050500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The area directors for RAI asked me to review draft-mdolly-dispatch-oma-push, specifically as they relate to the ongoing revisions to RFCs 3265 and 3427.

While there are some relatively minor issues with some of the 3265 concepts used in this document, there is an overarching structural issue that needs to be addressed.

By my reading, what this document seeks to do is open a door for OMA to create new event packages without requiring any IETF review (and, even if such is not the intent, it would certainly be the outcome). This is achieved by using an event package type of "oma-push," and then using a new "Event" header field parameter of "event-app-id" to indicate the actual event package. In the language of object-oriented programming, this draft seeks to define an event package that is little more than a façade to wrap RFC 3265, with the only substantive difference being whether IETF review is required.

The nature of this proposed "event package" as a framework (as opposed to an actual event package as RFC 3265 defines that term) is revealed substantially by the contents of two of its sections: section 10 and section 12. In section 10, the draft tacitly indicates that it is to be applied to a broad range of events:

   The durations of push event subscriptions, and in general the
   conditions under which they are terminated, vary widely with the
   nature of the applications as they are assumed to be application-
   specific criteria.

Even more tellingly, section 12 simply indicates that the notification bodies can be carried either inline or via indirection, and gives no actual definition of body type or of body syntax. By contrast, consider the body of published event packages:
  • RFC4575 defines a new application/conference-info+xml for NOTIFY
  • RFC5362 defines a new application/resource-lists+xml for NOTIFY
  • RFC4235 defines a new application/dialog-info+xml for NOTIFY
  • RFC4730 defined a new application/kpml-request+xml for NOTIFY
  • RFC3842 defines a new appcliation/simple-message-summary for NOTIFY
  • RFC4354 defines a new application/poc-settings+xml for NOTIFY
  • RFC3856 uses application/pidf+xml (which was designed for this purpose) for NOTIFY
  • RFC3680 defines a new application/reginfo+xml for NOTIFY
  • RFC3515 uses message/sipfrag to convey the state of the indicated resource in a NOTIFY
  • RFC3910 defines a new application/spirits-event+xml for NOTIFY
  • RFC3857 defines a new application/watcherinfo+xml for NOTIFY

A legitimate event package would indicate specifically and completely what state is to be conveyed. It will also define or normatively reference a formally-defined syntax for conveying the state. The fact that the draft cannot provide such a description of state and a syntax for conveying the state is a good indication that it is not an event package, but actually an attempt to wrap RFC3265 in a parallel framework.

If the overall mechanism proposed by the current document is approved as an IETF-sanctioned event package, the net result will be a loophole that effectively eliminates section 4.1 of rfc3427bis entirely.

By my reading of subject matter covered by this document -- and with the caveat that I am not familiar with any of the OMA applications that the mechanism is intended to enable -- the only path forward that both achieves the goals stated in this document's problem statement and conforms to the restrictions put forth in RFC 3427 (and its draft successor) is to define each of the applications as a new event package. Unless I misunderstand the mechanism defined in OMA-TS-SIP_PUSH, there appear to be approximately 23 such applications presently defined [1]. For the sake of expediency, it may be sensible to have a single document that defines the RFC3265 event packages for all of them -- that is, a single draft with 23 distinct copies of the sections required by section 4.4 of RFC3265.

/a

[1] A (partial?) list of defined applications appears to be published here: http://www.wapforum.org/wina/push-app-id.htm --------------000502060803010708050500-- From Henry.Lum@alcatel-lucent.com Mon Feb 1 09:33:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7807C3A67B4 for ; Mon, 1 Feb 2010 09:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z0okg3x6CGO for ; Mon, 1 Feb 2010 09:33:33 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 42CD828C17C for ; Mon, 1 Feb 2010 09:33:33 -0800 (PST) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id o11HY0G0008598; Mon, 1 Feb 2010 11:34:00 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o11HXxPm019247; Mon, 1 Feb 2010 11:34:00 -0600 (CST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id o11HXw6f028287; Mon, 1 Feb 2010 09:33:58 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 09:33:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA364.BC8E5C32" Date: Mon, 1 Feb 2010 09:33:57 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF740537930D@NAHALD.us.int.genesyslab.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAEEoz2A= References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> From: "Henry Lum" To: "Leon Portman" , X-OriginalArrivalTime: 01 Feb 2010 17:33:59.0129 (UTC) FILETIME=[BCB18C90:01CAA364] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 Cc: Dave Smith , krehor@cisco.com Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 17:33:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA364.BC8E5C32 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Leon, =20 Thanks for the quick response, I have a few more follow ups marked [hlum] below. =20 Regards, Henry=20 =20 From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Sunday, January 31, 2010 6:03 AM To: Henry Lum; dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-00 =20 Hi, Henry. =20 I will try to answer some of the questions. Please see below. =20 Leon =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Lum Sent: Sunday, January 31, 2010 6:11 AM To: dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 =20 Hi Ken, =20 I have a bunch of questions and comments on the requirements for SRP requirements. =20 - Section 3 - Recording Client - If the SRP requirement does not mandate to use SIP as the actual recording protocol, why does the recording client have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual call to be recorded) that can be not SIP based and Recording Session (part of SRP) that is used for triggering recording and it is SIP based. So both RC and RS are SIP UA. [[hlum]] I now understand that the recorded session does not have to be SIP based, but the wording in the definition of SRP itself mentions that it may be SIP; then why does RC and RS have to be a SIP UA if SRP does not have to be SIP? - Section 3 - Recorded session - Is a recorded session has to be a SIP session? [LeonP] No, my comment above - Section 3 - Persistent Recording - does recorded session exist in this context since it seems like the recording session is persistent from the endpoint perspective. [LeonP] No, recorded session are not required to be existing during initiation of persistent session. Persistent recording session can be initiated on agent logon for example. - Section 4 - use case 5 - if the recording can include recording for an IVR application (ie. VoiceXML application), does that mean the call metadata must include application contexts as well? [LeonP] Yes, like specific script or input results [[hlum]] I assume what kind of call metadata and how it is delivered is outside of the scope of this document? - Section 4, use case 7 - the first sentence has a strange word "&mdash". This use case somehow implies certain architectural design for a PBX with regards to media forking. Is that necessary from a requirement perspective? [LeonP] XML convert mistake. We don't want assume any specific configurations. - Section 4, use case 8 - shall we use a more general terminology such as multi-party call? Depending on the situation, the supervisor may be conferenced with the agent and customer so the recording session needs to define how a multi-party session should be recorded. [LeonP] Yes, probably we want to use more generic term then Complex Call - Section 4, use case 11, does a recorder "must" support some sort of media processing such as real-time analytics? This is more of a business application on the recording server side, which is independent of the session recording protocol itself. [LeonP] The main point there was that Recording Protocol must support real time streaming for real time analytics - Section 6: o REQ-001 - what does full-time Recording session mean? [LeonP] Record all calls o REQ-003 - it's unclear what is the target of the recording session here since this not directly related to a single recorded session (perhaps many) [LeonP] To minimize media clipping associated with recording initiation [[hlum]] You actually answered my question above about what a persistent recording mean and why it's useful, but what is unclear to me that is whether there is something called a persistent recording session that targets something like an agent device. o REQ-006 - I mentioned above that IVR sessions may contain additional IVR application metadata; should this requirement clarify that the mechanism should include application metadata? [LeonP] Yes, we should o REQ-007 - this wording of the requirement to me is pointing towards a specific implementation of high-availability or fault-tolerance of a recording session. o REQ-009 - the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party session where there are multiple media streams from multiple recorded sessions, and the media streams may be mixed by a conference mixer? [LeonP] It is more for trading floor environments where multiple concurrent calls on the same device (turret) recorded together. It is not related to summation for conference participants at the same call. [[hlum]] I'm not familiar with trading floor environments so I may not understand the intent here. If you have multiple concurrent calls then wouldn't you have multiple recording sessions to describe each call individually? Does the endpoint device perform mixing function for multiple calls so that's why you need to club them together in a single recording session? o REQ-013 - this is only one way of notifying the customer that the call is being recorded but there are others. I think this requires a bit more explanation of why this is needed. To me this looks like a duplicate of REQ-022 o REQ-015 - what does non-repudiation mean in this context? Isn't this the same as REQ-017? [LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session o REQ-021 - what happens with SRTP if recording client simply forks the media? The recording server would not be able to decrypt the media unless it gets the private keys from the recorded session. [LeonP] It is out of scope of this document.=20 o REQ-028 - the wording redirected looks out of context here; the requirement only applies when recording client initiates a recording session to an available recorder server? [LeonP] We want to support both directions [[hlum]] Okay, then I think we should re-word to mention something about availability in general. (eg. "A request for a new recording session must reach an available recording client or server"). o REQ-029/030 - They look very generic and I don't think these should be requirements for SRP, but rather a product requirement on how OA&M works for the recording client/server. =20 Thanks Henry =20 =20 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. =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CAA364.BC8E5C32 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Leon,

 <= /p>

Thanks for the quick resp= onse, I have a few more follow ups marked [hlum] below.

 <= /p>

Regards,

Henry <= /p>

 <= /p>

From: Leon Portma= n [mailto:Leon.Portman@nice.com]
Sent: Sunday, January 31, 2010 6:03 AM
To: Henry Lum; dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: RE: Comments on draft-rehor-dispatch-session-recording-re= q-00

 

Hi, Henry.

 

I will try to answer some of the questions. Please see below.

 

Leon

 

From: dispatch-bo= unces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Lum
Sent: Sunday, January 31, 2010 6:11 AM
To: dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

 

Hi Ken,

 

I have a bunch of questions and comments on the requ= irements for SRP requirements.

 

-&= nbsp;         Section 3 – Recording Client – If the= SRP requirement does not mandate to use SIP as the actual recording protocol,= why does the recording client have to be a SIP user agent or B2BUA?

[LeonP] Actually there is a difference between Recorded se= ssion (the actual call to be recorded) that can be not SIP based and Recording Session (part of SRP) that is used for triggering recording and it is SIP= based. So both RC and RS are SIP UA.

[[hlum]] I now understand= that the recorded session does not have to be SIP based, but the wording in the de= finition of SRP itself mentions that it may be SIP; then why does RC and RS have t= o be a SIP UA if SRP does not have to be SIP?

-&= nbsp;         Section 3 - Recorded session – Is a recorde= d session has to be a SIP session?

[LeonP] No, my comment above

-&= nbsp;         Section 3 - Persistent Recording – does rec= orded session exist in this context since it seems like the recording session i= s persistent from the endpoint perspective.

[LeonP] No, recorded session are not required to be existi= ng during initiation of persistent session. Persistent recording session can= be initiated on agent logon for example.

-&= nbsp;         Section 4 – use case 5 – if the recor= ding can include recording for an IVR application (ie. VoiceXML application), = does that mean the call metadata must include application contexts as well?

[LeonP] Yes, like specific script or input results

[[hlum]] I assume what ki= nd of call metadata and how it is delivered is outside of the scope of this document= ?

-&= nbsp;         Section 4, use case 7 – the first sentence = has a strange word “&mdash”. This use case somehow implies cert= ain architectural design for a PBX with regards to media forking. Is that nec= essary from a requirement perspective?

[LeonP] XML convert mistake. We don’t want assume an= y specific configurations.

-&= nbsp;         Section 4, use case 8 – shall we use a more= general terminology such as multi-party call? Depending on the situation,= the supervisor may be conferenced with the agent and customer so the recordin= g session needs to define how a multi-party session should be recorded.

[LeonP] Yes, probably we want to use more generic term the= n Complex Call

-&= nbsp;         Section 4, use case 11, does a recorder “must” support some sort of media processing such as real-tim= e analytics? This is more of a business application on the recording server= side, which is independent of the session recording protocol itself.=

[LeonP] The main point there was that Recording Protocol m= ust support real time streaming for real time analytics

-&= nbsp;         Section 6:

o&= nbsp;  REQ-001 – what does full-time Record= ing session mean?

[LeonP] Record all calls

o&= nbsp;  REQ-003 – it’s unclear what is= the target of the recording session here since this not directly related to a= single recorded session (perhaps many)

[LeonP] To minimize media clipping associated with recordi= ng initiation

[[hlum]] You actually ans= wered my question above about what a persistent recording mean and why it’s = useful, but what is unclear to me that is whether there is something called a per= sistent recording session that targets something like an agent device.=

o&= nbsp;  REQ-006 – I mentioned above that IVR= sessions may contain additional IVR application metadata; should this requirement clarify that the mechanism should include application metadata?

[LeonP] Yes, we should

o&= nbsp;  REQ-007 – this wording of the requir= ement to me is pointing towards a specific implementation of high-availability = or fault-tolerance of a recording session.

o&= nbsp;  REQ-009 – the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party s= ession where there are multiple media streams from multiple recorded sessions, a= nd the media streams may be mixed by a conference mixer?

[LeonP]  = It is more for trading floor environments where m= ultiple concurrent calls on the same device (turret) recorded together. It is not= related to summation for conference participants at the same call.=

[[hlum]] I’m not fa= miliar with trading floor environments so I may not understand the intent here. = If you have multiple concurrent calls then wouldn’t you have multiple reco= rding sessions to describe each call individually? Does the endpoint device per= form mixing function for multiple calls so that’s why you need to club t= hem together in a single recording session?

o&= nbsp;  REQ-013 – this is only one way of notifying the customer that the call is being recorded but there are othe= rs. I think this requires a bit more explanation of why this is needed. To me t= his looks like a duplicate of REQ-022

o&= nbsp;  REQ-015 – what does non-repudiation = mean in this context? Isn’t this the same as REQ-017?

[LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session=

o&= nbsp;  REQ-021 – what happens with SRTP if recording client simply forks the media? The recording server would not b= e able to decrypt the media unless it gets the private keys from the recorded se= ssion.

[LeonP] It is out of scope of this document.

o&= nbsp;  REQ-028 – the wording redirected loo= ks out of context here; the requirement only applies when recording client initi= ates a recording session to an available recorder server?

[LeonP] We want to support both directions

[[hlum]] Okay, then I thi= nk we should re-word to mention something about availability in general.  = (eg. “A request for a new recording session must reach an available recording cli= ent or server”).

o&= nbsp;  REQ-029/030 – They look very generic= and I don’t think these should be requirements for SRP, but rather a prod= uct requirement on how OA&M works for the recording client/server.

 

Thanks

Henry

 

 


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 informat= ion 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 m= edium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent an= d/or its affiliated entities.

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CAA364.BC8E5C32-- From rajnish.jain@ipc.com Mon Feb 1 15:28:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2AC28C0E2 for ; Mon, 1 Feb 2010 15:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26WhkpR8NRCW for ; Mon, 1 Feb 2010 15:27:59 -0800 (PST) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id DEE303A67B0 for ; Mon, 1 Feb 2010 15:27:58 -0800 (PST) Received: from unknown [65.244.37.52] (EHLO p01c12o144.mxlogic.net) by p01c12o144.mxlogic.net(mxl_mta-6.5.0-0) with ESMTP id 3a3676b4.e0bd3b90.7286.00-435.15103.p01c12o144.mxlogic.net (envelope-from ); Mon, 01 Feb 2010 16:28:35 -0700 (MST) X-MXL-Hash: 4b6763a36da680a0-cf4c63b40e72a468d0adc61fcc6d9bbe64b429a4 Received: from unknown [65.244.37.52] (EHLO smtp.ipc.com) by p01c12o144.mxlogic.net(mxl_mta-6.5.0-0) over TLS secured channel with ESMTP id 893676b4.0.7256.00-017.15022.p01c12o144.mxlogic.net (envelope-from ); Mon, 01 Feb 2010 16:28:25 -0700 (MST) X-MXL-Hash: 4b6763995dc69f9f-a543dfa86c859a1521dcc663d30b8cf77b0ba8f2 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.247]) by STSNYHTCAS2.corp.root.ipc.com ([10.201.40.93]) with mapi; Mon, 1 Feb 2010 18:28:24 -0500 From: "Jain, Rajnish" To: Henry Lum , Leon Portman , "dispatch@ietf.org" Date: Mon, 1 Feb 2010 18:28:23 -0500 Thread-Topic: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAEEoz2AADJZSAA== Message-ID: References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF740537930D@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF740537930D@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.000.1038-17166.004 x-tm-as-result: No--44.350700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_A549831415082442872141F4C99FE71301EDBD83B5STSNYCMS1corp_" MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=1.0 c=1 a=D4USGbs0y0J827gn68Ljfg==:17 a=YaNrmYCDIRQQ5aBO] X-AnalysisOut: [hv0A:9 a=fYfflSzehF2s_ftVPQYA:7 a=dH1wM39KedHncjgCkyWSrc4P] X-AnalysisOut: [acQA:4 a=FxFG08TSq6iBR-vJ:21 a=iQhSTAmYVLEwaaef:21 a=SSmOF] X-AnalysisOut: [EACAAAA:8 a=Y2VNeNrzAAAA:8 a=yMhMjlubAAAA:8 a=TW66zc2HAAAA] X-AnalysisOut: [:8 a=HQ31llbKAAAA:8 a=kXWNrtZfjuhznu8zXy0A:9 a=2Eke7qhGUuK] X-AnalysisOut: [4tKUtKUcA:7 a=k9wkqTeKkzDC3xIlzBcFmflx3dcA:4] Cc: Dave Smith , "krehor@cisco.com" Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 23:28:08 -0000 --_000_A549831415082442872141F4C99FE71301EDBD83B5STSNYCMS1corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Henry, Thanks for your comments. Inline: - Section 3 - Recording Client - If the SRP requirement does not man= date to use SIP as the actual recording protocol, why does the recording cl= ient have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual= call to be recorded) that can be not SIP based and Recording Session (part= of SRP) that is used for triggering recording and it is SIP based. So both= RC and RS are SIP UA. [[hlum]] I now understand that the recorded session does not have to be SIP= based, but the wording in the definition of SRP itself mentions that it ma= y be SIP; then why does RC and RS have to be a SIP UA if SRP does not have = to be SIP? [rj] The SRP, which manages how the recording media gets delivered to the r= ecorders, is based on SIP (SRP is a set of extensions to the SIP core proto= col). The sessions that SRP manages are called "Recording Sessions" and the= y are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The s= essions that get actually recorded (e.g. communication between a call cente= r agent and an external caller) may or may not be SIP (this depends on the = kind of the PBX phone the agent). - Section 4 - use case 5 - if the recording can include recording fo= r an IVR application (ie. VoiceXML application), does that mean the call me= tadata must include application contexts as well? [LeonP] Yes, like specific script or input results [[hlum]] I assume what kind of call metadata and how it is delivered is out= side of the scope of this document? [rj] Correct. o REQ-003 - it's unclear what is the target of the recording session here= since this not directly related to a single recorded session (perhaps many= ) [LeonP] To minimize media clipping associated with recording initiation [[hlum]] You actually answered my question above about what a persistent re= cording mean and why it's useful, but what is unclear to me that is whether= there is something called a persistent recording session that targets some= thing like an agent device. [rj] I guess, Persistent Recording is a bit confusing term (we've received = other feedback on this as well). If I can use the term always-on recording = from the wing-srtp draft then these sessions get established when the agent= logs on and torn off when the agent logs off. Codecs such as G.729 and G.7= 11 with VAD are used to ensure that silence is not recorded (for instance, = when the agent isn't on a call). o REQ-009 - the wording here is a bit unclear here. Do you mean the recor= ded session represents a multi-party session where there are multiple media= streams from multiple recorded sessions, and the media streams may be mixe= d by a conference mixer? [LeonP] It is more for trading floor environments where multiple concurren= t calls on the same device (turret) recorded together. It is not related to= summation for conference participants at the same call. [[hlum]] I'm not familiar with trading floor environments so I may not unde= rstand the intent here. If you have multiple concurrent calls then wouldn't= you have multiple recording sessions to describe each call individually? D= oes the endpoint device perform mixing function for multiple calls so that'= s why you need to club them together in a single recording session? [rj] Due to bandwidth and other cost burdens, the customer demand is that y= ou mix multiple _recorded sessions_ in a single _recording session_. o REQ-028 - the wording redirected looks out of context here; the require= ment only applies when recording client initiates a recording session to an= available recorder server? [LeonP] We want to support both directions [[hlum]] Okay, then I think we should re-word to mention something about av= ailability in general. (eg. "A request for a new recording session must re= ach an available recording client or server"). [rj] The example test you quoted doesn't reflect the actual intent here. Th= e reason for supporting both directions is dependent on where the policy to= record or not resides - RC or RS. The INVITE always comes from either of t= hese two places. Thanks, Raj Jain ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. --_000_A549831415082442872141F4C99FE71301EDBD83B5STSNYCMS1corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Henry,

 

Thanks for your commen= ts. Inline:

 

-     &= nbsp;  Section 3 – Recording Client – If the S= RP requirement does not mandate to use SIP as the actual recording protocol= , why does the recording client have to be a SIP user agent or B2BUA?<= /o:p>

[LeonP] Actually there is a difference between= Recorded session (the actual call to be recorded) that can be not SIP base= d and Recording Session (part of SRP) that is used for triggering recording= and it is SIP based. So both RC and RS are SIP UA.

[[hlum]] I now understand= that the recorded session does not have to be SIP based, but the wording i= n the definition of SRP itself mentions that it may be SIP; then why does R= C and RS have to be a SIP UA if SRP does not have to be SIP?

 

[rj] The SRP, which ma= nages how the recording media gets delivered to the recorders, is based on = SIP (SRP is a set of extensions to the SIP core protocol). The sessions tha= t SRP manages are called “Recording Sessions” and they are SIP sessions. Therefore, RC and RS are, by de= finition, SIP UAs. The sessions that get actually recorded (e.g. communicat= ion between a call center agent and an external caller) may or may not be S= IP (this depends on the kind of the PBX phone the agent).

 

 

-     &= nbsp;  Section 4 – use case 5 – if the recordi= ng can include recording for an IVR application (ie. VoiceXML application),= does that mean the call metadata must include application contexts as well= ?

[LeonP] Yes, like specific script or input res= ults

[[hlum]] I assume what ki= nd of call metadata and how it is delivered is outside of the scope of this= document?

 

[rj] Correct.

 

o   REQ-003 – it’s unclear what is t= he target of the recording session here since this not directly related to = a single recorded session (perhaps many)

[LeonP] To minimize media clipping associated = with recording initiation

[[hlum]] You actually ans= wered my question above about what a persistent recording mean and why it&#= 8217;s useful, but what is unclear to me that is whether there is something= called a persistent recording session that targets something like an agent device.

 

[rj] I guess, Persiste= nt Recording is a bit confusing term (we’ve received other feedback o= n this as well). If I can use the term always-on recording from the wing-sr= tp draft then these sessions get established when the agent logs on and torn off when the agent logs off. Codecs such a= s G.729 and G.711 with VAD are used to ensure that silence is not recorded = (for instance, when the agent isn’t on a call).

 

o   REQ-009 – the wording here is a bit un= clear here. Do you mean the recorded session represents a multi-party sessi= on where there are multiple media streams from multiple recorded sessions, = and the media streams may be mixed by a conference mixer?

[LeonP]  It is more for trading floor environments where multiple= concurrent calls on the same device (turret) recorded together. It is not = related to summation for conference participants at the same call.

[[hlum]] I’m not fa= miliar with trading floor environments so I may not understand the intent h= ere. If you have multiple concurrent calls then wouldn’t you have mul= tiple recording sessions to describe each call individually? Does the endpoint device perform mixing function for multiple calls so tha= t’s why you need to club them together in a single recording session?=

 

[rj] Due to bandwidth = and other cost burdens, the customer demand is that you mix multiple _re= corded sessions_ in a single _recording session_.

 

 

o   REQ-028 – the wording redirected looks= out of context here; the requirement only applies when recording client in= itiates a recording session to an available recorder server?

[LeonP] We want to support both directions

[[hlum]] Okay, then I thi= nk we should re-word to mention something about availability in general.&nb= sp; (eg. “A request for a new recording session must reach an availab= le recording client or server”).

 

[rj] The example test = you quoted doesn’t reflect the actual intent here. The reason for sup= porting both directions is dependent on where the policy to record or not r= esides – RC or RS. The INVITE always comes from either of these two places.

 

Thanks,

Raj Jain

 


DISCLAIMER: This e-mail may = contain information that is confidential, privileged or otherwise protected= from disclosure. If you are not an intended recipient of this e-mail, do n= ot duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you= have received it in error. Unintended recipients are prohibited from takin= g action on the basis of information in this e-mail.E-mail messages may con= tain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, = deleted or interfered with without the knowledge of the sender or the inten= ded recipient. If you are not comfortable with the risks associated with e-= mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the exte= nt and under circumstances permitted by applicable law, to retain, monitor = and intercept e-mail messages to and from its systems.
 --_000_A549831415082442872141F4C99FE71301EDBD83B5STSNYCMS1corp_-- From Leon.Portman@nice.com Mon Feb 1 23:40:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580593A6AB9 for ; Mon, 1 Feb 2010 23:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnwNJEUg-9dU for ; Mon, 1 Feb 2010 23:40:00 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 4225D3A6AB8 for ; Mon, 1 Feb 2010 23:39:58 -0800 (PST) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 2 Feb 2010 09:40:33 +0200 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 2 Feb 2010 09:40:33 +0200 From: Leon Portman To: Dave Smith , "dispatch@ietf.org" Date: Tue, 2 Feb 2010 09:40:33 +0200 Thread-Topic: Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAB1sHaAAQe/7AA== Message-ID: <07465C1D981ABC41A344374066AE1A2C37DA9FAF28@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C37DA9FAF28TLVMBX01nicec_" MIME-Version: 1.0 Cc: Henry Lum , "krehor@cisco.com" Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 07:40:13 -0000 --_000_07465C1D981ABC41A344374066AE1A2C37DA9FAF28TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, Hi Thank you very much for the comments. Please see below. We can also discuss it on our call today. Leon From: Dave Smith [mailto:Dave.Smith@genesyslab.com] Sent: Tuesday, February 02, 2010 7:03 AM To: dispatch@ietf.org Cc: krehor@cisco.com; Leon Portman; Henry Lum Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-00 Hi Leon, Henry, I put together some inputs on top of yours for consideration as well....pls= see my inputs below. Regards, Dave From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Sunday, January 31, 2010 3:03 AM To: Henry Lum; dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-00 Hi, Henry. I will try to answer some of the questions. Please see below. Leon From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Henry Lum Sent: Sunday, January 31, 2010 6:11 AM To: dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-= 00 Hi Ken, I have a bunch of questions and comments on the requirements for SRP requir= ements. - Section 3 - Recording Client - If the SRP requirement does not m= andate to use SIP as the actual recording protocol, why does the recording = client have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual= call to be recorded[DS] Is this just the voice - the RTP stream (the repl= icated voice stream that is sent to a Logger)? ) that can be not SIP based= and Recording Session (part of SRP) that is used for triggering recording = and it is SIP based[DS] Is this the control messaging...for starting/stoppi= ng/pause/resume...the messaging (SIP) for set up of the replicated voice st= ream/RTP transfer? . So both RC and RS are SIP UA. [LeonP] Yes, SRP is the control session for replicated media stream (any RT= P type of media) - Section 3 - Recorded session - Is a recorded session has to be a= SIP session? [LeonP] No, my comment above[DS] I recommend better Terms and/or better def= initions of the Terms "Recorded Session" and "Recording Session"in the Draf= t - is it possible to change one or both terms since they sound so similar.= That is, the IETF Draft definitions are not clear to me...and the differe= nce between these is not clear (for example, do not use the terms themselve= s in the definitions...provide examples. Recommend also to differentiate t= hese from the Metadata messaging (if they are or could be different), and t= o define that as well (as rec'd by Martin). [LeonP] Let's talk about it - Section 3 - Persistent Recording - does recorded session exist i= n this context since it seems like the recording session is persistent from= the endpoint perspective. [LeonP] No, recorded session are not required to be existing during initiat= ion of persistent session. Persistent recording session can be initiated on= agent logon for example. - Section 4 - use case 5 - if the recording can include recording = for an IVR application (ie. VoiceXML application), does that mean the call = metadata must include application contexts as well? [LeonP] Yes, like specific script or input results - Section 4, use case 7 - the first sentence has a strange word "&= mdash". This use case somehow implies certain architectural design for a PB= X with regards to media forking. Is that necessary from a requirement persp= ective? [LeonP] XML convert mistake. We don't want assume any specific configuratio= ns. - Section 4, use case 8 - shall we use a more general terminology = such as multi-party call? Depending on the situation, the supervisor may be= conferenced with the agent and customer so the recording session needs to = define how a multi-party session should be recorded. [LeonP] Yes, probably we want to use more generic term then Complex Call[DS= ] The term "Multi-Party Call" seems to imply a call/interaction with more t= han two users...that is, a conference. Recommend to keep "Complex Calls" t= erminology but define several different cases/examples - for example, Confe= rences (Henry's example), Consults (as in use case 8), also could include a= Whisper Agent/Coaching example, Barge-In example, other... Alternatively,= change Use Case 8 to "Consult Call" and add additional use cases for these= other complex call examples. - Section 4, use case 11, does a recorder "must" support some sort= of media processing such as real-time analytics? This is more of a busines= s application on the recording server side, which is independent of the ses= sion recording protocol itself. [LeonP] The main point there was that Recording Protocol must support real = time streaming for real time analytics[DS] This Use Case reads like a requ= irement and should read more like an example of how it is used. Is the ability to support "real-time" analytics dependent on the recording = protocol? Is there also a need separate streams for the two channels (what= the agent said, what the agent heard) - And do we already have a req't for= that.....i.e., req't 10 and/or req't 11? - Section 6: o REQ-001 - what does full-time Recording session mean? [LeonP] Record all calls[DS] Recommend we explain that in the req't; also, = is that by DN, or by Agent, or by Customer, other, or all of the above...? [LeonP] Yes, the requirement is to initiate recording session not by call i= d but by some fixed identifier as above o REQ-003 - it's unclear what is the target of the recording session here= since this not directly related to a single recorded session (perhaps many= ) [LeonP] To minimize media clipping associated with recording initiation o REQ-006 - I mentioned above that IVR sessions may contain additional IV= R application metadata; should this requirement clarify that the mechanism = should include application metadata? [LeonP] Yes, we should o REQ-007 - this wording of the requirement to me is pointing towards a s= pecific implementation of high-availability or fault-tolerance of a recordi= ng session. o REQ-009 - the wording here is a bit unclear here. Do you mean the recor= ded session represents a multi-party session where there are multiple media= streams from multiple recorded sessions, and the media streams may be mixe= d by a conference mixer? [LeonP] It is more for trading floor environments where multiple concurren= t calls on the same device (turret) recorded together. It is not related to= summation for conference participants at the same call. [DS] Recommend= to state this info in the req'ts and provide this example. o REQ-013 - this is only one way of notifying the customer that the call = is being recorded but there are others. I think this requires a bit more ex= planation of why this is needed. To me this looks like a duplicate of REQ-0= 22 [DS] Recommend to change this req't from "Must" to "May" o REQ-015 - what does non-repudiation mean in this context? Isn't this th= e same as REQ-017? [LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session = [DS] Recommend to define "non-repudiation" and/or provide an example to avo= id any confusion. o REQ-017 - [DS] Why is non-repudiation of both the SRP and the Media ne= eded? o Req - 022 - [DS] Recommend to add "This MAY be performed by injecting= tones into the Recorded Session either from the RS or from the RC." (but = could also be done by informing via speech script upon first answering call= ) o REQ-021 - what happens with SRTP if recording client simply forks the m= edia? The recording server would not be able to decrypt the media unless it= gets the private keys from the recorded session. [LeonP] It is out of scope of this document. o REQ-028 - the wording redirected looks out of context here; the require= ment only applies when recording client initiates a recording session to an= available recorder server? [LeonP] We want to support both directions o REQ-029/030 - They look very generic and I don't think these should be = requirements for SRP, but rather a product requirement on how OA&M works fo= r the recording client/server. Thanks Henry CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. --_000_07465C1D981ABC41A344374066AE1A2C37DA9FAF28TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave, Hi

 

Thank you very much for the comments.

 

Please see below.

 

We can also discuss it on our call today.

 

Leon

From: Dave Smith [mailto:Dave.Smith@genesyslab.com]
Sent: Tuesday, February 02, 2010 7:03 AM
To: dispatch@ietf.org
Cc: krehor@cisco.com; Leon Portman; Henry Lum
Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-= 00

 

Hi Leon, Henry,

I put together some inputs on top of yours for consideration as well….p= ls see my inputs below.

 

Regards,

Dave

 

From: Leon Portman = [mailto:Leon.Portman@nice.com]
Sent: Sunday, January 31, 2010 3:03 AM
To: Henry Lum; dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-= 00

 

Hi, Henry.

 

I will try to answer some of the questions. Please see below.

 

Leon

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O= f Henry Lum
Sent: Sunday, January 31, 2010 6:11 AM
To: dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: [dispatch] Comments on draft-rehor-dispatch-session-recordi= ng-req-00

 

Hi Ken,

 

I have a bunch of questions and comments on the requir= ements for SRP requirements.

 

-&nb= sp;         Section 3 – Recording = Client – If the SRP requirement does not mandate to use SIP as the actual recording protocol, why does the recording client have to be a SIP user age= nt or B2BUA?

[LeonP] Actually there is a difference between Recorded sess= ion (the actual call to be recorded[DS]  Is this just the voice - the= RTP stream (the replicated voice stream that is sent to a Logger)?  ) that can be not = SIP based and Recording Session (part of SRP) that is used for triggering recor= ding and it is SIP based[DS] Is this the control messaging…for starting/stopping/pause/resume…the messaging (SIP) for set up of the replicated voice stream/RTP transfer? . So both RC and R= S are SIP UA. 

[LeonP] Yes, SRP is the control session for replicated media stream (any RTP type of media)

-&nb= sp;         Section 3 - Recorded session – Is a recorded session has to be a SIP session?

[LeonP] No, my comment above[DS] I recommend b= etter Terms and/or better definitions of the Terms “Recorded Session” and “Recording Session”in the Draft ̵= 1; is it possible to change one or both terms since they sound so similar.&nbs= p; That is, the IETF Draft definitions are not clear to me…and the difference between these is not clear (for example, do not use the terms themselves in the definitions…provide examples.  Recommend also = to differentiate these from the Metadata messaging (if they are or could be different), and to define that as well (as rec’d by Martin).  =

[LeonP] Let’s talk about it=

-&nb= sp;         Section 3 - Persistent Recor= ding – does recorded session exist in this context since it seems like the recording session is persistent from the endpoint perspective.

[LeonP] No, recorded session are not required to be existing during initiation of persistent session. Persistent recording session can b= e initiated on agent logon for example.

-&nb= sp;         Section 4 – use case 5 – if the recording can include recording for an IVR application (ie. VoiceXML application), does that mean the call metadata must include application contexts as well?

[LeonP] Yes, like specific script or input results=

-&nb= sp;         Section 4, use case 7 –= ; the first sentence has a strange word “&mdash”. This use case somehow implies certain architectural design for a PBX with regards to medi= a forking. Is that necessary from a requirement perspective?

[LeonP] XML convert mistake. We don’t want assume any specific configurations.

-&nb= sp;         Section 4, use case 8 –= ; shall we use a more general terminology such as multi-party call? Depending= on the situation, the supervisor may be conferenced with the agent and custome= r so the recording session needs to define how a multi-party session should be recorded.

[LeonP] Yes, probably we want to use more generic term then Complex Call[DS] The term “Multi-Party Call” seems to imply = a call/interaction with more than two users…that is, a conference. = ; Recommend to keep “Complex Calls” terminology but define severa= l different cases/examples – for example, Conferences (Henry’s example), Consults (as in use case 8), also could include a Whisper Agent/Coaching example, Barge-In example, other…  Alternatively, change Use Case 8 to “Consult Call” and add additional use case= s for these other complex call examples.  =

-&nb= sp;         Section 4, use case 11, does= a recorder “must” support some sort of media processing such as real-time analytics? This is more of a business application on the recordin= g server side, which is independent of the session recording protocol itself.=

[LeonP] The main point there was that Recording Protocol mus= t support real time streaming for real time analytics[DS]  This Us= e Case reads like a requirement and should read more like an example of how it is used. 

Is the ability to support “real-time” analytics dependent on the recording protocol?  Is there also a need separate streams for the two channels (what the agent said, what the agent heard) - = And do we already have a req’t for that…..i.e., req’t 10 and/= or req’t 11?

-&nb= sp;         Section 6:

o&nb= sp;  REQ-001 – what = does full-time Recording session mean?

[LeonP] Record all calls[DS] Recommend we explain that in the req’t; also, is that by DN, or by Agent, or by Customer, other, or all of the above…?   = =

[LeonP] Yes, the requirement is to initiate recording sessio= n not by call id but by some fixed identifier as above=

o&nb= sp;  REQ-003 – it= 217;s unclear what is the target of the recording session here since this not directly related to a single recorded session (perhaps many)

[LeonP] To minimize media clipping associated with recording initiation

o&nb= sp;  REQ-006 – I men= tioned above that IVR sessions may contain additional IVR application metadata; sh= ould this requirement clarify that the mechanism should include application metadata?

[LeonP] Yes, we should

o&nb= sp;  REQ-007 – this wording of the requirement to me is pointing towards a specific implementat= ion of high-availability or fault-tolerance of a recording session.<= /p>

o&nb= sp;  REQ-009 – the w= ording here is a bit unclear here. Do you mean the recorded session represents a multi-party session where there are multiple media streams from multiple recorded sessions, and the media streams may be mixed by a conference mixer= ?

[LeonP]  It is more for trading floor environments where mul= tiple concurrent calls on the same device (turret) recorded together. It is not related to summation for conference participants at the same call. &nb= sp;   [DS] Recommend to state this info in the req’ts and provide this example.

o&nb= sp;  REQ-013 – this = is only one way of notifying the customer that the call is being recorded but there are others. I think this requires a bit more explanation of why this = is needed. To me this looks like a duplicate of REQ-022    <= i>[DS] Recommend to = change this req’t from “Must” to “May”   

o&nb= sp;  REQ-015 – what = does non-repudiation mean in this context? Isn’t this the same as REQ-017?=

[LeonP] REQ-015 talk re= garding media and REQ-017 regarding SRP SIP Session [DS] Recommend to = define “non-repudiation” and/or provide an example to avoid any confusion. 

o&nb= sp;  REQ-017 – [DS]  Why is non-repudiation of both the SRP and the Media needed?

o   Req – 022  = ;- [DS]  Recomme= nd to add “This MAY be performed by in= jecting tones into the Recorded Session either from the RS or from the RC.”  (but could also be done by informing via speech script upon first answering call)  

o&nb= sp;  REQ-021 – what happens with SRTP if recording client simply forks the media? The recording server would not be able to decrypt the media unless it gets the private ke= ys from the recorded session.

[LeonP] It is out of scope of this document. = =

o&nb= sp;  REQ-028 – the w= ording redirected looks out of context here; the requirement only applies when recording client initiates a recording session to an available recorder ser= ver?

[LeonP] We want to support both directions=

o&nb= sp;  REQ-029/030 – T= hey look very generic and I don’t think these should be requirements for = SRP, but rather a product requirement on how OA&M works for the recording client/server.

 

Thanks

Henry

 

 


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. A= ny 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 origi= nal transmission and its attachments and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any med= ium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/= or its affiliated entities.

 

 


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. A= ny 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 origi= nal transmission and its attachments and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any med= ium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/= or its affiliated entities.

--_000_07465C1D981ABC41A344374066AE1A2C37DA9FAF28TLVMBX01nicec_-- From Dave.Smith@genesyslab.com Mon Feb 1 21:02:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD99628C1FB for ; Mon, 1 Feb 2010 21:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLW5kM7nvFDl for ; Mon, 1 Feb 2010 21:02:11 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by core3.amsl.com (Postfix) with ESMTP id AF38E3A6A55 for ; Mon, 1 Feb 2010 21:02:11 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id o1252lrC011826; Mon, 1 Feb 2010 21:02:47 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 21:02:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA3C4.F5C28681" Date: Mon, 1 Feb 2010 21:02:42 -0800 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAB1sHaA= References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> From: "Dave Smith" To: X-OriginalArrivalTime: 02 Feb 2010 05:02:47.0290 (UTC) FILETIME=[F63275A0:01CAA3C4] X-Mailman-Approved-At: Tue, 02 Feb 2010 06:13:26 -0800 Cc: Henry Lum , Leon Portman , krehor@cisco.com Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 05:07:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA3C4.F5C28681 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Leon, Henry, I put together some inputs on top of yours for consideration as well....pls see my inputs below. =20 Regards, Dave =20 From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Sunday, January 31, 2010 3:03 AM To: Henry Lum; dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-00 =20 Hi, Henry. =20 I will try to answer some of the questions. Please see below. =20 Leon =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Lum Sent: Sunday, January 31, 2010 6:11 AM To: dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00 =20 Hi Ken, =20 I have a bunch of questions and comments on the requirements for SRP requirements. =20 - Section 3 - Recording Client - If the SRP requirement does not mandate to use SIP as the actual recording protocol, why does the recording client have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual call to be recorded[DS] Is this just the voice - the RTP stream (the replicated voice stream that is sent to a Logger)? ) that can be not SIP based and Recording Session (part of SRP) that is used for triggering recording and it is SIP based[DS] Is this the control messaging...for starting/stopping/pause/resume...the messaging (SIP) for set up of the replicated voice stream/RTP transfer? . So both RC and RS are SIP UA. =20 - Section 3 - Recorded session - Is a recorded session has to be a SIP session? [LeonP] No, my comment above[DS] I recommend better Terms and/or better definitions of the Terms "Recorded Session" and "Recording Session"in the Draft - is it possible to change one or both terms since they sound so similar. That is, the IETF Draft definitions are not clear to me...and the difference between these is not clear (for example, do not use the terms themselves in the definitions...provide examples. Recommend also to differentiate these from the Metadata messaging (if they are or could be different), and to define that as well (as rec'd by Martin). =20 - Section 3 - Persistent Recording - does recorded session exist in this context since it seems like the recording session is persistent from the endpoint perspective. [LeonP] No, recorded session are not required to be existing during initiation of persistent session. Persistent recording session can be initiated on agent logon for example. - Section 4 - use case 5 - if the recording can include recording for an IVR application (ie. VoiceXML application), does that mean the call metadata must include application contexts as well? [LeonP] Yes, like specific script or input results - Section 4, use case 7 - the first sentence has a strange word "&mdash". This use case somehow implies certain architectural design for a PBX with regards to media forking. Is that necessary from a requirement perspective? [LeonP] XML convert mistake. We don't want assume any specific configurations. - Section 4, use case 8 - shall we use a more general terminology such as multi-party call? Depending on the situation, the supervisor may be conferenced with the agent and customer so the recording session needs to define how a multi-party session should be recorded. [LeonP] Yes, probably we want to use more generic term then Complex Call[DS] The term "Multi-Party Call" seems to imply a call/interaction with more than two users...that is, a conference. Recommend to keep "Complex Calls" terminology but define several different cases/examples - for example, Conferences (Henry's example), Consults (as in use case 8), also could include a Whisper Agent/Coaching example, Barge-In example, other... Alternatively, change Use Case 8 to "Consult Call" and add additional use cases for these other complex call examples. =20 - Section 4, use case 11, does a recorder "must" support some sort of media processing such as real-time analytics? This is more of a business application on the recording server side, which is independent of the session recording protocol itself. [LeonP] The main point there was that Recording Protocol must support real time streaming for real time analytics[DS] This Use Case reads like a requirement and should read more like an example of how it is used. =20 Is the ability to support "real-time" analytics dependent on the recording protocol? Is there also a need separate streams for the two channels (what the agent said, what the agent heard) - And do we already have a req't for that.....i.e., req't 10 and/or req't 11? - Section 6: o REQ-001 - what does full-time Recording session mean? [LeonP] Record all calls[DS] Recommend we explain that in the req't; also, is that by DN, or by Agent, or by Customer, other, or all of the above...? =20 o REQ-003 - it's unclear what is the target of the recording session here since this not directly related to a single recorded session (perhaps many) [LeonP] To minimize media clipping associated with recording initiation o REQ-006 - I mentioned above that IVR sessions may contain additional IVR application metadata; should this requirement clarify that the mechanism should include application metadata? [LeonP] Yes, we should o REQ-007 - this wording of the requirement to me is pointing towards a specific implementation of high-availability or fault-tolerance of a recording session. o REQ-009 - the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party session where there are multiple media streams from multiple recorded sessions, and the media streams may be mixed by a conference mixer? [LeonP] It is more for trading floor environments where multiple concurrent calls on the same device (turret) recorded together. It is not related to summation for conference participants at the same call. [DS] Recommend to state this info in the req'ts and provide this example. o REQ-013 - this is only one way of notifying the customer that the call is being recorded but there are others. I think this requires a bit more explanation of why this is needed. To me this looks like a duplicate of REQ-022 [DS] Recommend to change this req't from "Must" to "May" =20 o REQ-015 - what does non-repudiation mean in this context? Isn't this the same as REQ-017? [LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session [DS] Recommend to define "non-repudiation" and/or provide an example to avoid any confusion. =20 o REQ-017 - [DS] Why is non-repudiation of both the SRP and the Media needed? o Req - 022 - [DS] Recommend to add "This MAY be performed by injecting tones into the Recorded Session either from the RS or from the RC." (but could also be done by informing via speech script upon first answering call) =20 o REQ-021 - what happens with SRTP if recording client simply forks the media? The recording server would not be able to decrypt the media unless it gets the private keys from the recorded session. [LeonP] It is out of scope of this document.=20 o REQ-028 - the wording redirected looks out of context here; the requirement only applies when recording client initiates a recording session to an available recorder server? [LeonP] We want to support both directions o REQ-029/030 - They look very generic and I don't think these should be requirements for SRP, but rather a product requirement on how OA&M works for the recording client/server. =20 Thanks Henry =20 =20 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. =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CAA3C4.F5C28681 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Leon, Henry,

I put together some inputs on top of yours for consideration as well…= =2Epls see my inputs below.

 

Regards,

Dave

 

From: Leon Portma= n [mailto:Leon.Portman@nice.com]
Sent: Sunday, January 31, 2010 3:03 AM
To: Henry Lum; dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: RE: Comments on draft-rehor-dispatch-session-recording-re= q-00

 

Hi, Henry.

 

I will try to answer some of the questions. Please see below.

 

Leon

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of Henry Lum
Sent: Sunday, January 31, 2010 6:11 AM
To: dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

 

Hi Ken,

 

I have a bunch of questions and comments on the requ= irements for SRP requirements.

 

-&= nbsp;         Section 3 – Recording Client – If the= SRP requirement does not mandate to use SIP as the actual recording protocol,= why does the recording client have to be a SIP user agent or B2BUA?

[LeonP] Actually there is a difference between Recorded se= ssion (the actual call to be recorded[DS]  Is this just the voice - t= he RTP stream (the replicated voice stream that is sent to a Logger)?  ) that can be no= t SIP based and Recording Session (part of SRP) that is used for triggering rec= ording and it is SIP based[DS] Is this the control messaging…for starting/stopping/pause/resume…the messaging (SIP) for set up of th= e replicated voice stream/RTP transfer? . So both RC and= RS are SIP UA. 

-&= nbsp;         Section 3 - Recorded session – Is a recorde= d session has to be a SIP session?

[LeonP] No, my comment above[DS] I recommend= better Terms and/or better definitions of the Terms “Recorded Session” and “Recording Session”in the Draft = 211; is it possible to change one or both terms since they sound so similar. = ; That is, the IETF Draft definitions are not clear to me…and the differen= ce between these is not clear (for example, do not use the terms themselves = in the definitions…provide examples.  Recommend also to differentiate= these from the Metadata messaging (if they are or could be different), and to d= efine that as well (as rec’d by Martin). 

-&= nbsp;         Section 3 - Persistent Recording – does rec= orded session exist in this context since it seems like the recording session i= s persistent from the endpoint perspective.

[LeonP] No, recorded session are not required to be existi= ng during initiation of persistent session. Persistent recording session can= be initiated on agent logon for example.

-&= nbsp;         Section 4 – use case 5 – if the recor= ding can include recording for an IVR application (ie. VoiceXML application), = does that mean the call metadata must include application contexts as well?

[LeonP] Yes, like specific script or input results<= /i>

-&= nbsp;         Section 4, use case 7 – the first sentence = has a strange word “&mdash”. This use case somehow implies cert= ain architectural design for a PBX with regards to media forking. Is that nec= essary from a requirement perspective?

[LeonP] XML convert mistake. We don’t want assume an= y specific configurations.

-&= nbsp;         Section 4, use case 8 – shall we use a more= general terminology such as multi-party call? Depending on the situation,= the supervisor may be conferenced with the agent and customer so the recordin= g session needs to define how a multi-party session should be recorded.

[LeonP] Yes, probably we want to use more generic term the= n Complex Call[DS] The term “Multi-Party Call” seems to impl= y a call/interaction with more than two users…that is, a conference.&nb= sp; Recommend to keep “Complex Calls” terminology but define seve= ral different cases/examples – for example, Conferences (Henry’s example), Consults (as in use case 8), also could include a Whisper Agent/Coaching example, Barge-In example, other…  Alternativel= y, change Use Case 8 to “Consult Call” and add additional use ca= ses for these other complex call examples. 

-&= nbsp;         Section 4, use case 11, does a recorder “must” support some sort of media processing such as real-tim= e analytics? This is more of a business application on the recording server= side, which is independent of the session recording protocol itself.=

[LeonP] The main point there was that Recording Protocol m= ust support real time streaming for real time analytics<= span style=3D'font-family:"Arial","sans-serif";color:#993366'>[DS]  This = Use Case reads like a requirement and should read more like an example of how it i= s used. 

Is the ability to support “real-time” analytic= s dependent on the recording protocol?  Is there also a need separate streams for the two channels (what the agent said, what the agent heard) = - And do we already have a req’t for that…..i.e., req’t 10 an= d/or req’t 11?

-&= nbsp;         Section 6:

o&= nbsp;  REQ-001 – what does full-time Record= ing session mean?

[LeonP] Record all calls[DS] Recommend w= e explain that in the req’t; also, is that by DN, or by Agent, or by Customer, other, or all of the above…?   <= span style=3D'font-family:"Arial","sans-serif";color:#1F497D'>

o&= nbsp;  REQ-003 – it’s unclear what is= the target of the recording session here since this not directly related to a= single recorded session (perhaps many)

[LeonP] To minimize media clipping associated with recordi= ng initiation

o&= nbsp;  REQ-006 – I mentioned above that IVR= sessions may contain additional IVR application metadata; should this req= uirement clarify that the mechanism should include application metadata?

[LeonP] Yes, we should

o&= nbsp;  REQ-007 – this wording of the requir= ement to me is pointing towards a specific implementation of high-availability = or fault-tolerance of a recording session.

o&= nbsp;  REQ-009 – the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party s= ession where there are multiple media streams from multiple recorded sessions, a= nd the media streams may be mixed by a conference mixer?

[LeonP]  = It is more for trading floor environments where m= ultiple concurrent calls on the same device (turret) recorded together. It is not= related to summation for conference participants at the same call. &= nbsp;   [DS] Recommend t= o state this info in the req’ts and provide this example.

o&= nbsp;  REQ-013 – this is only one way of notifying the customer that the call is being recorded but there are othe= rs. I think this requires a bit more explanation of why this is needed. To me t= his looks like a duplicate of REQ-022    [DS] Recommend t= o change this req’t from “Must” to “May”<= /b>   

o&= nbsp;  REQ-015 – what does non-repudiation = mean in this context? Isn’t this the same as REQ-017?

[LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session <= i>[DS] Recommend t= o define “non-repudiation” and/or provide an example to avoid any conf= usion. 

o&= nbsp;  REQ-017 – [DS]  Why is non-repudiation of = both the SRP and the Media needed?

o   Req – 022  - [DS]  Recom= mend to add “This MAY be performed by injecting tones into the Recorded Session either from the = RS or from the RC.”  (but could also be done by informing via speech= script upon first answering call)  

o&= nbsp;  REQ-021 – what happens with SRTP if recording client simply forks the media? The recording server would not b= e able to decrypt the media unless it gets the private keys from the recorded se= ssion.

[LeonP] It is out of scope of this document.

o&= nbsp;  REQ-028 – the wording redirected loo= ks out of context here; the requirement only applies when recording client initi= ates a recording session to an available recorder server?

[LeonP] We want to support both directions<= span style=3D'font-family:"Arial","sans-serif";color:#1F497D'>

o&= nbsp;  REQ-029/030 – They look very generic= and I don’t think these should be requirements for SRP, but rather a prod= uct requirement on how OA&M works for the recording client/server.

 

Thanks

Henry

 

 


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 an= y information contained in this e-mail is hereby excluded. If you are not t= he intended recipient, please notify the sender immediately, destroy the ori= ginal 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 m= edium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent an= d/or its affiliated entities.

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CAA3C4.F5C28681-- From Dave.Smith@genesyslab.com Tue Feb 2 11:41:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC5C3A68C5 for ; Tue, 2 Feb 2010 11:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsO31HyTWQWP for ; Tue, 2 Feb 2010 11:41:51 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by core3.amsl.com (Postfix) with ESMTP id A3B8E3A68AB for ; Tue, 2 Feb 2010 11:41:51 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id o12JgK9I013940; Tue, 2 Feb 2010 11:42:20 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 11:42:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA43F.D564B5D3" Date: Tue, 2 Feb 2010 11:42:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF SRP DRAFT Thread-Index: AcqkP9TXog+2kNScQzSADP7daBVHjQ== From: "Dave Smith" To: X-OriginalArrivalTime: 02 Feb 2010 19:42:20.0896 (UTC) FILETIME=[D5B7AE00:01CAA43F] Cc: Henry Lum , "Jain, Rajnish" , Leon Portman , "Ken Rehor \(krehor\)" Subject: [dispatch] IETF SRP DRAFT X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 19:41:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA43F.D564B5D3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Ken,=20 =20 Just wanted to say (before I forgot) that your idea about using the diagram to clarify the def'ns is a good one I think....I just recommend to link/match the different parts of the diagram (Call Metadata, Recording Control, Recorded Media) to the definitions.....to describe/show what parts in the diagram are related to what def'ns.....e.g., where is SRP in the diagram, does this Draft cover the different aspects of Recording Control (and if so, which ones & where....we discussed another aspect of control in today's mtg), etc... I think that really would help. =20 Regards, Dave=20 =20 =20 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CAA43F.D564B5D3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Ken= ,

 

Jus= t wanted to say (before I forgot) that your idea about using the diagram to clarif= y the def’ns is a good one I think….I just recommend to link/match = the different parts of the diagram (Call Metadata, Recording Control, Recorded Media) t= o the definitions…..to describe/show what parts in the diagram are relate= d to what def’ns…..e.g., where is SRP in the diagram, does this Dr= aft cover the different aspects of Recording Control (and if so, which ones &= amp; where….we discussed another aspect of control in today’s mtg)= , etc…

I t= hink that really would help.

 

Reg= ards,

Dav= e

 

 

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CAA43F.D564B5D3-- From scottlawrenc@avaya.com Tue Feb 2 10:31:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22DCB3A6952 for ; Tue, 2 Feb 2010 10:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kszYedGrf7S for ; Tue, 2 Feb 2010 10:30:59 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C6F673A67AB for ; Tue, 2 Feb 2010 10:30:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,392,1262581200"; d="scan'208";a="174983204" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Feb 2010 13:31:34 -0500 X-IronPort-AV: E=Sophos;i="4.49,392,1262581200"; d="scan'208";a="441828882" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2010 13:31:32 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o12IVBL23211; Tue, 2 Feb 2010 18:31:11 GMT Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o12IV9b06654; Tue, 2 Feb 2010 18:31:09 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 13:31:08 -0500 From: "Scott Lawrence" To: "Dale Worley" In-Reply-To: <1264704307.5746.62.camel@khone.us.nortel.com> References: <20091026005148.196193A68EF@core3.amsl.com> <1256581091.3748.9.camel@khone.us.nortel.com> <3623C7AE-6491-4D5A-8150-FC2A3E420A91@ntt-at.com> <1260708093.30342.131.camel@scott> <1264704307.5746.62.camel@khone.us.nortel.com> Content-Type: text/plain Organization: Avaya Date: Tue, 02 Feb 2010 13:31:07 -0500 Message-Id: <1265135467.3493.3113.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2010 18:31:08.0809 (UTC) FILETIME=[E35AEF90:01CAA435] X-Mailman-Approved-At: Tue, 02 Feb 2010 14:16:37 -0800 Cc: DISPATCH Subject: Re: [dispatch] New Version Notification for draft-worley-service-example-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 18:31:00 -0000 On Thu, 2010-01-28 at 13:45 -0500, Dale Worley wrote: > On Sun, 2009-12-13 at 07:41 -0500, Scott Lawrence wrote: > > The draft doesn't go into much detail on the specifics of the advantages > > over the method described in 5359 (and other methods in use); it could > > probably use some expansion in that area because the advantages are > > real. > > The current text is: > > This technique for providing music-on-hold has advantages over other > methods now in use: > > 1. The original dialog is not transferred to another UA, so the > "remote endpoint URI" displayed by the remote endpoint's user > interface and dialog event package[dialog-event] does not change > during the call.[service-examples] > > 2. Compared to [service-examples], this method does not require use > of an out-of-dialog REFER, which is not otherwise used much in > SIP and may not be handled correctly by authorization mechanisms. > > 3. The music-on-hold media are sent directly from the music-on-hold > source to the remote UA, rather than being relayed through the > executing UA. > > 4. The remote UA sees, in the incoming SDP, the address/port that > the MOH source will send MOH media from, thus allowing it to > render the media, even if it is filtering incoming media based on > originating address as a media security measure. > > 5. The technique requires relatively simple manipulation of SDP, and > in particular: (1) does not require a SIP element to modify > unrelated SDP to be acceptable to be sent within an already > established sequence of SDP (a problem with > [service-examples-11]), and (2) does not require converting an > SDP answer into an SDP offer (which was a problem with the -00 > version of this document, as well as with [service-examples-11]). > > 6. It complies with the payload type number rules.[offer-answer] > > What do you think needs to be added or expanded? In regard to RFC 5359 > specifically, items 1 and 2 call out the improved behavior. Since the goal is to update 5359, I think that there should be an explicit section that says, in effect: "Here is what is wrong with how it is done in 5359, and why this proposal is better". For each of the above, rather than saying "this way doesn't do xyz", say "service-examples-11 does xyz, and that is a problem because...". Some specifics that you leave unsaid: What's wrong with changing the remote party id on a call just because you get put on hold? In what way is sending an out-of-dialog REFER unreliable? When wouldn't it work? (neither From headers nor Contact addresses are always routable). What's wrong with relaying media through the UA executing the hold? What's wrong with manipulating SDP? What's the big deal with payload number rules? What problem does that cause? From Dave.Smith@genesyslab.com Tue Feb 2 14:33:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B10B28C10A for ; Tue, 2 Feb 2010 14:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.994, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww6WS2WcbhUW for ; Tue, 2 Feb 2010 14:33:14 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by core3.amsl.com (Postfix) with ESMTP id CBB9E28C0D7 for ; Tue, 2 Feb 2010 14:33:14 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id o12MX8g1014284; Tue, 2 Feb 2010 14:33:08 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 14:33:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA457.B18561D3" Date: Tue, 2 Feb 2010 14:33:07 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAEEoz2AADJZSAAAw1mQg References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com><07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF740537930D@NAHALD.us.int.genesyslab.com> From: "Dave Smith" To: "Jain, Rajnish" , "Henry Lum" , "Leon Portman" , X-OriginalArrivalTime: 02 Feb 2010 22:33:08.0822 (UTC) FILETIME=[B1F51760:01CAA457] Cc: krehor@cisco.com Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 22:33:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA457.B18561D3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Raj, Regarding this input: [rj] The SRP, which manages how the recording media gets delivered to the recorders, is based on SIP (SRP is a set of extensions to the SIP core protocol). The sessions that SRP manages are called "Recording Sessions" and they are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The sessions that get actually recorded (e.g. communication between a call center agent and an external caller) may or may not be SIP (this depends on the kind of the PBX phone the agent).=20 =20 Can you please provide a few examples of the different types of protocols that might be possible/practical for the sessions that get actually recorded (which are dependent on the kind of PBX phone used)? =20 Regards, Dave =20 =20 From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com]=20 Sent: Monday, February 01, 2010 3:28 PM To: Henry Lum; Leon Portman; dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 =20 Henry, =20 Thanks for your comments. Inline: =20 - Section 3 - Recording Client - If the SRP requirement does not mandate to use SIP as the actual recording protocol, why does the recording client have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual call to be recorded) that can be not SIP based and Recording Session (part of SRP) that is used for triggering recording and it is SIP based. So both RC and RS are SIP UA. [[hlum]] I now understand that the recorded session does not have to be SIP based, but the wording in the definition of SRP itself mentions that it may be SIP; then why does RC and RS have to be a SIP UA if SRP does not have to be SIP? =20 [rj] The SRP, which manages how the recording media gets delivered to the recorders, is based on SIP (SRP is a set of extensions to the SIP core protocol). The sessions that SRP manages are called "Recording Sessions" and they are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The sessions that get actually recorded (e.g. communication between a call center agent and an external caller) may or may not be SIP (this depends on the kind of the PBX phone the agent).=20 =20 =20 - Section 4 - use case 5 - if the recording can include recording for an IVR application (ie. VoiceXML application), does that mean the call metadata must include application contexts as well? [LeonP] Yes, like specific script or input results [[hlum]] I assume what kind of call metadata and how it is delivered is outside of the scope of this document? =20 [rj] Correct. =20 o REQ-003 - it's unclear what is the target of the recording session here since this not directly related to a single recorded session (perhaps many) [LeonP] To minimize media clipping associated with recording initiation [[hlum]] You actually answered my question above about what a persistent recording mean and why it's useful, but what is unclear to me that is whether there is something called a persistent recording session that targets something like an agent device. =20 [rj] I guess, Persistent Recording is a bit confusing term (we've received other feedback on this as well). If I can use the term always-on recording from the wing-srtp draft then these sessions get established when the agent logs on and torn off when the agent logs off. Codecs such as G.729 and G.711 with VAD are used to ensure that silence is not recorded (for instance, when the agent isn't on a call). =20 o REQ-009 - the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party session where there are multiple media streams from multiple recorded sessions, and the media streams may be mixed by a conference mixer? [LeonP] It is more for trading floor environments where multiple concurrent calls on the same device (turret) recorded together. It is not related to summation for conference participants at the same call. [[hlum]] I'm not familiar with trading floor environments so I may not understand the intent here. If you have multiple concurrent calls then wouldn't you have multiple recording sessions to describe each call individually? Does the endpoint device perform mixing function for multiple calls so that's why you need to club them together in a single recording session? =20 [rj] Due to bandwidth and other cost burdens, the customer demand is that you mix multiple _recorded sessions_ in a single _recording session_. =20 =20 o REQ-028 - the wording redirected looks out of context here; the requirement only applies when recording client initiates a recording session to an available recorder server? [LeonP] We want to support both directions [[hlum]] Okay, then I think we should re-word to mention something about availability in general. (eg. "A request for a new recording session must reach an available recording client or server").=20 =20 [rj] The example test you quoted doesn't reflect the actual intent here. The reason for supporting both directions is dependent on where the policy to record or not resides - RC or RS. The INVITE always comes from either of these two places. =20 Thanks, Raj Jain =20 =20 ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CAA457.B18561D3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Raj,

Regarding this input:

[rj] = The SRP, which manages how the recording media gets delivered to the recorders, is= based on SIP (SRP is a set of extensions to the SIP core protocol). The session= s that SRP manages are called “Recording Sessions” and they are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The sessions = that get actually recorded (e.g. communication between a call center agent and= an external caller) may or may not be SIP (this depends on the kind of the P= BX phone the agent).

 

Can you please provide a few examples of the different types= of protocols that might be possible/practical for the sessions that get actually recorded = (which are dependent on the kind of PBX phone used)?

 

Regards,

Dave

 

 

From: Jain, Rajni= sh [mailto:Rajnish.Jain@ipc.com]
Sent: Monday, February 01, 2010 3:28 PM
To: Henry Lum; Leon Portman; dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00

 

Henry,

 

Thanks for your commen= ts. Inline:

 

-&= nbsp;         Section 3 – Recording Client – If the= SRP requirement does not mandate to use SIP as the actual recording protocol,= why does the recording client have to be a SIP user agent or B2BUA?

[LeonP] Actually there is a difference between= Recorded session (the actual call to be recorded) that can be not SIP bas= ed and Recording Session (part of SRP) that is used for triggering recording and= it is SIP based. So both RC and RS are SIP UA.

[[hlum]] I now understand= that the recorded session does not have to be SIP based, but the wording in the definition of SRP itself mentions that it may be SIP; then why does RC an= d RS have to be a SIP UA if SRP does not have to be SIP?

=

 

[rj] The SRP, which ma= nages how the recording media gets delivered to the recorders, is based on SIP (SRP= is a set of extensions to the SIP core protocol). The sessions that SRP manage= s are called “Recording Sessions” and they are SIP sessions. Theref= ore, RC and RS are, by definition, SIP UAs. The sessions that get actually rec= orded (e.g. communication between a call center agent and an external caller) m= ay or may not be SIP (this depends on the kind of the PBX phone the agent).

 

 

-&= nbsp;         Section 4 – use case 5 – if the recor= ding can include recording for an IVR application (ie. VoiceXML application), = does that mean the call metadata must include application contexts as well?

[LeonP] Yes, like specific script or input res= ults

[[hlum]] I assume what ki= nd of call metadata and how it is delivered is outside of the scope of this document= ?

 

[rj] Correct.

 

o&= nbsp;  REQ-003 – it’s unclear what is= the target of the recording session here since this not directly related to a= single recorded session (perhaps many)

[LeonP] To minimize media clipping associated = with recording initiation

[[hlum]] You actually ans= wered my question above about what a persistent recording mean and why it’s useful, but what is unclear to me that is whether there is something call= ed a persistent recording session that targets something like an agent device.=

 

[rj] I guess, Persiste= nt Recording is a bit confusing term (we’ve received other feedback on= this as well). If I can use the term always-on recording from the wing-srtp dr= aft then these sessions get established when the agent logs on and torn off w= hen the agent logs off. Codecs such as G.729 and G.711 with VAD are used to e= nsure that silence is not recorded (for instance, when the agent isn’t on= a call).

 

o&= nbsp;  REQ-009 – the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party s= ession where there are multiple media streams from multiple recorded sessions, a= nd the media streams may be mixed by a conference mixer?

[LeonP]  It is more for trading floor environments where multiple concurrent calls on th= e same device (turret) recorded together. It is not related to summation for conference participants at the same call.

[[hlum]] I’m not fa= miliar with trading floor environments so I may not understand the intent here. = If you have multiple concurrent calls then wouldn’t you have multiple reco= rding sessions to describe each call individually? Does the endpoint device per= form mixing function for multiple calls so that’s why you need to club t= hem together in a single recording session?

 

[rj] Due to bandwidth = and other cost burdens, the customer demand is that you mix multiple _recorded sessions_ in a single _recording session_.

 

 

o&= nbsp;  REQ-028 – the wording redirected loo= ks out of context here; the requirement only applies when recording client initi= ates a recording session to an available recorder server?

[LeonP] We want to support both directions

[[hlum]] Okay, then I thi= nk we should re-word to mention something about availability in general.  = (eg. “A request for a new recording session must reach an available reco= rding client or server”).

 

[rj] The example test = you quoted doesn’t reflect the actual intent here. The reason for supporting b= oth directions is dependent on where the policy to record or not resides R= 11; RC or RS. The INVITE always comes from either of these two places.

 

Thanks,

Raj Jain

 

 

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you a= re not an intended recipient of this e-mail, do not duplicate or redistribute it= by any means. Please delete it and any attachments and notify the sender tha= t you have received it in error. Unintended recipients are prohibited from taki= ng action on the basis of information in this e-mail.E-mail messages may con= tain computer viruses or other defects, may not be accurately replicated on ot= her systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfort= able with the risks associated with e-mail messages, you may decide not to use= e-mail to communicate with IPC. IPC reserves the right, to the extent and= under circumstances permitted by applicable law, to retain, monitor and interce= pt e-mail messages to and from its systems.

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CAA457.B18561D3-- From rajnish.jain@ipc.com Tue Feb 2 15:55:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68DF28C134 for ; Tue, 2 Feb 2010 15:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Apo1dxeD8Nq for ; Tue, 2 Feb 2010 15:55:35 -0800 (PST) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by core3.amsl.com (Postfix) with ESMTP id 9041228C132 for ; Tue, 2 Feb 2010 15:55:33 -0800 (PST) Received: from unknown [65.244.37.51] (EHLO p01c12o141.mxlogic.net) by p01c12o141.mxlogic.net(mxl_mta-6.5.0-0) with ESMTP id e9bb86b4.a17a1b90.99902.00-484.224813.p01c12o141.mxlogic.net (envelope-from ); Tue, 02 Feb 2010 16:56:14 -0700 (MST) X-MXL-Hash: 4b68bb9e52ce445a-e0586171964b78e70d2d55e6337b3ade2bcb8809 Received: from unknown [65.244.37.51] (EHLO smtp.ipc.com) by p01c12o141.mxlogic.net(mxl_mta-6.5.0-0) over TLS secured channel with ESMTP id 188b86b4.0.96412.00-014.218336.p01c12o141.mxlogic.net (envelope-from ); Tue, 02 Feb 2010 16:42:58 -0700 (MST) X-MXL-Hash: 4b68b882493e02a8-54c25b5c9193e8905e328409ec69d7e4a90415da Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.247]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Tue, 2 Feb 2010 18:42:56 -0500 From: "Jain, Rajnish" To: Dave Smith , Henry Lum , Leon Portman , "dispatch@ietf.org" Date: Tue, 2 Feb 2010 18:42:55 -0500 Thread-Topic: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAEEoz2AADJZSAAAw1mQgAAJibMA= Message-ID: References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com><07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF740537930D@NAHALD.us.int.genesyslab.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.000.1038-17168.003 x-tm-as-result: No--50.430500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_A549831415082442872141F4C99FE71301EDC50E7ESTSNYCMS1corp_" MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=z+2a4RCZxltofrpCDsS06w==:17 a=Tn40LXQWAAAA:8 a] X-AnalysisOut: [=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=vvKfUcgjAAAA:8 a=1HLV9X] X-AnalysisOut: [koM5QEZqyI34MA:9 a=8iJ2LWKiubigRNy0LB4A:7 a=LevAyUxAzecR_F] X-AnalysisOut: [WI-qXUiYBO5awA:4 a=Pw_wLAgS6uQA:10 a=lZB815dzVvQA:10 a=JfD] X-AnalysisOut: [0Fch1gWkA:10 a=OeN1TrMypwAA:10 a=whdYfQUhDAFULvQF:21 a=ttq] X-AnalysisOut: [q2fDxzhlrwFp4:21 a=SSmOFEACAAAA:8 a=Y2VNeNrzAAAA:8 a=yMhMj] X-AnalysisOut: [lubAAAA:8 a=TW66zc2HAAAA:8 a=HQ31llbKAAAA:8 a=wdit_z9nL5Lm] X-AnalysisOut: [FjRBfKQA:9 a=5TcCcabYcy_b5DsdqkUA:7 a=S7sC_Ko4r-wH5g4r8_Y4] X-AnalysisOut: [KJfQpgwA:4] Cc: "krehor@cisco.com" Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 23:55:46 -0000 --_000_A549831415082442872141F4C99FE71301EDC50E7ESTSNYCMS1corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, Inline: From: Dave Smith [mailto:Dave.Smith@genesyslab.com] Sent: Tuesday, February 02, 2010 5:33 PM To: Jain, Rajnish; Henry Lum; Leon Portman; dispatch@ietf.org Cc: krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Raj, Regarding this input: [rj] The SRP, which manages how the recording media gets delivered to the r= ecorders, is based on SIP (SRP is a set of extensions to the SIP core proto= col). The sessions that SRP manages are called "Recording Sessions" and the= y are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The s= essions that get actually recorded (e.g. communication between a call cente= r agent and an external caller) may or may not be SIP (this depends on the = kind of the PBX phone the agent). Can you please provide a few examples of the different types of protocols t= hat might be possible/practical for the sessions that get actually recorded= (which are dependent on the kind of PBX phone used)? [rj] This can range anywhere from proprietary VoIP media and signaling prot= ocols to things such as SCCP, UNISTIM, H.323, TDM and analog phones. Most s= uch phones are not SIP UAs. Some other entity (such as a SIP-enabled mixer)= may provide the RC media forking point functionality in these cases. Thanks, Raj From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] Sent: Monday, February 01, 2010 3:28 PM To: Henry Lum; Leon Portman; dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Henry, Thanks for your comments. Inline: - Section 3 - Recording Client - If the SRP requirement does not man= date to use SIP as the actual recording protocol, why does the recording cl= ient have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual= call to be recorded) that can be not SIP based and Recording Session (part= of SRP) that is used for triggering recording and it is SIP based. So both= RC and RS are SIP UA. [[hlum]] I now understand that the recorded session does not have to be SIP= based, but the wording in the definition of SRP itself mentions that it ma= y be SIP; then why does RC and RS have to be a SIP UA if SRP does not have = to be SIP? [rj] The SRP, which manages how the recording media gets delivered to the r= ecorders, is based on SIP (SRP is a set of extensions to the SIP core proto= col). The sessions that SRP manages are called "Recording Sessions" and the= y are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The s= essions that get actually recorded (e.g. communication between a call cente= r agent and an external caller) may or may not be SIP (this depends on the = kind of the PBX phone the agent). - Section 4 - use case 5 - if the recording can include recording fo= r an IVR application (ie. VoiceXML application), does that mean the call me= tadata must include application contexts as well? [LeonP] Yes, like specific script or input results [[hlum]] I assume what kind of call metadata and how it is delivered is out= side of the scope of this document? [rj] Correct. o REQ-003 - it's unclear what is the target of the recording session here= since this not directly related to a single recorded session (perhaps many= ) [LeonP] To minimize media clipping associated with recording initiation [[hlum]] You actually answered my question above about what a persistent re= cording mean and why it's useful, but what is unclear to me that is whether= there is something called a persistent recording session that targets some= thing like an agent device. [rj] I guess, Persistent Recording is a bit confusing term (we've received = other feedback on this as well). If I can use the term always-on recording = from the wing-srtp draft then these sessions get established when the agent= logs on and torn off when the agent logs off. Codecs such as G.729 and G.7= 11 with VAD are used to ensure that silence is not recorded (for instance, = when the agent isn't on a call). o REQ-009 - the wording here is a bit unclear here. Do you mean the recor= ded session represents a multi-party session where there are multiple media= streams from multiple recorded sessions, and the media streams may be mixe= d by a conference mixer? [LeonP] It is more for trading floor environments where multiple concurren= t calls on the same device (turret) recorded together. It is not related to= summation for conference participants at the same call. [[hlum]] I'm not familiar with trading floor environments so I may not unde= rstand the intent here. If you have multiple concurrent calls then wouldn't= you have multiple recording sessions to describe each call individually? D= oes the endpoint device perform mixing function for multiple calls so that'= s why you need to club them together in a single recording session? [rj] Due to bandwidth and other cost burdens, the customer demand is that y= ou mix multiple _recorded sessions_ in a single _recording session_. o REQ-028 - the wording redirected looks out of context here; the require= ment only applies when recording client initiates a recording session to an= available recorder server? [LeonP] We want to support both directions [[hlum]] Okay, then I think we should re-word to mention something about av= ailability in general. (eg. "A request for a new recording session must re= ach an available recording client or server"). [rj] The example test you quoted doesn't reflect the actual intent here. Th= e reason for supporting both directions is dependent on where the policy to= record or not resides - RC or RS. The INVITE always comes from either of t= hese two places. Thanks, Raj Jain ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. --_000_A549831415082442872141F4C99FE71301EDC50E7ESTSNYCMS1corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,<= /p>

 =

Inline:

 =

From: Dave Smith [mailto:Dave.Smith@genesyslab.com]
Sent: Tuesday, February 02, 2010 5:33 PM
To: Jain, Rajnish; Henry Lum; Leon Portman; dispatch@ietf.org
Cc: krehor@cisco.com
Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00

 

Raj,

Regarding this input:

[rj] Th= e SRP, which manages how the recording media gets delivered to the recorders, is b= ased on SIP (SRP is a set of extensions to the SIP core protocol). The sessions = that SRP manages are called “Recording Sessions” and they are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The sessions th= at get actually recorded (e.g. communication between a call center agent and a= n external caller) may or may not be SIP (this depends on the kind of the PBX phone the agent).

 

Can you please provide a few examples of the different= types of protocols that might be possible/practical for the sessions that get actually recorded (which are dependent on the kind of PBX phone used)?

 =

[rj] This can range anyw= here from proprietary VoIP media and signaling protocols to things such as SCCP,= UNISTIM, H.323, TDM and analog phones. Most such phones are not SIP UAs. Some other entity (such as a SIP-enabled mixer) may provide the RC media forking point= functionality in these cases.

 =

Thanks,

Raj

 

From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.co= m]
Sent: Monday, February 01, 2010 3:28 PM
To: Henry Lum; Leon Portman; dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00

 

Henry,=

 =

Thanks for your comments= . Inline:

 =

-&nb= sp;       Section 3 – Recording Client – If the S= RP requirement does not mandate to use SIP as the actual recording protocol, w= hy does the recording client have to be a SIP user agent or B2BUA?<= /p>

[LeonP] Actually there is a difference between Recorded session (the actual call to be recorded) that can be not SIP based= and Recording Session (part of SRP) that is used for triggering recording and i= t is SIP based. So both RC and RS are SIP UA.

[[hlum]] I now understand t= hat the recorded session does not have to be SIP based, but the wording in the definition of SRP itself mentions that it may be SIP; then why does RC and = RS have to be a SIP UA if SRP does not have to be SIP?

 =

[rj] The SRP, which mana= ges how the recording media gets delivered to the recorders, is based on SIP (SRP i= s a set of extensions to the SIP core protocol). The sessions that SRP manages = are called “Recording Sessions” and they are SIP sessions. Therefor= e, RC and RS are, by definition, SIP UAs. The sessions that get actually recor= ded (e.g. communication between a call center agent and an external caller) may= or may not be SIP (this depends on the kind of the PBX phone the agent). =

 =

 =

-&nb= sp;       Section 4 – use case 5 – if the recordi= ng can include recording for an IVR application (ie. VoiceXML application), do= es that mean the call metadata must include application contexts as well?=

[LeonP] Yes, like specific script or input resul= ts

[[hlum]] I assume what kind= of call metadata and how it is delivered is outside of the scope of this document?<= o:p>

 =

[rj] Correct.=

 =

o&nb= sp;  REQ-003 – it’s unclear what is t= he target of the recording session here since this not directly related to a single recorded session (perhaps many)

[LeonP] To minimize media clipping associated wi= th recording initiation

[[hlum]] You actually answe= red my question above about what a persistent recording mean and why it’s us= eful, but what is unclear to me that is whether there is something called a persistent recording session that targets something like an agent device.

 =

[rj] I guess, Persistent Recording is a bit confusing term (we’ve received other feedback on t= his as well). If I can use the term always-on recording from the wing-srtp draf= t then these sessions get established when the agent logs on and torn off whe= n the agent logs off. Codecs such as G.729 and G.711 with VAD are used to ens= ure that silence is not recorded (for instance, when the agent isn’t on a call).

 =

o&nb= sp;  REQ-009 – the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party ses= sion where there are multiple media streams from multiple recorded sessions, and= the media streams may be mixed by a conference mixer?

[LeonP]  It is more for trading floor environments where multiple concurrent calls on the = same device (turret) recorded together. It is not related to summation for conference participants at the same call.

[[hlum]] I’m not fami= liar with trading floor environments so I may not understand the intent here. If= you have multiple concurrent calls then wouldn’t you have multiple record= ing sessions to describe each call individually? Does the endpoint device perfo= rm mixing function for multiple calls so that’s why you need to club the= m together in a single recording session?

 =

[rj] Due to bandwidth an= d other cost burdens, the customer demand is that you mix multiple _recorded sessions_ in a single _recording session_.

 =

 =

o&nb= sp;  REQ-028 – the wording redirected looks= out of context here; the requirement only applies when recording client initiat= es a recording session to an available recorder server?

[LeonP] We want to support both directions<= /o:p>

[[hlum]] Okay, then I think= we should re-word to mention something about availability in general.  (e= g. “A request for a new recording session must reach an available record= ing client or server”). =

 =

[rj] The example test yo= u quoted doesn’t reflect the actual intent here. The reason for supporting bot= h directions is dependent on where the policy to record or not resides –= ; RC or RS. The INVITE always comes from either of these two places.<= /span>

 =

Thanks,

Raj Jain

 =

 

DISCLAIMER: This e-mail may contain information that i= s confidential, privileged or otherwise protected from disclosure. If you are= not an intended recipient of this e-mail, do not duplicate or redistribute it b= y any means. Please delete it and any attachments and notify the sender that = you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may conta= in computer viruses or other defects, may not be accurately replicated on othe= r systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortab= le with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and u= nder circumstances permitted by applicable law, to retain, monitor and intercept= e-mail messages to and from its systems.

 

 


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. A= ny 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 origi= nal transmission and its attachments and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any med= ium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/= or its affiliated entities.

--_000_A549831415082442872141F4C99FE71301EDC50E7ESTSNYCMS1corp_-- From zhouzp@huawei.com Wed Feb 3 01:51:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76483A6BEB for ; Wed, 3 Feb 2010 01:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.014 X-Spam-Level: *** X-Spam-Status: No, score=3.014 tagged_above=-999 required=5 tests=[AWL=4.125, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mSRWcwCTB-y for ; Wed, 3 Feb 2010 01:51:59 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id EF95C3A6BE3 for ; Wed, 3 Feb 2010 01:51:58 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX90092FFEMMH@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 03 Feb 2010 17:51:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX900HSHFEMUM@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 03 Feb 2010 17:51:58 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [217.167.116.106]) by szxmc03-in.huawei.com (mshttpd); Wed, 03 Feb 2010 17:51:58 +0800 Date: Wed, 03 Feb 2010 17:51:58 +0800 From: zhouzhipeng 54906 In-reply-to: To: dispatch@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 09:51:59 -0000 Dear all, I have got much valuable information from related emails. As I cited as following, > [rj] This can range anywhere from proprietary VoIP media and > signaling protocols to things such as SCCP, UNISTIM, H.323, TDM > and analog phones. Most such phones are not SIP UAs. Some other > entity (such as a SIP-enabled mixer) may provide the RC media > forking point functionality in these cases. there have been many years for the application of recording. So, may the author give us a brief summary what have been advanced based on current recording solutions, for example the call center architecture. So we can easily catch the core point of this document. Another point is: does the diagram need to add the interface between UA to the RS for the search or query functions. Thanks very much. Zhipeng From henry.sinnreich@gmail.com Wed Feb 3 10:17:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F5A28C17B for ; Wed, 3 Feb 2010 10:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+2PlgcU8h4N for ; Wed, 3 Feb 2010 10:17:16 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 5CAE028C170 for ; Wed, 3 Feb 2010 10:17:16 -0800 (PST) Received: by yxe4 with SMTP id 4so1651108yxe.32 for ; Wed, 03 Feb 2010 10:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=Ulg8b1zzal+gUFTXXf2a2jieCxbpafvvH7sYXhYCafU=; b=lCkY+BFa3s7cM+pZ7zmlYKeH2BAe5URNu5snkYZKWKBBYqFo5c0kYFNVxFYmQsr5Pt 01MvD7gfZ4o0Y6E17HyzIMnuHHVnXd38l37S68orEAVZ+9aj4VZRY2PVxgKStFlqQeM+ TEfG0M82DGQVSCkimszbPF7tlRCOI0iQm0y5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=qpW01Hx/+cPAfPBnhOt5kZQTPlfc1dfCbicQ1O2kwPDU+53xZiwcueMfCmtIzXSG4Y c+ncrPH+/6NH7EbJ+gJl6K1zW6q5jd1ci+x419sf97vFwE5DVTZbIjdw0+/bXnZR66vP 7DXHjWaYWrH7p9GmRm/sK7kREYuOQRF48w/9M= Received: by 10.90.40.17 with SMTP id n17mr279305agn.3.1265221076288; Wed, 03 Feb 2010 10:17:56 -0800 (PST) Received: from ?192.168.0.31? (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 7sm2610381ywc.21.2010.02.03.10.17.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 10:17:55 -0800 (PST) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 03 Feb 2010 12:17:52 -0600 From: Henry Sinnreich To: dispatch mailing list Message-ID: Thread-Topic: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: Acqk/TLV2aIfjAsHN0W0EOLjGZc8Kg== In-Reply-To: <4B69B30E.3010909@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 18:17:17 -0000 We have published an I-D on "SIP APIs for Web Communications" and would appreciate any comments and input. Here is the link and the announcement: http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP APIs for Communications on the Web Author(s) : H. Sinnreich, A. Johnston Filename : draft-sinnreich-sip-web-apis-00.txt Pages : 19 Date : 2010-1-19 Interactive communications are becoming part of rich Internet applications (RIA). This can be accomplished entirely by using Web technology and developing it as an Internet standard. Voice over IP (VoIP) features developed for Session Initiation Protocol (SIP 2.0) can be preserved in rich multimedia communications and applications on the web. Hyper Text Transport Protocol (HTTP) is used for control and signaling data and RTP for interactive media transport respectively. No other network application protocols are required. Web, fixed and mobile device application development tools can thus be used to include components and widgets for Internet presence, Instant Messaging (IM), voice and video. This opens Internet communications, including voice to application developers and will also enhance the user experience with real-time Web and mobile communications. Usage scenarios include service providers, private IP networks, device application developers and media companies providing a mix of integrated communications, applications and media. This memo argues for the development and standardization of Application Programming Interfaces (APIs) to allow the benefits of SIP to be used by Rich Internet Applications (RIA), for fixed and mobile devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt ------ End of Forwarded Message Thanks in advance for your comments. Henry From peter.musgrave@magorcorp.com Wed Feb 3 12:20:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79173A6B4D for ; Wed, 3 Feb 2010 12:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-UE5Vh-bbU2 for ; Wed, 3 Feb 2010 12:20:32 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 4B9363A6A3C for ; Wed, 3 Feb 2010 12:20:32 -0800 (PST) Received: by ewy28 with SMTP id 28so1903805ewy.28 for ; Wed, 03 Feb 2010 12:21:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.89.193 with SMTP id c43mr21131wef.221.1265228472064; Wed, 03 Feb 2010 12:21:12 -0800 (PST) In-Reply-To: References: <4B69B30E.3010909@gmail.com> Date: Wed, 3 Feb 2010 15:21:11 -0500 Message-ID: <8e5ec72f1002031221we5a4da6s16c84d8a31543e90@mail.gmail.com> From: Peter Musgrave To: Henry Sinnreich Content-Type: multipart/alternative; boundary=0016e6d46d7da31f88047eb7f542 Cc: dispatch mailing list Subject: Re: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 20:20:33 -0000 --0016e6d46d7da31f88047eb7f542 Content-Type: text/plain; charset=ISO-8859-1 Hi Henry, (Based on a one-pass read through) I like the ideas expressed in this draft. The summary of SIP 2.0 is on target and the definition of a web API is a good idea. It is something I can use. Moving to HIP is a good idea. Regards, Peter Musgrave On Wed, Feb 3, 2010 at 1:17 PM, Henry Sinnreich wrote: > We have published an I-D on "SIP APIs for Web Communications" and would > appreciate any comments and input. > > Here is the link and the announcement: > > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SIP APIs for Communications on the Web > Author(s) : H. Sinnreich, A. Johnston > Filename : draft-sinnreich-sip-web-apis-00.txt > Pages : 19 > Date : 2010-1-19 > > Interactive communications are becoming part of rich Internet > applications (RIA). This can be accomplished entirely by using Web > technology and developing it as an Internet standard. Voice over IP > (VoIP) features developed for Session Initiation Protocol (SIP 2.0) > can be preserved in rich multimedia communications and applications > on the web. Hyper Text Transport Protocol (HTTP) is used for control > and signaling data and RTP for interactive media transport > respectively. No other network application protocols are required. > Web, fixed and mobile device application development tools can thus > be used to include components and widgets for Internet presence, > Instant Messaging (IM), voice and video. This opens Internet > communications, including voice to application developers and will > also enhance the user experience with real-time Web and mobile > communications. Usage scenarios include service providers, private > IP networks, device application developers and media companies > providing a mix of integrated communications, applications and media. > This memo argues for the development and standardization of > Application Programming Interfaces (APIs) to allow the benefits of > SIP to be used by Rich Internet Applications (RIA), for fixed and > mobile devices. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt > > ------ End of Forwarded Message > > Thanks in advance for your comments. > > Henry > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0016e6d46d7da31f88047eb7f542 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Henry,=A0

(Based on a one-pass read through)

I like the ideas expressed in this draft. The summary of S= IP 2.0 is on target and the definition of a web API is a good idea. It is s= omething I can use.

Moving to HIP is a good idea.

= Regards,=A0

Peter Musgrave

On Wed, Feb 3, 2010 at 1:17 PM, Henry Sinnreich <henry.sinnreich@gmail.co= m> wrote:
We have published an I-D on "SIP APIs = for Web Communications" and would
appreciate any comments and input.

Here is the link and the announcement:

http://www.ietf.org/internet-drafts/draft-sinnre= ich-sip-web-apis-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=A0Title =A0: SIP APIs for Communications on the Web
=A0Author(s) : H. Sinnreich, A. Johnston
=A0Filename : draft-sinnreich-sip-web-apis-00.txt
=A0Pages =A0: 19
=A0Date =A0: 2010-1-19

=A0 Interactive communications are becoming part of rich Internet
=A0 applications (RIA). This can be accomplished entirely by using Web
=A0 technology and developing it as an Internet standard. Voice over IP =A0 (VoIP) features developed for Session Initiation Protocol (SIP 2.0) =A0 can be preserved in rich multimedia communications and applications =A0 on the web. =A0Hyper Text Transport Protocol (HTTP) is used for contro= l
=A0 and signaling data and RTP for interactive media transport
=A0 respectively. No other network application protocols are required.
=A0 Web, fixed and mobile device application development tools can thus =A0 be used to include components and widgets for Internet presence,
=A0 Instant Messaging (IM), voice and video. =A0This opens Internet
=A0 communications, including voice to application developers and will
=A0 also enhance the user experience with real-time Web and mobile
=A0 communications. =A0Usage scenarios include service providers, private<= br> =A0 IP networks, device application developers and media companies
=A0 providing a mix of integrated communications, applications and media.<= br> =A0 This memo argues for the development and standardization of
=A0 Application Programming Interfaces (APIs) to allow the benefits of
=A0 SIP to be used by Rich Internet Applications (RIA), for fixed and
=A0 mobile devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sinnre= ich-sip-web-apis-00.txt

------ End of Forwarded Message

Thanks in advance for your comments.

Henry


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--0016e6d46d7da31f88047eb7f542-- From bernard_aboba@hotmail.com Wed Feb 3 12:55:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7272C3A68AD for ; Wed, 3 Feb 2010 12:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhgUecDLGEgU for ; Wed, 3 Feb 2010 12:55:15 -0800 (PST) Received: from blu0-omc4-s16.blu0.hotmail.com (blu0-omc4-s16.blu0.hotmail.com [65.55.111.155]) by core3.amsl.com (Postfix) with ESMTP id 7AD6B3A6868 for ; Wed, 3 Feb 2010 12:55:15 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.136]) by blu0-omc4-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 12:55:58 -0800 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 3 Feb 2010 12:55:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcqlEW6fzo676ejnSgWcMPDjB7vtFg== Content-Language: en-us X-OriginalArrivalTime: 03 Feb 2010 20:55:58.0796 (UTC) FILETIME=[496778C0:01CAA513] Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 20:55:16 -0000 There is considerable work already underway to address some of the issues raised in this draft. For example: 1. Work in W3C HTML5 WGs to add native support for audio and video. 2. Work in IETF "HyBi" WG to make HTTP more suitable for realtime signaling 3. Work in XSF to provide enhanced telephony support within XMPP (e.g. Jingle ICE, Jingle Transfer, etc.) 4. Work in IETF XMPP WG to revise RFC 3920/3921, address SIP/XMPP interop, etc. Given this, my reading of the document raised several questions: 1. What problems exist with existing XML over HTTP approaches to signaling (e.g. XMPP over HTTP w/Jingle)? 2. What additional work beyond what is already under discussion is necessary to complete the vision you describe? ========================================================== Henry said: "We have published an I-D on "SIP APIs for Web Communications" and would appreciate any comments and input. Here is the link and the announcement: http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP APIs for Communications on the Web Author(s) : H. Sinnreich, A. Johnston Filename : draft-sinnreich-sip-web-apis-00.txt Pages : 19 Date : 2010-1-19 Interactive communications are becoming part of rich Internet applications (RIA). This can be accomplished entirely by using Web technology and developing it as an Internet standard. Voice over IP (VoIP) features developed for Session Initiation Protocol (SIP 2.0) can be preserved in rich multimedia communications and applications on the web. Hyper Text Transport Protocol (HTTP) is used for control and signaling data and RTP for interactive media transport respectively. No other network application protocols are required. Web, fixed and mobile device application development tools can thus be used to include components and widgets for Internet presence, Instant Messaging (IM), voice and video. This opens Internet communications, including voice to application developers and will also enhance the user experience with real-time Web and mobile communications. Usage scenarios include service providers, private IP networks, device application developers and media companies providing a mix of integrated communications, applications and media. This memo argues for the development and standardization of Application Programming Interfaces (APIs) to allow the benefits of SIP to be used by Rich Internet Applications (RIA), for fixed and mobile devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt" From henry.sinnreich@gmail.com Wed Feb 3 18:02:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42933A67B6 for ; Wed, 3 Feb 2010 18:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqO1Te9Ai8IA for ; Wed, 3 Feb 2010 18:02:15 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 4B42E3A6359 for ; Wed, 3 Feb 2010 18:02:15 -0800 (PST) Received: by gxk28 with SMTP id 28so1927019gxk.9 for ; Wed, 03 Feb 2010 18:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=+TdYv0jrI9vifm+Fe2N287n3JsC+1D7zMX2K3tdU2wA=; b=wLxs/ZHxbKOcSZpfs3XjU/vRu42CO501CSqQx2D47KwXEkSe77sGVEE9xEkAk4/h7J 2zJjaGtc1SgvuSbvJ7Ompw2g8h+IQYKHRYyAzNYYXirYahX+9o0dH3DJmPG3unHOZRpo X6yoC330N0OtCgNsNaIbnxaKpTLHoV7lLg5lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=cSOndotZpJNHYnM3sx0FibmKmcfa2xO17z7gvM3cwYBAWi+NM6tAgJKn/xeYFl1MOS qgeN2uIvldJop/Lq1oCkPHR3+WAKpvtc+GsIsiRDPLOWbkYolp9MjuDp+9a96Fn7pNbt o/110MKWbACKe9BAHRkfOviI4mki1oxZE6RRc= Received: by 10.101.195.17 with SMTP id x17mr548578anp.110.1265248975511; Wed, 03 Feb 2010 18:02:55 -0800 (PST) Received: from ?192.168.0.31? (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 6sm2710564yxg.30.2010.02.03.18.02.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 18:02:54 -0800 (PST) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 03 Feb 2010 20:02:52 -0600 From: Henry Sinnreich To: Bernard Aboba , Message-ID: Thread-Topic: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: AcqlEW6fzo676ejnSgWcMPDjB7vtFgALLnrC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 02:02:16 -0000 Hi Bernard, Thanks for drilling down on some of the issues. > 1. Work in W3C HTML5 WGs to add native support for audio and video. > 2. Work in IETF "HyBi" WG to make HTTP more suitable for realtime signaling Both confirm we believe our approach, though no SIP-specific functionality for rendezvous and session initiation is envisaged, as is the focus in our I-D. Even less on how to port the very rich SIP voice functionality to HTML/HTTP. Such items as support for the SPEEX codec (in the example) in http://dev.w3.org/html5/spec/Overview.html and for bidirectional HTTP (as mentioned in our I-D), at http://trac.tools.ietf.org/bof/trac/wiki/HyBi are really heartening. > 1. What problems exist with existing XML over HTTP approaches to signaling > (e.g. XMPP over HTTP w/Jingle)? No problems at all with XMPP, except sharing the same problem with SIP, SIMPLE and all the proprietary IM protocols that are dominant in the IM market (no names mentioned here): Too complex for generalists Web application developers to afford the time and resources to learn and to use. Though it would be useful to have similar APIs developed in the IM industry ported to Web communications as well. There is no reason not to replace them all with HTTP transport and APIs for the client and/or server applications. Section 1.2 Background in our I-D says: " Note that in a similar fashion other network application protocols; XMPP [7] or MSRP [8], and RTSP [9] have also one single significant application each: IM chat and network media player respectively. This is due to the '90s view that new Internet apps require new protocols. The advent of RIA has made this view obsolete at present, given the seemingly boundless number of new rich Internet applications using just HTTP as the only standard network application layer protocol." (for data only as mentioned elsewhere, and having RTP/UPD as a possible companion protocol for real-time interactive media). > 2. What additional work beyond what is already under discussion is necessary > to complete the vision you describe? The biggest work item IMO is replacing the stale and problematic SDP with metadata as detailed in section 2.3.3 and thus also fixing the non-compliance of SIP with "UNSAF" RFC 3424. Our I-D deals only with SIP at this point. Replacing SDP and its consequences for NAT traversal requires indeed some work, possibly not in scope here. Much more than SDP codec negotiation (and providing misleading transport addresses) is required to support adequate user experience, depending on device capabilities, no matter what screen size, keyboard, mouse, touch screen, remote control, etc. All this can be far better accomplished using metadata, as in RFC 5013. Thanks again for focusing on these issues. Henry On 2/3/10 2:55 PM, "Bernard Aboba" wrote: > There is considerable work already underway to address some of the issues > raised in this draft. For example: > > 1. Work in W3C HTML5 WGs to add native support for audio and video. > 2. Work in IETF "HyBi" WG to make HTTP more suitable for realtime signaling > 3. Work in XSF to provide enhanced telephony support within XMPP (e.g. > Jingle ICE, Jingle Transfer, etc.) > 4. Work in IETF XMPP WG to revise RFC 3920/3921, address SIP/XMPP interop, > etc. > > Given this, my reading of the document raised several questions: > > 1. What problems exist with existing XML over HTTP approaches to signaling > (e.g. XMPP over HTTP w/Jingle)? > 2. What additional work beyond what is already under discussion is necessary > to complete the vision you describe? > > ========================================================== > Henry said: > > "We have published an I-D on "SIP APIs for Web Communications" and would > appreciate any comments and input. > > Here is the link and the announcement: > > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SIP APIs for Communications on the Web > Author(s) : H. Sinnreich, A. Johnston > Filename : draft-sinnreich-sip-web-apis-00.txt > Pages : 19 > Date : 2010-1-19 > > Interactive communications are becoming part of rich Internet > applications (RIA). This can be accomplished entirely by using Web > technology and developing it as an Internet standard. Voice over IP > (VoIP) features developed for Session Initiation Protocol (SIP 2.0) > can be preserved in rich multimedia communications and applications > on the web. Hyper Text Transport Protocol (HTTP) is used for control > and signaling data and RTP for interactive media transport > respectively. No other network application protocols are required. > Web, fixed and mobile device application development tools can thus > be used to include components and widgets for Internet presence, > Instant Messaging (IM), voice and video. This opens Internet > communications, including voice to application developers and will > also enhance the user experience with real-time Web and mobile > communications. Usage scenarios include service providers, private > IP networks, device application developers and media companies > providing a mix of integrated communications, applications and media. > This memo argues for the development and standardization of > Application Programming Interfaces (APIs) to allow the benefits of > SIP to be used by Rich Internet Applications (RIA), for fixed and > mobile devices. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt" > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From bernard_aboba@hotmail.com Wed Feb 3 18:51:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002DC3A6A48 for ; Wed, 3 Feb 2010 18:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3GYClKR1182 for ; Wed, 3 Feb 2010 18:51:48 -0800 (PST) Received: from blu0-omc4-s33.blu0.hotmail.com (blu0-omc4-s33.blu0.hotmail.com [65.55.111.172]) by core3.amsl.com (Postfix) with ESMTP id AB9F73A6A28 for ; Wed, 3 Feb 2010 18:51:48 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.136]) by blu0-omc4-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 18:52:33 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Henry Sinnreich'" , References: In-Reply-To: Date: Wed, 3 Feb 2010 18:52:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlEW6fzo676ejnSgWcMPDjB7vtFgALLnrCAADmLVA= Content-Language: en-us X-OriginalArrivalTime: 04 Feb 2010 02:52:33.0120 (UTC) FILETIME=[196A3E00:01CAA545] Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 02:51:50 -0000 In response to (http://www.ietf.org/mail-archive/web/dispatch/current/msg01291.html ) Henry Sinnreich said: "No problems at all with XMPP, except sharing the same problem with SIP, SIMPLE and all the proprietary IM protocols that are dominant in the IM market (no names mentioned here): Too complex for generalists Web application developers to afford the time and resources to learn and to use." [BA] Despite all the extensions (see http://xmpp.org/extensions/ ), XMPP as described in RFC 3920bis and 3921bis is not a complex protocol, nor is it difficult to incorporate XMPP into applications. Have you seen the XMPP SDKs that are available? Some of them (like SleekXMPP) are incredibly powerful and easy to use. Chapter 14 of the O'Reilly book "XMPP: The Definitive Guide" by Peter St. Andre provides an example "micro-blogging" application written using SleekXMPP that requires very little Python code, and is easy to understand even if you don't know much Python. Now that XMPP is a supported platform within the Google cloud platform, I expect that the situation will only get better. Henry said: "There is no reason not to replace them all with HTTP transport and APIs for the client and/or server applications." [BA] Since there are XMPP SDKs available for PHP, Python and any other web development environment you might desire, using XMPP over HTTP should not require much beyond support for BOSH: http://xmpp.org/extensions/xep-0124.html http://xmpp.org/extensions/xep-0206.html Henry said: "The biggest work item IMO is replacing the stale and problematic SDP with metadata as detailed in section 2.3.3 and thus also fixing the non-compliance of SIP with "UNSAF" RFC 3424. Our I-D deals only with SIP at this point. Replacing SDP and its consequences for NAT traversal requires indeed some work, possibly not in scope here." [BA] I'd be interested in your take on the XMPP session description and codec functionality: http://xmpp.org/extensions/xep-0167.html http://xmpp.org/extensions/xep-0266.html http://xmpp.org/extensions/xep-0181.html http://xmpp.org/extensions/xep-0176.html From bernie@ietf.hoeneisen.ch Thu Feb 4 01:17:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142543A6A91; Thu, 4 Feb 2010 01:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KROBdAa90J5U; Thu, 4 Feb 2010 01:17:01 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 1F9893A6A8F; Thu, 4 Feb 2010 01:17:00 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NcxqK-0006i5-G5; Thu, 04 Feb 2010 10:17:44 +0100 Date: Thu, 4 Feb 2010 10:17:44 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF DISPATCH list , IETF ENUM list , dnsop@ietf.org, dnsext@ietf.org, EPP Provreg Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [dispatch] BOF / New Mailing List E2MD (E.164 To MetaData) DDDS application X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 09:17:02 -0000 Dear DNS, ENUM and RAI experts, Please be informed that a new mailing list has been created for discussion related to a proposed DDDS application 'E.164 to MetaData' (E2MD). If you are interested in this topic, please subscribe to the new Mailing List via: https://www.ietf.org/mailman/listinfo/e2md E2MD is proposed to hold E.164-related information that does not fit the normal use cases for E2U. Known use cases include information that describes the structure of the E.164 numbering plan, and records which do not represent end-user communication URIs. A BOF about E2MD has been proposed for the upcoming IETF in Anaheim: http://trac.tools.ietf.org/bof/trac/#RAI Note: E2MD has been formerly known as E2M (a naming conflict with a legacy SIP WG item required a change of the acronym for this BOF) cheers, Bernie From john.elwell@siemens-enterprise.com Thu Feb 4 01:43:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2803A6AF2 for ; Thu, 4 Feb 2010 01:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiRXL9WMXpqR for ; Thu, 4 Feb 2010 01:43:03 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A2F343A6AE0 for ; Thu, 4 Feb 2010 01:43:02 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-773982; Thu, 4 Feb 2010 10:43:47 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 3C45723F0278; Thu, 4 Feb 2010 10:43:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 4 Feb 2010 10:43:47 +0100 From: "Elwell, John" To: Henry Sinnreich , dispatch mailing list Date: Thu, 4 Feb 2010 10:43:45 +0100 Thread-Topic: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: Acqk/TLV2aIfjAsHN0W0EOLjGZc8KgAgGbYg Message-ID: References: <4B69B30E.3010909@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 09:43:03 -0000 Henry, Where the draft talks about "porting core SIP functions to standards XML ba= sed API" (section 4.5), can you shed some more light on this? Is it just a = case of adopting existing SIP semantics and defining a new syntax (XML)? If= so, this would seem to require the web application to support the same com= plex SIP state machine, with its notions of transactions, dialogs, early di= alogs, backwards compatibility capabilities, tolerance of unreliable transp= orts, offer-answer rules, and at least some of the many SIP extensions. Or = had you intended some sort of simplification, and if so can you give more d= etail? Thanks, John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich > Sent: 03 February 2010 18:18 > To: dispatch mailing list > Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt >=20 > We have published an I-D on "SIP APIs for Web Communications"=20 > and would > appreciate any comments and input. >=20 > Here is the link and the announcement: >=20 > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap > is-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : SIP APIs for Communications on the Web > Author(s) : H. Sinnreich, A. Johnston > Filename : draft-sinnreich-sip-web-apis-00.txt > Pages : 19 > Date : 2010-1-19 > =20 > Interactive communications are becoming part of rich Internet > applications (RIA). This can be accomplished entirely by using Web > technology and developing it as an Internet standard. Voice over IP > (VoIP) features developed for Session Initiation Protocol (SIP 2.0) > can be preserved in rich multimedia communications and applications > on the web. Hyper Text Transport Protocol (HTTP) is used=20 > for control > and signaling data and RTP for interactive media transport > respectively. No other network application protocols are required. > Web, fixed and mobile device application development tools can thus > be used to include components and widgets for Internet presence, > Instant Messaging (IM), voice and video. This opens Internet > communications, including voice to application developers and will > also enhance the user experience with real-time Web and mobile > communications. Usage scenarios include service providers, private > IP networks, device application developers and media companies > providing a mix of integrated communications, applications=20 > and media. > This memo argues for the development and standardization of > Application Programming Interfaces (APIs) to allow the benefits of > SIP to be used by Rich Internet Applications (RIA), for fixed and > mobile devices. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap > is-00.txt >=20 > ------ End of Forwarded Message >=20 > Thanks in advance for your comments. >=20 > Henry >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From andrew.hutton@siemens-enterprise.com Thu Feb 4 02:11:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7608A3A6BD3 for ; Thu, 4 Feb 2010 02:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul6eFBNf5wAL for ; Thu, 4 Feb 2010 02:11:05 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5B61D3A6BD1 for ; Thu, 4 Feb 2010 02:11:02 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-774050; Thu, 4 Feb 2010 11:11:47 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4ED991EB82B0; Thu, 4 Feb 2010 11:11:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 4 Feb 2010 11:11:47 +0100 From: "Hutton, Andrew" To: "Jain, Rajnish" , Dave Smith , Henry Lum , Leon Portman , "dispatch@ietf.org" Date: Thu, 4 Feb 2010 11:12:11 +0100 Thread-Topic: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAEEoz2AADJZSAAAw1mQgAAJibMAASCQkIA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E306EEA7A11D@MCHP058A.global-ad.net> References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com><07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF740537930D@NAHALD.us.int.genesyslab.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_101C6067BEC68246B0C3F6843BCCC1E306EEA7A11DMCHP058Agloba_" MIME-Version: 1.0 Cc: "krehor@cisco.com" Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 10:11:23 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E306EEA7A11DMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I can see that the recorded session could in theory be something other than= a SIP session however I think that for the purposes of this draft and the = working group which we hope will be formed shortly that we should assume th= at the recorded session is a SIP session. We have requirements and proposed charter text that impact the recorded ses= sion and will require protocol to be defined. Of course the recording client can be a SIP gateway which provides interwor= king with other protocols but this is outside the scope so I think we shoul= d state that the recorded session is a SIP session. Regards Andy ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Jain, Rajnish Sent: 02 February 2010 23:43 To: Dave Smith; Henry Lum; Leon Portman; dispatch@ietf.org Cc: krehor@cisco.com Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Dave, Inline: From: Dave Smith [mailto:Dave.Smith@genesyslab.com] Sent: Tuesday, February 02, 2010 5:33 PM To: Jain, Rajnish; Henry Lum; Leon Portman; dispatch@ietf.org Cc: krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Raj, Regarding this input: [rj] The SRP, which manages how the recording media gets delivered to the r= ecorders, is based on SIP (SRP is a set of extensions to the SIP core proto= col). The sessions that SRP manages are called "Recording Sessions" and the= y are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The s= essions that get actually recorded (e.g. communication between a call cente= r agent and an external caller) may or may not be SIP (this depends on the = kind of the PBX phone the agent). Can you please provide a few examples of the different types of protocols t= hat might be possible/practical for the sessions that get actually recorded= (which are dependent on the kind of PBX phone used)? [rj] This can range anywhere from proprietary VoIP media and signaling prot= ocols to things such as SCCP, UNISTIM, H.323, TDM and analog phones. Most s= uch phones are not SIP UAs. Some other entity (such as a SIP-enabled mixer)= may provide the RC media forking point functionality in these cases. Thanks, Raj From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] Sent: Monday, February 01, 2010 3:28 PM To: Henry Lum; Leon Portman; dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Henry, Thanks for your comments. Inline: - Section 3 - Recording Client - If the SRP requirement does not man= date to use SIP as the actual recording protocol, why does the recording cl= ient have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual= call to be recorded) that can be not SIP based and Recording Session (part= of SRP) that is used for triggering recording and it is SIP based. So both= RC and RS are SIP UA. [[hlum]] I now understand that the recorded session does not have to be SIP= based, but the wording in the definition of SRP itself mentions that it ma= y be SIP; then why does RC and RS have to be a SIP UA if SRP does not have = to be SIP? [rj] The SRP, which manages how the recording media gets delivered to the r= ecorders, is based on SIP (SRP is a set of extensions to the SIP core proto= col). The sessions that SRP manages are called "Recording Sessions" and the= y are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The s= essions that get actually recorded (e.g. communication between a call cente= r agent and an external caller) may or may not be SIP (this depends on the = kind of the PBX phone the agent). - Section 4 - use case 5 - if the recording can include recording fo= r an IVR application (ie. VoiceXML application), does that mean the call me= tadata must include application contexts as well? [LeonP] Yes, like specific script or input results [[hlum]] I assume what kind of call metadata and how it is delivered is out= side of the scope of this document? [rj] Correct. o REQ-003 - it's unclear what is the target of the recording session here= since this not directly related to a single recorded session (perhaps many= ) [LeonP] To minimize media clipping associated with recording initiation [[hlum]] You actually answered my question above about what a persistent re= cording mean and why it's useful, but what is unclear to me that is whether= there is something called a persistent recording session that targets some= thing like an agent device. [rj] I guess, Persistent Recording is a bit confusing term (we've received = other feedback on this as well). If I can use the term always-on recording = from the wing-srtp draft then these sessions get established when the agent= logs on and torn off when the agent logs off. Codecs such as G.729 and G.7= 11 with VAD are used to ensure that silence is not recorded (for instance, = when the agent isn't on a call). o REQ-009 - the wording here is a bit unclear here. Do you mean the recor= ded session represents a multi-party session where there are multiple media= streams from multiple recorded sessions, and the media streams may be mixe= d by a conference mixer? [LeonP] It is more for trading floor environments where multiple concurren= t calls on the same device (turret) recorded together. It is not related to= summation for conference participants at the same call. [[hlum]] I'm not familiar with trading floor environments so I may not unde= rstand the intent here. If you have multiple concurrent calls then wouldn't= you have multiple recording sessions to describe each call individually? D= oes the endpoint device perform mixing function for multiple calls so that'= s why you need to club them together in a single recording session? [rj] Due to bandwidth and other cost burdens, the customer demand is that y= ou mix multiple _recorded sessions_ in a single _recording session_. o REQ-028 - the wording redirected looks out of context here; the require= ment only applies when recording client initiates a recording session to an= available recorder server? [LeonP] We want to support both directions [[hlum]] Okay, then I think we should re-word to mention something about av= ailability in general. (eg. "A request for a new recording session must re= ach an available recording client or server"). [rj] The example test you quoted doesn't reflect the actual intent here. Th= e reason for supporting both directions is dependent on where the policy to= record or not resides - RC or RS. The INVITE always comes from either of t= hese two places. Thanks, Raj Jain ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. --_000_101C6067BEC68246B0C3F6843BCCC1E306EEA7A11DMCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I can see that the recorded session could in theor= y be=20 something other than a SIP session however I think that for the purposes of= this=20 draft and the working group which we hope will be formed shortly that we sh= ould=20 assume that the recorded session is a SIP session.
 
We have requirements and proposed charter=20 text that impact the recorded session and will require protocol to be= =20 defined.
 
Of course the recording client can be a SIP gatewa= y which=20 provides interworking with other protocols but this is outside the scope so= I=20 think we should state that the recorded session is a SIP=20 session.
 
Regards
Andy
 
 
From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O= f=20 Jain, Rajnish
Sent: 02 February 2010 23:43
To: Dave= =20 Smith; Henry Lum; Leon Portman; dispatch@ietf.org
Cc:=20 krehor@cisco.com
Subject: Re: [dispatch] Comments=20 ondraft-rehor-dispatch-session-recording-req-00

Dave,=

 

Inline:

 

From:<= /B> Dave Smith=20 [mailto:Dave.Smith@genesyslab.com]
Sent: Tuesday, February 02, 2= 010=20 5:33 PM
To: Jain, Rajnish; Henry Lum; Leon Portman;=20 dispatch@ietf.org
Cc: krehor@cisco.com
Subject: RE:=20 [dispatch] Comments=20 ondraft-rehor-dispatch-session-recording-req-00

=

 

Raj,

Regarding this input:

[rj] T= he SRP,=20 which manages how the recording media gets delivered to the recorders, is b= ased=20 on SIP (SRP is a set of extensions to the SIP core protocol). The sessions = that=20 SRP manages are called “Recording Sessions” and they are SIP se= ssions.=20 Therefore, RC and RS are, by definition, SIP UAs. The sessions that get act= ually=20 recorded (e.g. communication between a call center agent and an external ca= ller)=20 may or may not be SIP (this depends on the kind of the PBX phone the agent)= .=20

 

Can you please provide a few examples of the different= types=20 of protocols that might be possible/practical for the sessions that get actually=20 recorded (which are dependent on the kind of PBX phone=20 used)?

 

[rj] This can range any= where=20 from proprietary VoIP media and signaling protocols to things such as SCCP,= =20 UNISTIM, H.323, TDM and analog phones. Most such phones are not SIP UAs. So= me=20 other entity (such as a SIP-enabled mixer) may provide the RC media forking= =20 point functionality in these cases.

 

Thanks,

Raj

 

From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.co= m]=20
Sent: Monday, February 01, 2010 3:28 PM
To: Henry Lum;= Leon=20 Portman; dispatch@ietf.org
Cc: Dave Smith;=20 krehor@cisco.com
Subject: RE: [dispatch] Comments=20 ondraft-rehor-dispatch-session-recording-req-00

 

Henry,

 

Thanks for your comment= s.=20 Inline:

 

-      &= nbsp;=20 Section 3 – Recording Client – If the S= RP requirement=20 does not mandate to use SIP as the actual recording protocol, why does the= =20 recording client have to be a SIP user agent or B2BUA?

[LeonP] Actually there is a difference between R= ecorded=20 session (the actual call to be recorded) that can be not SIP based and Reco= rding=20 Session (part of SRP) that is used for triggering recording and it is SIP b= ased.=20 So both RC and RS are SIP UA.

[[hlum]] I now understand = that the=20 recorded session does not have to be SIP based, but the wording in the=20 definition of SRP itself mentions that it may be SIP; then why does RC and = RS=20 have to be a SIP UA if SRP does not have to be SIP?

 

[rj] The SRP, which man= ages how=20 the recording media gets delivered to the recorders, is based on SIP (SRP i= s a=20 set of extensions to the SIP core protocol). The sessions that SRP manages = are=20 called “Recording Sessions” and they are SIP sessions. Therefor= e, RC and RS are,=20 by definition, SIP UAs. The sessions that get actually recorded (e.g.=20 communication between a call center agent and an external caller) may or ma= y not=20 be SIP (this depends on the kind of the PBX phone the agent).=20

 

 

-      &= nbsp;=20 Section 4 – use case 5 – if the recordi= ng can include=20 recording for an IVR application (ie. VoiceXML application), does that mean= the=20 call metadata must include application contexts as well?

[LeonP] Yes, like specific script or input=20 results

[[hlum]] I assume what kin= d of call=20 metadata and how it is delivered is outside of the scope of this=20 document?

 

[rj]=20 Correct.

 

= o  =20 REQ-003 – it’s unclear what is t= he target of the=20 recording session here since this not directly related to a single recorded= =20 session (perhaps many)

[LeonP] To minimize media clipping associated wi= th=20 recording initiation

[[hlum]] You actually answ= ered my=20 question above about what a persistent recording mean and why it’s us= eful, but=20 what is unclear to me that is whether there is something called a persisten= t=20 recording session that targets something like an agent=20 device.

 

[rj] I guess, Persisten= t=20 Recording is a bit confusing term (we’ve received other feedback on t= his as=20 well). If I can use the term always-on recording from the wing-srtp draft t= hen=20 these sessions get established when the agent logs on and torn off when the= =20 agent logs off. Codecs such as G.729 and G.711 with VAD are used to ensure = that=20 silence is not recorded (for instance, when the agent isn’t on a=20 call).

 

= o  =20 REQ-009 – the wording here is a bit un= clear here.=20 Do you mean the recorded session represents a multi-party session where the= re=20 are multiple media streams from multiple recorded sessions, and the media=20 streams may be mixed by a conference mixer?

[LeonP]  It is=20 more for trading floor environments where multiple concurrent calls on the = same=20 device (turret) recorded together. It is not related to summation for confe= rence=20 participants at the same call.

[[hlum]] I’m not fam= iliar with=20 trading floor environments so I may not understand the intent here. If you = have=20 multiple concurrent calls then wouldn’t you have multiple recording s= essions to=20 describe each call individually? Does the endpoint device perform mixing=20 function for multiple calls so that’s why you need to club them toget= her in a=20 single recording session?

 

[rj] Due to bandwidth a= nd other=20 cost burdens, the customer demand is that you mix multiple _recorded=20 sessions_ in a single _recording session_.

 

 

= o  =20 REQ-028 – the wording redirected looks= out of=20 context here; the requirement only applies when recording client initiates = a=20 recording session to an available recorder server?

[LeonP] We want to support both=20 directions

[[hlum]] Okay, then I thin= k we=20 should re-word to mention something about availability in general.  (e= g. “A=20 request for a new recording session must reach an available recording clien= t or=20 server”).

 

[rj] The example test y= ou quoted=20 doesn’t reflect the actual intent here. The reason for supporting bot= h=20 directions is dependent on where the policy to record or not resides –= ; RC or RS.=20 The INVITE always comes from either of these two places.<= /P>

 

Thanks,

Raj Jain

 

 

DISCLAIMER: This e-mail may contain information that i= s=20 confidential, privileged or otherwise protected from disclosure. If you are= not=20 an intended recipient of this e-mail, do not duplicate or redistribute it b= y any=20 means. Please delete it and any attachments and notify the sender that you = have=20 received it in error. Unintended recipients are prohibited from taking acti= on on=20 the basis of information in this e-mail.E-mail messages may contain compute= r=20 viruses or other defects, may not be accurately replicated on other systems= , or=20 may be intercepted, deleted or interfered with without the knowledge of the= =20 sender or the intended recipient. If you are not comfortable with the risks= =20 associated with e-mail messages, you may decide not to use e-mail to commun= icate=20 with IPC. IPC reserves the right, to the extent and under circumstances=20 permitted by applicable law, to retain, monitor and intercept e-mail messag= es to=20 and from its systems.

 

&nbs= p;


CONFI= DENTIALITY=20 NOTICE: This e-mail and any files attached may contain confidential and=20 proprietary information of Alcatel-Lucent and/or its affiliated entities. A= ccess=20 by the intended recipient only is authorized. Any liability arising from an= y=20 party acting, or refraining from acting, on any information contained in th= is=20 e-mail is hereby excluded. If you are not the intended recipient, please no= tify=20 the sender immediately, destroy the original transmission and its attachmen= ts=20 and do not disclose the contents to any other person, use it for any purpos= e, or=20 store or copy the information in any medium. Copyright in this e-mail and a= ny=20 attachments belongs to Alcatel-Lucent and/or its affiliated=20 entities.

--_000_101C6067BEC68246B0C3F6843BCCC1E306EEA7A11DMCHP058Agloba_-- From gonzalo.camarillo@ericsson.com Thu Feb 4 04:12:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DC83A6BF7 for ; Thu, 4 Feb 2010 04:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3al3EwthaIBm for ; Thu, 4 Feb 2010 04:12:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 227C83A6C29 for ; Thu, 4 Feb 2010 04:11:53 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-0b-4b6ab9b69b94 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D2.DA.02429.6B9BA6B4; Thu, 4 Feb 2010 13:12:38 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 13:12:38 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 13:12:38 +0100 Message-ID: <4B6AB9B6.9030607@ericsson.com> Date: Thu, 04 Feb 2010 14:12:38 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "R.Jesske@telekom.de" References: <9886E5FCA6D76549A3011068483A4BD4058CE47C@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4058CE47C@S4DE8PSAAQB.mitte.t-com.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Feb 2010 12:12:38.0566 (UTC) FILETIME=[57D25C60:01CAA593] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Interworking of Responses X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 12:12:17 -0000 Hi, talking as a chair, most of the discussions we had last time were about using Reason in responses versus using encapsulated ISUP REL messages. Some people claimed that REL messages are rather small and that the overhead of both approaches would be comparable. I suggest you try and address those concerns. Thanks, Gonzalo DISPATCH co-chair R.Jesske@telekom.de wrote: > Dear all, > The discussion about the use of the Reason header within responses was > triggered by the used case where ISUP-SIP-ISUP traversal will happen > without using SIP-T. > > During the discussion at the last IETF meeting it was asked how the pure > mapping of ISUP Cause to SIP Response and back will cause the ISUP > network. Here is the consideration of this issue. > > The case where a call will be released within a pure ISUP network it > will cause a announcement based on the ISUP Release Cause. > > When the call instead has to traverse a SIP network the ISUP cause will > change in most of the cases and the related announcement. > > The figure below shows the principle of such a call ISUP-SIP-ISUP. > > Phone PTSN SWITCH Gateway A Gateway B > B > > | | | | | > | Setup Message| | > | | > | Phone | IAM | | | > |-------------->|------------------>| INVITE | | > | | |----------------->| IAM | > | | | 100 Trying |----------------->| > | | |<-----------------| 100 Trying | > | | | 403 Forbidden | | > | | | Reason Q850 #87 | REL Cause #87 | > | play | REL Cause #87 | > |<-----------------| > | Announcement | |<-----------------| | > |<--------------|<----------------- | | | > | | | | | > | | | | | > | | | | | > > The table below shows now the mappings of the Cause and the relating > announcements > Problem is that the mapping regarding RFC 3398 will result in the > following table. > > EXAMPLE: > The Call is released with Cause 27 from the user B > This Cause will normally trigger an announcement B. > > Due to the rules in ISUP the Announcement/Tone is put into the media > path at the originating switch. > > So the first gateway maps (RFC3398) the ISUP RELEASE message with Cause > 27 to a SIP response 502 Bad Gateway > > Now mapping back (RFC3398) to ISUP the release cause 38 will be taken > and this Release Cause will trigger an congestion tone. > > The following table shows now the mapping for our PSTN network and the > corresponding announcements. > > Mapping ISUP SIP GW-B Mapping SIP ISUP GW-A > ------------------------> ------------------> > > ISUP Tone or ISUP > CAUSE Announcement SIP Response CAUSE > Tone or Announcement > > 1 ANNOUNC. A 404 Not Found 1 ANNOUNC. A > *2 ANNOUNC. C 404 Not found 1 ANNOUNC. A > 3 ANNOUNC. A 404 Not found 1 ANNOUNC. A > 16 Congestion tone --- (*) > 17 Busy Tone 486 Busy here 17 Busy tone > *18 Busy Tone 408 Request Timeout 102 > Congestion tone > 19 Busy Tone 480 Temporarily unavailable 18 Busy tone > *20 ANNOUNC. B 480 Temporarily unavailable 18 Busy tone > 21 ANNOUNC. B 403 Forbidden (+) 21 > ANNOUNC. B > 22 ANNOUNC. A 410 Gone 22 ANNOUNC. A > *23 Congestion tone 410 Gone 22 ANNOUNC. A > *26 Congestion tone 404 Not Found (=) 1 ANNOUNC. A > > *27 ANNOUNC. B 502 Bad Gateway 38 > Congestion tone > > *28 Congestion tone 484 Address incomplete 28 > Congestion tone > 29 ANNOUNC. D 501 Not implemented 79 ANNOUNC. D > *31 Congestion tone 480 Temporarily unavailable 18 Busy tone > 34 Congestion tone 503 Service unavailable 41 > Congestion tone > 38 Congestion tone 503 Service unavailable 41 > Congestion tone > 41 Congestion tone 503 Service unavailable 41 > Congestion tone > *42 ANNOUNC. B 503 Service unavailable 41 > Congestion tone > 47 Congestion tone 503 Service unavailable 41 > Congestion tone > *55 ANNOUNC. D 403 Forbidden 21 ANNOUNC. B > *57 ANNOUNC. D 403 Forbidden 21 ANNOUNC. B > 58 Congestion tone 503 Service unavailable 41 > Congestion tone > *65 ANNOUNC. D 488 Not Acceptable Here 127 > Congestion tone (**) > *70 ANNOUNC. D 488 Not Acceptable Here 127 > Congestion tone (**) > 79 ANNOUNC. D 501 Not implemented 79 > ANNOUNC. D > *87 ANNOUNC. D 403 Forbidden 21 ANNOUNC. B > *88 ANNOUNC. D 503 Service unavailable 41 > Congestion tone > 102 Congestion tone 504 Gateway timeout 102 > Congestion tone > *111 ANNOUNC. D 500 Server internal error 41 > Congestion tone > 127 Congestion tone 500 Server internal error 41 > Congestion tone > > (*) Announcement change due to passing the SIP domain > (**)No mapping in RFC 3398 described in the field 127 is used then as > default mapping. > > Half of the mapped Responses will end in a ISUP Cause that will initiate > an other announcement than intended from the originator of the Release > cause. > > That is why a mapping of a Release Cause into an Reason Header and back > to the ISUP cause will help in an easy using an existing SIP header that > is intended to carry ISUP causes. > > > Kind regards > Roland Jesske > > > Deutsche Telekom Netzproduktion GmbH > Technical Engineering Center > Roland Jesske > Heinrich-Hertz-Straße 3-7, 64295 Darmstadt, Germany > +49 6151 628-2766 (Phone) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobile) > E-Mail: r.jesske@telekom.de > www.telekom.com > > Life is for sharing. > > Deutsche Telekom Netzproduktion GmbH > Supervisory Board: Dr. Steffen Roehn (Chairman) > Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert Matheis, > Klaus Peren > Commercial register: Local court Bonn HRB 14190 > Registered office: Bonn > VAT identification no. DE 814645262 > From alan.b.johnston@gmail.com Thu Feb 4 05:36:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAFF28C1AA for ; Thu, 4 Feb 2010 05:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD5Ka+qi+qdM for ; Thu, 4 Feb 2010 05:36:08 -0800 (PST) Received: from mail-iw0-f184.google.com (mail-iw0-f184.google.com [209.85.223.184]) by core3.amsl.com (Postfix) with ESMTP id E5BF23A6C07 for ; Thu, 4 Feb 2010 05:36:07 -0800 (PST) Received: by iwn14 with SMTP id 14so2754949iwn.17 for ; Thu, 04 Feb 2010 05:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=QWJOW/9/CLpzc9Kh99u0Dw58x7XE+LHG4YrP3FRVu4A=; b=SAnKLRDF351j4+zxCIzH6syXRf19SqKB46M+U7P4FmRcZYOZR0hMK8if0Chg9w2gxr 40HktmqqSOHuHtu+NeDb+I7MsfFDCPy8KTbtiyZkcHlsUcS9kJvq614iPt5wpeQUghMZ AE9EU3WGwyx6A+rqD2wsU28hWqfFGj4d9ipOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=fCCMWDxXFVkWB3mAjkaFgMffRC9PnIJyrIt5OyyUXv7g755CxcUcFsBx52tDg4ElPy uJHEVjp2URi/6dZ7eTY5Pr6yW1a5Kp0NwpDEfU/TcUgRGakWycILzSmccnQDo0VsIG3X 1K9Ypt9+NZEBWGJ9Va0ll5R1pSB//wKMpnhWw= Received: by 10.231.145.20 with SMTP id b20mr1282821ibv.78.1265290608767; Thu, 04 Feb 2010 05:36:48 -0800 (PST) Received: from Alans-PowerBook-G4-17.local (24-107-197-239.dhcp.stls.mo.charter.com [24.107.197.239]) by mx.google.com with ESMTPS id 23sm109758iwn.3.2010.02.04.05.36.44 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 05:36:45 -0800 (PST) Message-ID: <4B6ACD6A.3030706@gmail.com> Date: Thu, 04 Feb 2010 07:36:42 -0600 From: Alan Johnston User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: <4B69B30E.3010909@gmail.com> In-Reply-To: X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch mailing list Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 13:36:09 -0000 John, Thanks for your comments. We are not thinking about just an XML encoding for SIP - you are correct, that would still expose way too much complexity. We were thinking about starting with the functionality in RFC 5638, then see how much we can abstract and separate the "plumbing" of SIP from what an app developer needs/cares about. We hope to avoid replicating the entire SIP state machine. However, this is just a starting point, and feedback and input from others who share our goal is most welcome. - Alan - On 2/4/10 3:43 AM, Elwell, John wrote: > Henry, > > Where the draft talks about "porting core SIP functions to standards XML based API" (section 4.5), can you shed some more light on this? Is it just a case of adopting existing SIP semantics and defining a new syntax (XML)? If so, this would seem to require the web application to support the same complex SIP state machine, with its notions of transactions, dialogs, early dialogs, backwards compatibility capabilities, tolerance of unreliable transports, offer-answer rules, and at least some of the many SIP extensions. Or had you intended some sort of simplification, and if so can you give more detail? > > Thanks, > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich >> Sent: 03 February 2010 18:18 >> To: dispatch mailing list >> Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt >> >> We have published an I-D on "SIP APIs for Web Communications" >> and would >> appreciate any comments and input. >> >> Here is the link and the announcement: >> >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap >> is-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : SIP APIs for Communications on the Web >> Author(s) : H. Sinnreich, A. Johnston >> Filename : draft-sinnreich-sip-web-apis-00.txt >> Pages : 19 >> Date : 2010-1-19 >> >> Interactive communications are becoming part of rich Internet >> applications (RIA). This can be accomplished entirely by using Web >> technology and developing it as an Internet standard. Voice over IP >> (VoIP) features developed for Session Initiation Protocol (SIP 2.0) >> can be preserved in rich multimedia communications and applications >> on the web. Hyper Text Transport Protocol (HTTP) is used >> for control >> and signaling data and RTP for interactive media transport >> respectively. No other network application protocols are required. >> Web, fixed and mobile device application development tools can thus >> be used to include components and widgets for Internet presence, >> Instant Messaging (IM), voice and video. This opens Internet >> communications, including voice to application developers and will >> also enhance the user experience with real-time Web and mobile >> communications. Usage scenarios include service providers, private >> IP networks, device application developers and media companies >> providing a mix of integrated communications, applications >> and media. >> This memo argues for the development and standardization of >> Application Programming Interfaces (APIs) to allow the benefits of >> SIP to be used by Rich Internet Applications (RIA), for fixed and >> mobile devices. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap >> is-00.txt >> >> ------ End of Forwarded Message >> >> Thanks in advance for your comments. >> >> Henry >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From rajnish.jain@ipc.com Thu Feb 4 05:50:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926593A6D12 for ; Thu, 4 Feb 2010 05:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaEvEHAQKGeD for ; Thu, 4 Feb 2010 05:50:11 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by core3.amsl.com (Postfix) with ESMTP id C12593A6D11 for ; Thu, 4 Feb 2010 05:50:07 -0800 (PST) Received: from unknown [65.244.37.52] (EHLO p01c11o149.mxlogic.net) by p01c11o149.mxlogic.net(mxl_mta-6.5.0-0) with ESMTP id 1c0da6b4.c9f7db90.77910.00-411.186303.p01c11o149.mxlogic.net (envelope-from ); Thu, 04 Feb 2010 06:50:57 -0700 (MST) X-MXL-Hash: 4b6ad0c10d744a0b-099892b05661d8615cb27969c2099fe29e1efed6 Received: from unknown [65.244.37.52] (EHLO smtp.ipc.com) by p01c11o149.mxlogic.net(mxl_mta-6.5.0-0) over TLS secured channel with ESMTP id ea0da6b4.0.77889.00-016.186247.p01c11o149.mxlogic.net (envelope-from ); Thu, 04 Feb 2010 06:50:41 -0700 (MST) X-MXL-Hash: 4b6ad0b13ce266e3-f21818a7aa12755cc25a6aa918b495bf17898efe Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.247]) by STSNYHTCAS2.corp.root.ipc.com ([10.201.40.93]) with mapi; Thu, 4 Feb 2010 08:50:38 -0500 From: "Jain, Rajnish" To: "Hutton, Andrew" , Dave Smith , Henry Lum , Leon Portman , "dispatch@ietf.org" Date: Thu, 4 Feb 2010 08:50:37 -0500 Thread-Topic: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQAEEoz2AADJZSAAAw1mQgAAJibMAASCQkIAAH5baw Message-ID: References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com><07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF740537930D@NAHALD.us.int.genesyslab.com> <101C6067BEC68246B0C3F6843BCCC1E306EEA7A11D@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E306EEA7A11D@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.000.1038-17172.004 x-tm-as-result: No--58.030800-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=1.0 c=1 a=D4USGbs0y0J827gn68Ljfg==:17 a=ag3Orf1RAAAA:8 a] X-AnalysisOut: [=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=Tn40LXQWAAAA:8 a=vvKfUc] X-AnalysisOut: [gjAAAA:8 a=wKJGeZWdawDEohAVch0A:9 a=6hemzV_OKkQycwzQgloA:7] X-AnalysisOut: [ a=N4O89i-XGNpkMK5AwS_dK-9MdBcA:4 a=KwNp_X_GjOYA:10 a=lZB8] X-AnalysisOut: [15dzVvQA:10 a=JfD0Fch1gWkA:10 a=Pw_wLAgS6uQA:10 a=OeN1TrMy] X-AnalysisOut: [pwAA:10 a=qNmcPvwWLBWMKc77:21 a=G3vhxxUYVr-yQFFi:21] Cc: "krehor@cisco.com" Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 13:50:12 -0000 I agree with this proposal in the interest of moving this work forward. Regards, Raj From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: Thursday, February 04, 2010 5:12 AM To: Jain, Rajnish; Dave Smith; Henry Lum; Leon Portman; dispatch@ietf.org Cc: krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 I can see that the recorded session could in theory be something other than= a SIP session however I think that for the purposes of this draft and the = working group which we hope will be formed shortly that we should assume th= at the recorded session is a SIP session. =A0 We=A0have requirements and proposed charter text=A0that impact the recorded= session and will require protocol to be defined. =A0 Of course the recording client can be a SIP gateway which provides interwor= king with other protocols but this is outside the scope so I think we shoul= d state that the recorded session is a SIP session. =A0 Regards Andy =A0 =A0 ________________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Jain, Rajnish Sent: 02 February 2010 23:43 To: Dave Smith; Henry Lum; Leon Portman; dispatch@ietf.org Cc: krehor@cisco.com Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Dave, Inline: From: Dave Smith [mailto:Dave.Smith@genesyslab.com]=20 Sent: Tuesday, February 02, 2010 5:33 PM To: Jain, Rajnish; Henry Lum; Leon Portman; dispatch@ietf.org Cc: krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Raj, Regarding this input: [rj] The SRP, which manages how the recording media gets delivered to the r= ecorders, is based on SIP (SRP is a set of extensions to the SIP core proto= col). The sessions that SRP manages are called "Recording Sessions" and the= y are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The s= essions that get actually recorded (e.g. communication between a call cente= r agent and an external caller) may or may not be SIP (this depends on the = kind of the PBX phone the agent).=20 Can you please provide a few examples of the different types of protocols t= hat might be possible/practical for the sessions that get actually recorded= (which are dependent on the kind of PBX phone used)? [rj] This can range anywhere from proprietary VoIP media and signaling prot= ocols to things such as SCCP, UNISTIM, H.323, TDM and analog phones. Most s= uch phones are not SIP UAs. Some other entity (such as a SIP-enabled mixer)= may provide the RC media forking point functionality in these cases.=20 Thanks, Raj From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com]=20 Sent: Monday, February 01, 2010 3:28 PM To: Henry Lum; Leon Portman; dispatch@ietf.org Cc: Dave Smith; krehor@cisco.com Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Henry, Thanks for your comments. Inline: -=A0=A0=A0=A0=A0=A0=A0 Section 3 - Recording Client - If the SRP requiremen= t does not mandate to use SIP as the actual recording protocol, why does th= e recording client have to be a SIP user agent or B2BUA? [LeonP] Actually there is a difference between Recorded session (the actual= call to be recorded) that can be not SIP based and Recording Session (part= of SRP) that is used for triggering recording and it is SIP based. So both= RC and RS are SIP UA. [[hlum]] I now understand that the recorded session does not have to be SIP= based, but the wording in the definition of SRP itself mentions that it ma= y be SIP; then why does RC and RS have to be a SIP UA if SRP does not have = to be SIP? [rj] The SRP, which manages how the recording media gets delivered to the r= ecorders, is based on SIP (SRP is a set of extensions to the SIP core proto= col). The sessions that SRP manages are called "Recording Sessions" and the= y are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The s= essions that get actually recorded (e.g. communication between a call cente= r agent and an external caller) may or may not be SIP (this depends on the = kind of the PBX phone the agent).=20 -=A0=A0=A0=A0=A0=A0=A0 Section 4 - use case 5 - if the recording can includ= e recording for an IVR application (ie. VoiceXML application), does that me= an the call metadata must include application contexts as well? [LeonP] Yes, like specific script or input results [[hlum]] I assume what kind of call metadata and how it is delivered is out= side of the scope of this document? [rj] Correct. o=A0=A0 REQ-003 - it's unclear what is the target of the recording session = here since this not directly related to a single recorded session (perhaps = many) [LeonP] To minimize media clipping associated with recording initiation [[hlum]] You actually answered my question above about what a persistent re= cording mean and why it's useful, but what is unclear to me that is whether= there is something called a persistent recording session that targets some= thing like an agent device. [rj] I guess, Persistent Recording is a bit confusing term (we've received = other feedback on this as well). If I can use the term always-on recording = from the wing-srtp draft then these sessions get established when the agent= logs on and torn off when the agent logs off. Codecs such as G.729 and G.7= 11 with VAD are used to ensure that silence is not recorded (for instance, = when the agent isn't on a call). o=A0=A0 REQ-009 - the wording here is a bit unclear here. Do you mean the r= ecorded session represents a multi-party session where there are multiple m= edia streams from multiple recorded sessions, and the media streams may be = mixed by a conference mixer? [LeonP] =A0It is more for trading floor environments where multiple concurr= ent calls on the same device (turret) recorded together. It is not related = to summation for conference participants at the same call. [[hlum]] I'm not familiar with trading floor environments so I may not unde= rstand the intent here. If you have multiple concurrent calls then wouldn't= you have multiple recording sessions to describe each call individually? D= oes the endpoint device perform mixing function for multiple calls so that'= s why you need to club them together in a single recording session? [rj] Due to bandwidth and other cost burdens, the customer demand is that y= ou mix multiple _recorded sessions_ in a single _recording session_. o=A0=A0 REQ-028 - the wording redirected looks out of context here; the req= uirement only applies when recording client initiates a recording session t= o an available recorder server? [LeonP] We want to support both directions [[hlum]] Okay, then I think we should re-word to mention something about av= ailability in general.=A0 (eg. "A request for a new recording session must = reach an available recording client or server").=20 [rj] The example test you quoted doesn't reflect the actual intent here. Th= e reason for supporting both directions is dependent on where the policy to= record or not resides - RC or RS. The INVITE always comes from either of t= hese two places. Thanks, Raj Jain ________________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. =A0 CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. From peter.musgrave@magorcorp.com Thu Feb 4 06:15:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DE23A690A for ; Thu, 4 Feb 2010 06:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0RakWSgzKis for ; Thu, 4 Feb 2010 06:15:49 -0800 (PST) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id E9A8C3A68F5 for ; Thu, 4 Feb 2010 06:15:48 -0800 (PST) Received: by pzk5 with SMTP id 5so3860460pzk.29 for ; Thu, 04 Feb 2010 06:16:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.89.8 with SMTP id r8mr794251rvl.216.1265292993026; Thu, 04 Feb 2010 06:16:33 -0800 (PST) In-Reply-To: <4B6ACD6A.3030706@gmail.com> References: <4B69B30E.3010909@gmail.com> <4B6ACD6A.3030706@gmail.com> Date: Thu, 4 Feb 2010 09:16:32 -0500 Message-ID: <8e5ec72f1002040616r4ac95411k8bb5eb6a8261027a@mail.gmail.com> From: Peter Musgrave To: Alan Johnston , Henry Sinnreich Content-Type: multipart/alternative; boundary=000e0cd138e062db70047ec6fb00 Cc: dispatch mailing list Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 14:15:50 -0000 --000e0cd138e062db70047ec6fb00 Content-Type: text/plain; charset=ISO-8859-1 Henry/Alan, I think some mention of other web technologies in the draft might help frame the effort. e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP-like media constructs, uses ICE and if I recall correctly does put address inside messages). If I had a web API which allowed direct connections to SIP endpoints/media servers I think that would be powerful. In the past I have done things like created a "B2B-like" entity with a Jingle stack and a SIP stack - but then I end up with identity issues and issues with simultaneous sessions to media servers. I agree that a very simple call state machine is desired - even if the SIP mechanics need to be strongly restricted. I also agree that SDP is getting a bit tired. Peter On Thu, Feb 4, 2010 at 8:36 AM, Alan Johnston wrote: > John, > > Thanks for your comments. > > We are not thinking about just an XML encoding for SIP - you are > correct, that would still expose way too much complexity. We were > thinking about starting with the functionality in RFC 5638, then see how > much we can abstract and separate the "plumbing" of SIP from what an app > developer needs/cares about. We hope to avoid replicating the entire > SIP state machine. > > However, this is just a starting point, and feedback and input from > others who share our goal is most welcome. > > - Alan - > > On 2/4/10 3:43 AM, Elwell, John wrote: > > Henry, > > > > Where the draft talks about "porting core SIP functions to standards XML > based API" (section 4.5), can you shed some more light on this? Is it just a > case of adopting existing SIP semantics and defining a new syntax (XML)? If > so, this would seem to require the web application to support the same > complex SIP state machine, with its notions of transactions, dialogs, early > dialogs, backwards compatibility capabilities, tolerance of unreliable > transports, offer-answer rules, and at least some of the many SIP > extensions. Or had you intended some sort of simplification, and if so can > you give more detail? > > > > Thanks, > > > > John > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich > >> Sent: 03 February 2010 18:18 > >> To: dispatch mailing list > >> Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt > >> > >> We have published an I-D on "SIP APIs for Web Communications" > >> and would > >> appreciate any comments and input. > >> > >> Here is the link and the announcement: > >> > >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap > >> is-00.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : SIP APIs for Communications on the Web > >> Author(s) : H. Sinnreich, A. Johnston > >> Filename : draft-sinnreich-sip-web-apis-00.txt > >> Pages : 19 > >> Date : 2010-1-19 > >> > >> Interactive communications are becoming part of rich Internet > >> applications (RIA). This can be accomplished entirely by using Web > >> technology and developing it as an Internet standard. Voice over IP > >> (VoIP) features developed for Session Initiation Protocol (SIP 2.0) > >> can be preserved in rich multimedia communications and applications > >> on the web. Hyper Text Transport Protocol (HTTP) is used > >> for control > >> and signaling data and RTP for interactive media transport > >> respectively. No other network application protocols are required. > >> Web, fixed and mobile device application development tools can thus > >> be used to include components and widgets for Internet presence, > >> Instant Messaging (IM), voice and video. This opens Internet > >> communications, including voice to application developers and will > >> also enhance the user experience with real-time Web and mobile > >> communications. Usage scenarios include service providers, private > >> IP networks, device application developers and media companies > >> providing a mix of integrated communications, applications > >> and media. > >> This memo argues for the development and standardization of > >> Application Programming Interfaces (APIs) to allow the benefits of > >> SIP to be used by Rich Internet Applications (RIA), for fixed and > >> mobile devices. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap > >> is-00.txt > >> > >> ------ End of Forwarded Message > >> > >> Thanks in advance for your comments. > >> > >> Henry > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000e0cd138e062db70047ec6fb00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Henry/Alan,=A0

I think some mention of other web technol= ogies in the draft might help frame the effort.

e.= g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP-like = media constructs, uses ICE and if I recall correctly does put address insid= e messages).=A0

If I had a web API which allowed direct connections to = SIP endpoints/media servers I think that would be powerful. In the past I h= ave done things like created a "B2B-like" entity with a Jingle st= ack and a SIP stack - but then I end up with identity issues and issues wit= h simultaneous sessions to media servers.

I agree that a very simple call state machine is desire= d - even if the SIP mechanics need to be strongly restricted. I also agree = that SDP is getting a bit tired.=A0

Peter

On Thu, Feb 4, 2010 at 8:36 AM, Alan Johnston <alan.b.joh= nston@gmail.com> wrote:
John,

Thanks for your comments.

We are not thinking about just an XML encoding for SIP - you are
correct, that would still expose way too much complexity. =A0We were
thinking about starting with the functionality in RFC 5638, then see how much we can abstract and separate the "plumbing" of SIP from what= an app
developer needs/cares about. =A0We hope to avoid replicating the entire
SIP state machine.

However, this is just a starting point, and feedback and input from
others who share our goal is most welcome.

- Alan -

On 2/4/10 3:43 AM, Elwell, John wrote:
> Henry,
>
> Where the draft talks about "porting core SIP functions to standa= rds XML based API" (section 4.5), can you shed some more light on this= ? Is it just a case of adopting existing SIP semantics and defining a new s= yntax (XML)? If so, this would seem to require the web application to suppo= rt the same complex SIP state machine, with its notions of transactions, di= alogs, early dialogs, backwards compatibility capabilities, tolerance of un= reliable transports, offer-answer rules, and at least some of the many SIP = extensions. Or had you intended some sort of simplification, and if so can = you give more detail?
>
> Thanks,
>
> John
>
>
>> -----Original Message-----
>> From: dispatch-bounce= s@ietf.org
>> [mailto:dispatch-boun= ces@ietf.org] On Behalf Of Henry Sinnreich
>> Sent: 03 February 2010 18:18
>> To: dispatch mailing list
>> Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00= .txt
>>
>> We have published an I-D on "SIP APIs for Web Communications&= quot;
>> and would
>> appreciate any comments and input.
>>
>> Here is the link and the announcement:
>>
>> http://www.ietf.org/internet-drafts/draft-sinnre= ich-sip-web-ap
>> is-00.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories.
>>
>>
>> =A0Title =A0: SIP APIs for Communications on the Web
>> =A0Author(s) : H. Sinnreich, A. Johnston
>> =A0Filename : draft-sinnreich-sip-web-apis-00.txt
>> =A0Pages =A0: 19
>> =A0Date =A0: 2010-1-19
>>
>> =A0 =A0Interactive communications are becoming part of rich Intern= et
>> =A0 =A0applications (RIA). This can be accomplished entirely by us= ing Web
>> =A0 =A0technology and developing it as an Internet standard. Voice= over IP
>> =A0 =A0(VoIP) features developed for Session Initiation Protocol (= SIP 2.0)
>> =A0 =A0can be preserved in rich multimedia communications and appl= ications
>> =A0 =A0on the web. =A0Hyper Text Transport Protocol (HTTP) is used=
>> for control
>> =A0 =A0and signaling data and RTP for interactive media transport<= br> >> =A0 =A0respectively. No other network application protocols are re= quired.
>> =A0 =A0Web, fixed and mobile device application development tools = can thus
>> =A0 =A0be used to include components and widgets for Internet pres= ence,
>> =A0 =A0Instant Messaging (IM), voice and video. =A0This opens Inte= rnet
>> =A0 =A0communications, including voice to application developers a= nd will
>> =A0 =A0also enhance the user experience with real-time Web and mob= ile
>> =A0 =A0communications. =A0Usage scenarios include service provider= s, private
>> =A0 =A0IP networks, device application developers and media compan= ies
>> =A0 =A0providing a mix of integrated communications, applications<= br> >> and media.
>> =A0 =A0This memo argues for the development and standardization of=
>> =A0 =A0Application Programming Interfaces (APIs) to allow the bene= fits of
>> =A0 =A0SIP to be used by Rich Internet Applications (RIA), for fix= ed and
>> =A0 =A0mobile devices.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-sinnre= ich-sip-web-ap
>> is-00.txt
>>
>> ------ End of Forwarded Message
>>
>> Thanks in advance for your comments.
>>
>> Henry
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--000e0cd138e062db70047ec6fb00-- From john.elwell@siemens-enterprise.com Thu Feb 4 06:16:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD473A692C for ; Thu, 4 Feb 2010 06:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2bAkp6plbJK for ; Thu, 4 Feb 2010 06:16:17 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 40EB83A6921 for ; Thu, 4 Feb 2010 06:16:14 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-779048; Thu, 4 Feb 2010 15:16:58 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 202B91EB82AB; Thu, 4 Feb 2010 15:16:58 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 4 Feb 2010 15:16:58 +0100 From: "Elwell, John" To: "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Thu, 4 Feb 2010 15:16:57 +0100 Thread-Topic: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses Thread-Index: Acqf6cQbqABRpT7zRbqNP1YkjuQ6yQAPOZXw Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de> Keywords: DISPATCH In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 14:16:20 -0000 Roland, Another use case we have come across is where we receive from Q.931 during = outgoing call establishment a Disconnect message indicating busy and a prog= ress indicator saying there is an in-band announcement. This needs to be ma= pped to a SIP 183 response (include SDP answer if not already sent), rather= than a final response, so that the caller can hear the announcement from P= STN. However, being able to indicate busy in the Reason header field would = allow an appropriate display on the device. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: 28 January 2010 07:16 > To: dispatch@ietf.org > Subject: [dispatch] ISSUES on=20 > draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in=20 > Responses >=20 > Dear all,=20 > The discussion at the last IETF meeting due to the proposal=20 > to use the reason header within responses where controversial. >=20 > I would like to start the discussion on mentioned concerns.=20 >=20 > One concern was that we define an new encapsulation mechanism=20 > for ISUP elements in parallel to SIP-T.=20 >=20 > The Reason header itself is a SIP generic Header defined in RFC3326.=20 >=20 > The syntax allows to put in a SIP Response code and/or an=20 > ISUP Q.850 Cause Code.=20 >=20 > As many times mentioned before RFC 3326 (The Reason Header=20 > Field for the Session Initiation Protocol (SIP)) defines the=20 > following. >=20 > Initially, the Reason header field defined here appears to be most=20 > useful for BYE and CANCEL requests, but it can appear in=20 > any request=20 > within a dialog, in any CANCEL request and in any response whose=20 > status code explicitly allows the presence of this header field.=20 >=20 > Note that the Reason header field is usually not needed in=20 > responses=20 > because the status code and the reason phrase already provide=20 > sufficient information.=20 >=20 > Clients and servers are free to ignore this header field. =20 > It has no=20 > impact on protocol processing.=20 >=20 > At that time where RFC3326 was written it was not assumed=20 > that a Reason in a response is usually not needed but it does=20 > not restrict the use of the Reason header within responses.=20 > It allows the use of the Reason header if the status code allows it. >=20 > That was the reasoning for writing this draft to allow the=20 > Reason header within Responses and it is not an new=20 > encapsulation mechanism. >=20 > Kind regards=20 > Roland Jesske=20 >=20 >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Technical Engineering Center=20 > Roland Jesske=20 > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, Germany=20 > +49 6151 628-2766 (Phone)=20 > +49 521 9210-3753 (Fax)=20 > +49 171 8618-445 (Mobile)=20 > E-Mail: r.jesske@telekom.de =20 > www.telekom.com =20 >=20 > Life is for sharing.=20 >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Supervisory Board: Dr. Steffen Roehn (Chairman)=20 > Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert=20 > Matheis, Klaus Peren=20 > Commercial register: Local court Bonn HRB 14190=20 > Registered office: Bonn=20 > VAT identification no. DE 814645262=20 >=20 > = From BeckW@telekom.de Thu Feb 4 06:58:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DCA3A6D95 for ; Thu, 4 Feb 2010 06:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hObyoCtwltjj for ; Thu, 4 Feb 2010 06:58:58 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id CE8733A6C1F for ; Thu, 4 Feb 2010 06:58:57 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 04 Feb 2010 15:59:38 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 15:59:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Feb 2010 15:56:47 +0100 Message-ID: <4A956CE47D1066408D5C7EB34368A51105B98C93@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: AcqlEW6fzo676ejnSgWcMPDjB7vtFgALLnrCABkP3LA= References: From: To: X-OriginalArrivalTime: 04 Feb 2010 14:59:38.0764 (UTC) FILETIME=[AC533CC0:01CAA5AA] Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 14:58:59 -0000 =20 > 2.1. SIP 2.0 is too expensive for Web application developers The big question is whether SIP is to blame for this complexity or if = it's in the nature of telephony. Web standards are as complex as SIP. = Only very few web browsers pass the acid3 test. XML is not the most = elegant technology either. There must be a different reason why so many develop for the web and so = few for voice. With Flash, it is already possible to do SIP-like = voice/video connections between users. It's rarely used, though. When = eBay bought Skype, everybody expected exciting mash-ups. Nothing = happened.=20 > 4.1.1. Applications reside in endpoints of the Internet Kind of. The success of Web 2.0 was the success of Javascript; = applications run on the endpoint, but are maintained on the server. The = user has no choice which javascript applet to use when accessing a web = 2.0 site. The site owner can update the applet without having to ask the = browser owner for approval. Wolfgang Beck Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) http://www.telekom.com =20 Erleben, was verbindet.=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 From henry.sinnreich@gmail.com Thu Feb 4 07:31:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FEA3A6D97 for ; Thu, 4 Feb 2010 07:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNK8NXKY8zOl for ; Thu, 4 Feb 2010 07:31:17 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id E15CC3A6D87 for ; Thu, 4 Feb 2010 07:31:16 -0800 (PST) Received: by ywh13 with SMTP id 13so2537371ywh.23 for ; Thu, 04 Feb 2010 07:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=iVhpDDNhw428BJWAeAeSaMMIUjZ0tWVA1fDFrQuFTYA=; b=CI38F7+Htk2vu4z7BnXlaP0EsOF2p7RtIu1ddpzcQFXbIWVoaqTuWWiYivCyKCog8r ivbO9K+KIJ4ra3j8gmjkKK4gvXV3UXj1XAxn/RG6nBnwjTAgmpwf5MVqzYt0sTewq1+t JAy+ePAF/JoTYevqydHXuPHlAiw8l4YrAJc5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=PF2IkVLptk/o+T9RJpTB5ylXw7zhTfbfm++t5P6j7Gmno76DPIwOAcn9pyBelHV89k qHXjN4YK45l9VymC1AQPspX8aUeqWicY3i3+qkZOSVWjM156CYZLN1SL3N3L5NNI/uf5 OHNxW5W4oPFR80kZdl1ob0C8sz4HAH3xgRB5w= Received: by 10.150.117.26 with SMTP id p26mr2094968ybc.348.1265297520649; Thu, 04 Feb 2010 07:32:00 -0800 (PST) Received: from ?192.168.0.31? (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 22sm71312ywh.15.2010.02.04.07.31.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 07:31:59 -0800 (PST) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 04 Feb 2010 09:31:57 -0600 From: Henry Sinnreich To: , Message-ID: Thread-Topic: AW: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: AcqlEW6fzo676ejnSgWcMPDjB7vtFgALLnrCABkP3LAAAzHo8w== In-Reply-To: <4A956CE47D1066408D5C7EB34368A51105B98C93@S4DE8PSAAQC.mitte.t-com.de> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 15:31:18 -0000 Thanks Wolfgang for raising these interesting issues. > The big question is whether SIP is to blame for this complexity or if it'= s in > the nature of telephony. My vote goes it's in the nature of traditional telephony. It is arguable ho= w much traditional telephony is of interest today for new investments however= , given especially for younger users accustomed to Web applications and to Skype. Web communications may also lead to much better enabled "call centers". >Web standards are as complex as SIP. Very true, but APIs and IDEs completely hide that complexity. Whatever the reasons (such as market size for developers), there are zillions of Web applications, and only one major app for SIP: Re-engineerin= g traditional telephony over IP. > XML is not the most elegant technology either. Beauty is in the eye of the beholder :-) We could think only of XML as a platform independent standard for APIs. XML is also fully supported in IDE we happen to know, such as Eclipse and Flash that you also mention. Let us know if have any alternative(s) to XML. Thanks again, Henry On 2/4/10 8:56 AM, "BeckW@telekom.de" wrote: > =20 >> 2.1. SIP 2.0 is too expensive for Web application developers > The big question is whether SIP is to blame for this complexity or if it'= s in > the nature of telephony. Web standards are as complex as SIP. Only very f= ew > web browsers pass the acid3 test. XML is not the most elegant technology > either. >=20 > There must be a different reason why so many develop for the web and so f= ew > for voice. With Flash, it is already possible to do SIP-like voice/video > connections between users. It's rarely used, though. When eBay bought Sky= pe, > everybody expected exciting mash-ups. Nothing happened. >=20 >> 4.1.1. Applications reside in endpoints of the Internet > Kind of. The success of Web 2.0 was the success of Javascript; applicatio= ns > run on the endpoint, but are maintained on the server. The user has no ch= oice > which javascript applet to use when accessing a web 2.0 site. The site ow= ner > can update the applet without having to ask the browser owner for approva= l. >=20 >=20 > Wolfgang Beck >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Wolfgang Beck > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628 2832 (Tel.) > http://www.telekom.com >=20 > Erleben, was verbindet. >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis= , > Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 From henry.sinnreich@gmail.com Thu Feb 4 07:55:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EA93A69F9 for ; Thu, 4 Feb 2010 07:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8jegu12g0Al for ; Thu, 4 Feb 2010 07:55:23 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id B9CAB3A6C4E for ; Thu, 4 Feb 2010 07:55:23 -0800 (PST) Received: by gxk28 with SMTP id 28so2467856gxk.9 for ; Thu, 04 Feb 2010 07:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=Rnk8/tKP6fQvezu1jN+IulKKbHum2h0DQIsMyKEA9MQ=; b=mrXkOHgc/SggHcrtYb5BeYs5NX9FuilXkOm59u7Fq05QybUISmUO8FEAyvcbTGHXaO yp7oUiGfO5mnFKmTnRvJ2jtF9EdXrGvNBAI/BZRYmr0SZY/E6ylC0gzeIFgM5GAzXvuB WeEe8l/h6Kw9yhzaXbkdNf8xISZ2Zcisfswao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=OIZe69m8uIQso3zwPxaAAcnwGPOEH9t7Onrw3VhQGBHc4ZES7Tg8rJ0G1T8MFWZEp6 GdTWJgTOLSXL3Lik/wM7y3/OUT7bXMZiXJ9nPlwkzsLvvansOgSPVZVVwIuF1U+ZylB5 dZOCVDxjJgKYIOif8NhYmRMD7nCUkVabUeqc0= Received: by 10.101.132.14 with SMTP id j14mr1815005ann.58.1265298967032; Thu, 04 Feb 2010 07:56:07 -0800 (PST) Received: from ?192.168.0.31? (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 7sm79299yxg.50.2010.02.04.07.56.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 07:56:06 -0800 (PST) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 04 Feb 2010 09:56:02 -0600 From: Henry Sinnreich To: Bernard Aboba , Message-ID: Thread-Topic: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: AcqlEW6fzo676ejnSgWcMPDjB7vtFgALLnrCAADmLVAAHDLqkA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 15:55:25 -0000 There is no disagreement here about the merits of XMPP, however this I-D is focused on SIP APIs and the expertise of the present authors is mainly in SIP. It would be useful to have similar XMPP APIs for Web communications, as well as APIs from the other dominant IM protocols. Application developers would thus have a larger choice, depending on the usage scenario. > [BA] I'd be interested in your take on the XMPP session description and > codec functionality No disagreement here either, though the I-D argues for using metadata instead of SDP, that goes way beyond codec negotiation. In such applications as Web conferencing with screen sharing, telepresence for business and the digital living room, much more platform-specific data needs to be considered in the application than just codecs. Screen sharing example: One, two or more screens in an IT customer support scenario on both ends, with different screen resolutions. Without metadata the parties will not see the same desired screens. Thanks again for the good probing questions, Henry On 2/3/10 8:52 PM, "Bernard Aboba" wrote: > In response to > (http://www.ietf.org/mail-archive/web/dispatch/current/msg01291.html ) > > Henry Sinnreich said: > > "No problems at all with XMPP, except sharing the same problem with SIP, > SIMPLE and all the proprietary IM protocols that are dominant in the IM > market (no names mentioned here): Too complex for generalists Web > application developers to afford the time and resources to learn and to > use." > > [BA] Despite all the extensions (see http://xmpp.org/extensions/ ), XMPP as > described in RFC 3920bis and 3921bis is not a complex protocol, nor > is it difficult to incorporate XMPP into applications. > > Have you seen the XMPP SDKs that are available? Some of them (like > SleekXMPP) are incredibly powerful and easy to use. Chapter 14 of the > O'Reilly book "XMPP: The Definitive Guide" by Peter St. Andre provides an > example > "micro-blogging" application written using SleekXMPP that requires very > little Python code, and is easy to understand even if you don't know > much Python. > > Now that XMPP is a supported platform within the Google cloud platform, > I expect that the situation will only get better. > > Henry said: > > "There is no reason not to replace them all with HTTP transport and APIs for > the client and/or server applications." > > [BA] Since there are XMPP SDKs available for PHP, Python and any other > web development environment you might desire, using XMPP over HTTP should > not require much beyond support for BOSH: > http://xmpp.org/extensions/xep-0124.html > http://xmpp.org/extensions/xep-0206.html > > Henry said: > > "The biggest work item IMO is replacing the stale and problematic SDP with > metadata as detailed in section 2.3.3 and thus also fixing the > non-compliance of SIP with "UNSAF" RFC 3424. Our I-D deals only with SIP at > this point. Replacing SDP and its consequences for NAT traversal requires > indeed some work, possibly not in scope here." > > [BA] I'd be interested in your take on the XMPP session description and > codec functionality: > > http://xmpp.org/extensions/xep-0167.html > http://xmpp.org/extensions/xep-0266.html > http://xmpp.org/extensions/xep-0181.html > http://xmpp.org/extensions/xep-0176.html > > > > > From Leon.Portman@nice.com Thu Feb 4 08:04:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2568E3A6B05 for ; Thu, 4 Feb 2010 08:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KMhbYTPAps3 for ; Thu, 4 Feb 2010 08:04:51 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id E2A0C3A6A86 for ; Thu, 4 Feb 2010 08:04:50 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 4 Feb 2010 18:05:35 +0200 From: Leon Portman To: zhouzhipeng 54906 , "dispatch@ietf.org" Date: Thu, 4 Feb 2010 18:05:33 +0200 Thread-Topic: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqktqKRlOC8O9mCTiGaKCgdeQsikwA/F9Nw Message-ID: <07465C1D981ABC41A344374066AE1A2C37DAB9A2CB@TLVMBX01.nice.com> References: In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 16:04:52 -0000 Zhipeng, Hi The core point of this document is to define a SIP based protocol that will= allow Active VoIP recording, where a some entity from communication system= (gateway, phone, media server) will fork media of the call to recording se= rver. The interface for querying and playback of recorded sessions are currently = out of scope of this work because it probably should be a web service or RE= ST interface. However we are definitely considering to work on it as well. Regards Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of zhouzhipeng 54906 Sent: Wednesday, February 03, 2010 11:52 AM To: dispatch@ietf.org Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Dear all, I have got much valuable information from related emails. As I cited as following, > [rj] This can range anywhere from proprietary VoIP media and=20 > signaling protocols to things such as SCCP, UNISTIM, H.323, TDM=20 > and analog phones. Most such phones are not SIP UAs. Some other=20 > entity (such as a SIP-enabled mixer) may provide the RC media=20 > forking point functionality in these cases. there have been many years for the application of recording.=20 So, may the author give us a brief summary what have been advanced based on= current recording solutions, for example the call center architecture. So = we can easily catch the core point of this document. Another point is: does the diagram need to add the interface between UA to = the RS for the search or query functions. Thanks very much. Zhipeng _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Thu Feb 4 08:09:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720113A6C10 for ; Thu, 4 Feb 2010 08:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmQp5S7nslyH for ; Thu, 4 Feb 2010 08:09:57 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8B8F23A6909 for ; Thu, 4 Feb 2010 08:09:57 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGKAakutJV2Y/2dsb2JhbAC/cJgAhEwE X-IronPort-AV: E=Sophos;i="4.49,405,1262563200"; d="scan'208";a="84041666" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2010 16:10:43 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o14GAh9W014562; Thu, 4 Feb 2010 16:10:43 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 10:10:42 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 10:10:42 -0600 Message-ID: <4B6AF18F.3090107@cisco.com> Date: Thu, 04 Feb 2010 11:10:55 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Musgrave References: <4B69B30E.3010909@gmail.com> <4B6ACD6A.3030706@gmail.com> <8e5ec72f1002040616r4ac95411k8bb5eb6a8261027a@mail.gmail.com> In-Reply-To: <8e5ec72f1002040616r4ac95411k8bb5eb6a8261027a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2010 16:10:42.0694 (UTC) FILETIME=[99D35260:01CAA5B4] Cc: dispatch mailing list Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 16:09:58 -0000 Peter Musgrave wrote: > I also agree that SDP is getting a bit tired. SDP was tired in 2000. It should have been buried long ago. Paul From henry.sinnreich@gmail.com Thu Feb 4 08:10:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A7B3A6C41 for ; Thu, 4 Feb 2010 08:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLdibJ+6RhsL for ; Thu, 4 Feb 2010 08:10:24 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 75AD13A6C27 for ; Thu, 4 Feb 2010 08:10:24 -0800 (PST) Received: by gxk28 with SMTP id 28so2482731gxk.9 for ; Thu, 04 Feb 2010 08:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type; bh=loihE5cXCgQlE76M731rJ6bLY9w2P1DsPkFibxu+EL8=; b=ZU8fH3ZjLt5CGWf4Z/UHCH33XUjlga6txA1zrC5ydieRYcnEOHqGXzytTqhdR6Qi8V DanB8AgCKwZBrXhY+W2MxSgzEcSJ1mM19TywSd5zTtlsmjTAqjDOB9CtlWQp/sd+3wzo 5BaBR3t8YBZTHFCioKPUOmvAZm8Edu+jqeSp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=Kbun6o7lWlupSmt7ZUuIGjqpWPR+JOMuEFRwjWBj3GuqNGA9JLzFCx5fgjHmYOmM2z GglGY43BFIYf2IaUI1EQyBRMuGecpMjFiJlkKDnauJI+Ca406HyBvsNZIOcGcaj8bjNv TpYudsj2ClCOdRDXUe+eIebPgyDNTHALy8EWI= Received: by 10.150.119.29 with SMTP id r29mr2315557ybc.52.1265299867636; Thu, 04 Feb 2010 08:11:07 -0800 (PST) Received: from ?192.168.0.31? (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 9sm82637ywf.5.2010.02.04.08.11.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 08:11:06 -0800 (PST) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 04 Feb 2010 10:11:04 -0600 From: Henry Sinnreich To: Peter Musgrave , Alan Johnston Message-ID: Thread-Topic: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: AcqltKaGODzUkdqAhEOOJpg2zm8LJA== In-Reply-To: <8e5ec72f1002040616r4ac95411k8bb5eb6a8261027a@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3348123066_1518226" Cc: dispatch mailing list Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 16:10:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3348123066_1518226 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Peter, >e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP-li= ke media constructs, uses ICE and if I recall correctly does put address insid= e messages).=A0 As mentioned, our expertise and focus here is in SIP and similar APIs for Jingle would give developers a bigger choice, depending on the usage scenario. As for ICE, we argue it to work in HIP for all application protocols alike, besides all the other reasons for using HIP. >If I had a web API which allowed direct connections to SIP endpoints/media servers I think that would be powerful. Yes, since all or most of the telecom gear supports SIP, we believe there are lots of such apps. Henry On 2/4/10 8:16 AM, "Peter Musgrave" wrote: > Henry/Alan,=A0 >=20 > I think some mention of other web technologies in the draft might help fr= ame > the effort. >=20 > e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP-l= ike > media constructs, uses ICE and if I recall correctly does put address ins= ide > messages).=A0 >=20 > If I had a web API which allowed direct connections to SIP endpoints/medi= a > servers I think that would be powerful. In the past I have done things li= ke > created a "B2B-like" entity with a Jingle stack and a SIP stack - but the= n I > end up with identity issues and issues with simultaneous sessions to medi= a > servers. >=20 > I agree that a very simple call state machine is desired - even if the SI= P > mechanics need to be strongly restricted. I also agree that SDP is gettin= g a > bit tired.=A0 >=20 > Peter >=20 > On Thu, Feb 4, 2010 at 8:36 AM, Alan Johnston > wrote: >> John, >>=20 >> Thanks for your comments. >>=20 >> We are not thinking about just an XML encoding for SIP - you are >> correct, that would still expose way too much complexity. =A0We were >> thinking about starting with the functionality in RFC 5638, then see how >> much we can abstract and separate the "plumbing" of SIP from what an app >> developer needs/cares about. =A0We hope to avoid replicating the entire >> SIP state machine. >>=20 >> However, this is just a starting point, and feedback and input from >> others who share our goal is most welcome. >>=20 >> - Alan - >>=20 >> On 2/4/10 3:43 AM, Elwell, John wrote: >>> > Henry, >>> > >>> > Where the draft talks about "porting core SIP functions to standards = XML >>> based API" (section 4.5), can you shed some more light on this? Is it j= ust a >>> case of adopting existing SIP semantics and defining a new syntax (XML)= ? If >>> so, this would seem to require the web application to support the same >>> complex SIP state machine, with its notions of transactions, dialogs, e= arly >>> dialogs, backwards compatibility capabilities, tolerance of unreliable >>> transports, offer-answer rules, and at least some of the many SIP >>> extensions. Or had you intended some sort of simplification, and if so = can >>> you give more detail? >>> > >>> > Thanks, >>> > >>> > John >>> > >>> > >>>> >> -----Original Message----- >>>> >> From: dispatch-bounces@ietf.org >>>> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich >>>> >> Sent: 03 February 2010 18:18 >>>> >> To: dispatch mailing list >>>> >> Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.= txt >>>> >> >>>> >> We have published an I-D on "SIP APIs for Web Communications" >>>> >> and would >>>> >> appreciate any comments and input. >>>> >> >>>> >> Here is the link and the announcement: >>>> >> >>>> >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap >>>> >> is-00.txt >>>> >> >>>> >> A New Internet-Draft is available from the on-line Internet-Drafts >>>> >> directories. >>>> >> >>>> >> >>>> >> =A0Title =A0: SIP APIs for Communications on the Web >>>> >> =A0Author(s) : H. Sinnreich, A. Johnston >>>> >> =A0Filename : draft-sinnreich-sip-web-apis-00.txt >>>> >> =A0Pages =A0: 19 >>>> >> =A0Date =A0: 2010-1-19 >>>> >> >>>> >> =A0 =A0Interactive communications are becoming part of rich Internet >>>> >> =A0 =A0applications (RIA). This can be accomplished entirely by using W= eb >>>> >> =A0 =A0technology and developing it as an Internet standard. Voice over= IP >>>> >> =A0 =A0(VoIP) features developed for Session Initiation Protocol (SIP 2= .0) >>>> >> =A0 =A0can be preserved in rich multimedia communications and applicati= ons >>>> >> =A0 =A0on the web. =A0Hyper Text Transport Protocol (HTTP) is used >>>> >> for control >>>> >> =A0 =A0and signaling data and RTP for interactive media transport >>>> >> =A0 =A0respectively. No other network application protocols are require= d. >>>> >> =A0 =A0Web, fixed and mobile device application development tools can t= hus >>>> >> =A0 =A0be used to include components and widgets for Internet presence, >>>> >> =A0 =A0Instant Messaging (IM), voice and video. =A0This opens Internet >>>> >> =A0 =A0communications, including voice to application developers and wi= ll >>>> >> =A0 =A0also enhance the user experience with real-time Web and mobile >>>> >> =A0 =A0communications. =A0Usage scenarios include service providers, priv= ate >>>> >> =A0 =A0IP networks, device application developers and media companies >>>> >> =A0 =A0providing a mix of integrated communications, applications >>>> >> and media. >>>> >> =A0 =A0This memo argues for the development and standardization of >>>> >> =A0 =A0Application Programming Interfaces (APIs) to allow the benefits = of >>>> >> =A0 =A0SIP to be used by Rich Internet Applications (RIA), for fixed an= d >>>> >> =A0 =A0mobile devices. >>>> >> >>>> >> A URL for this Internet-Draft is: >>>> >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap >>>> >> is-00.txt >>>> >> >>>> >> ------ End of Forwarded Message >>>> >> >>>> >> Thanks in advance for your comments. >>>> >> >>>> >> Henry >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> dispatch mailing list >>>> >> dispatch@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/dispatch >>>> >> >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 --B_3348123066_1518226 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt</TITLE= > </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '>Peter,<BR> <BR> >e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP= -like media constructs, uses ICE and if I recall correctly does put address = inside messages).=A0<BR> <BR> As mentioned, our expertise and focus here is in SIP and similar APIs for J= ingle would give developers a bigger choice, depending on the usage scenario= .<BR> As for ICE, we argue it to work in HIP for all application protocols alike,= besides all the other reasons for using HIP.<BR> <BR> >If I had a web API which allowed direct connections to SIP endpoints/me= dia servers I think that would be powerful.<BR> Yes, since all or most of the telecom gear supports SIP, we believe there a= re lots of such apps.<BR> <BR> Henry<BR> <BR> <BR> On 2/4/10 8:16 AM, "Peter Musgrave" <<a href=3D"peter.musgrave@m= agorcorp.com">peter.musgrave@magorcorp.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:13pt'>Henry/Alan,=A0<BR> <BR> I think some mention of other web technologies in the draft might help fram= e the effort.<BR> <BR> e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP-lik= e media constructs, uses ICE and if I recall correctly does put address insi= de messages).=A0<BR> <BR> If I had a web API which allowed direct connections to SIP endpoints/media = servers I think that would be powerful. In the past I have done things like = created a "B2B-like" entity with a Jingle stack and a SIP stack - = but then I end up with identity issues and issues with simultaneous sessions= to media servers.<BR> <BR> I agree that a very simple call state machine is desired - even if the SIP = mechanics need to be strongly restricted. I also agree that SDP is getting a= bit tired.=A0<BR> <BR> Peter<BR> <BR> On Thu, Feb 4, 2010 at 8:36 AM, Alan Johnston <<a href=3D"alan.b.johnston@= gmail.com">alan.b.johnston@gmail.com</a>> wrote:<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:13pt'>John,<BR> <BR> Thanks for your comments.<BR> <BR> We are not thinking about just an XML encoding for SIP - you are<BR> correct, that would still expose way too much complexity. =A0We were<BR> thinking about starting with the functionality in RFC 5638, then see how<BR= > much we can abstract and separate the "plumbing" of SIP from what= an app<BR> developer needs/cares about. =A0We hope to avoid replicating the entire<BR> SIP state machine.<BR> <BR> However, this is just a starting point, and feedback and input from<BR> others who share our goal is most welcome.<BR> <FONT COLOR=3D"#888888"><BR> - Alan -<BR> </FONT><BR> On 2/4/10 3:43 AM, Elwell, John wrote:<BR> > Henry,<BR> ><BR> > Where the draft talks about "porting core SIP functions to standa= rds XML based API" (section 4.5), can you shed some more light on this?= Is it just a case of adopting existing SIP semantics and defining a new syn= tax (XML)? If so, this would seem to require the web application to support = the same complex SIP state machine, with its notions of transactions, dialog= s, early dialogs, backwards compatibility capabilities, tolerance of unrelia= ble transports, offer-answer rules, and at least some of the many SIP extens= ions. Or had you intended some sort of simplification, and if so can you giv= e more detail?<BR> ><BR> > Thanks,<BR> ><BR> > John<BR> ><BR> ><BR> >> -----Original Message-----<BR> >> From: <a href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.or= g</a><BR> >> [<a href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounce= s@ietf.org</a>] On Behalf Of Henry Sinnreich<BR> >> Sent: 03 February 2010 18:18<BR> >> To: dispatch mailing list<BR> >> Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00= .txt<BR> >><BR> >> We have published an I-D on "SIP APIs for Web Communications&= quot;<BR> >> and would<BR> >> appreciate any comments and input.<BR> >><BR> >> Here is the link and the announcement:<BR> >><BR> >> <a href=3D"http://www.ietf.org/internet-drafts/draft-sinnreich-sip-w= eb-ap">http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap</a><BR= > >> is-00.txt<BR> >><BR> >> A New Internet-Draft is available from the on-line Internet-Drafts= <BR> >> directories.<BR> >><BR> >><BR> >> =A0Title =A0: SIP APIs for Communications on the Web<BR> >> =A0Author(s) : H. Sinnreich, A. Johnston<BR> >> =A0Filename : draft-sinnreich-sip-web-apis-00.txt<BR> >> =A0Pages =A0: 19<BR> >> =A0Date =A0: 2010-1-19<BR> >><BR> >> =A0 =A0Interactive communications are becoming part of rich Internet<B= R> >> =A0 =A0applications (RIA). This can be accomplished entirely by using = Web<BR> >> =A0 =A0technology and developing it as an Internet standard. Voice ove= r IP<BR> >> =A0 =A0(VoIP) features developed for Session Initiation Protocol (SIP = 2.0)<BR> >> =A0 =A0can be preserved in rich multimedia communications and applicat= ions<BR> >> =A0 =A0on the web. =A0Hyper Text Transport Protocol (HTTP) is used<BR> >> for control<BR> >> =A0 =A0and signaling data and RTP for interactive media transport<BR> >> =A0 =A0respectively. No other network application protocols are requir= ed.<BR> >> =A0 =A0Web, fixed and mobile device application development tools can = thus<BR> >> =A0 =A0be used to include components and widgets for Internet presence= ,<BR> >> =A0 =A0Instant Messaging (IM), voice and video. =A0This opens Internet<B= R> >> =A0 =A0communications, including voice to application developers and w= ill<BR> >> =A0 =A0also enhance the user experience with real-time Web and mobile<= BR> >> =A0 =A0communications. =A0Usage scenarios include service providers, pri= vate<BR> >> =A0 =A0IP networks, device application developers and media companies<= BR> >> =A0 =A0providing a mix of integrated communications, applications<BR> >> and media.<BR> >> =A0 =A0This memo argues for the development and standardization of<BR> >> =A0 =A0Application Programming Interfaces (APIs) to allow the benefits= of<BR> >> =A0 =A0SIP to be used by Rich Internet Applications (RIA), for fixed a= nd<BR> >> =A0 =A0mobile devices.<BR> >><BR> >> A URL for this Internet-Draft is:<BR> >> <a href=3D"http://www.ietf.org/internet-drafts/draft-sinnreich-sip-w= eb-ap">http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap</a><BR= > >> is-00.txt<BR> >><BR> >> ------ End of Forwarded Message<BR> >><BR> >> Thanks in advance for your comments.<BR> >><BR> >> Henry<BR> >><BR> >><BR> >> _______________________________________________<BR> >> dispatch mailing list<BR> >> <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR> >> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://w= ww.ietf.org/mailman/listinfo/dispatch</a><BR> >><BR> > _______________________________________________<BR> > dispatch mailing list<BR> > <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.i= etf.org/mailman/listinfo/dispatch</a><BR> ><BR> _______________________________________________<BR> dispatch mailing list<BR> <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.o= rg/mailman/listinfo/dispatch</a><BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:13pt'><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3348123066_1518226-- From BeckW@telekom.de Thu Feb 4 08:18:49 2010 Return-Path: <BeckW@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD383A6C63 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-w6wKJFU1my for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:18:48 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id C27663A6DE1 for <dispatch@ietf.org>; Thu, 4 Feb 2010 08:18:46 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 04 Feb 2010 17:18:54 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 17:18:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA5B5.BE5A0F94" Date: Thu, 4 Feb 2010 17:18:52 +0100 Message-ID: <4A956CE47D1066408D5C7EB34368A51105B98D1E@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <C7904DB8.C6F7%henry.sinnreich@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: AcqltKaGODzUkdqAhEOOJpg2zm8LJAAAHCBQ References: <8e5ec72f1002040616r4ac95411k8bb5eb6a8261027a@mail.gmail.com> <C7904DB8.C6F7%henry.sinnreich@gmail.com> From: <BeckW@telekom.de> To: <henry.sinnreich@gmail.com>, <peter.musgrave@magorcorp.com>, <alan.b.johnston@gmail.com> X-OriginalArrivalTime: 04 Feb 2010 16:18:53.0796 (UTC) FILETIME=[BE8B8A40:01CAA5B5] Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 16:18:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA5B5.BE5A0F94 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Henry wrote > Peter Musgrave wrote: >> If I had a web API which allowed direct connections to SIP = endpoints/media servers I think that would be powerful. > Yes, since all or most of the telecom gear supports SIP, we believe = there are lots of such apps. do you think of something like this: = http://www.developergarden.com/startseite ? It's a REST-based API to set = up voice calls or conferences. It's an attempt to hide SIP's complexity = from web developers.=20 =20 Wolfgang Beck =20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) www.telekom.com=20 Erleben, was verbindet.=20 =20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 =20 =20 ________________________________ Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Henry Sinnreich Gesendet: Donnerstag, 4. Februar 2010 17:11 An: Peter Musgrave; Alan Johnston Cc: dispatch mailing list Betreff: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Peter, >e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has = SDP-like media constructs, uses ICE and if I recall correctly does put = address inside messages).=20 As mentioned, our expertise and focus here is in SIP and similar APIs = for Jingle would give developers a bigger choice, depending on the usage = scenario. As for ICE, we argue it to work in HIP for all application protocols = alike, besides all the other reasons for using HIP. >If I had a web API which allowed direct connections to SIP = endpoints/media servers I think that would be powerful. Yes, since all or most of the telecom gear supports SIP, we believe = there are lots of such apps. Henry =20 ------_=_NextPart_001_01CAA5B5.BE5A0F94 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Re: [dispatch] I-D = ACTION:draft-sinnreich-sip-web-apis-00.txt
Henry wrote
> Peter Musgrave = wrote:
>> If I had a web API which allowed = direct=20 connections to SIP endpoints/media servers I think that would be=20 powerful.
> Yes, since all = or most=20 of the telecom gear supports SIP, we believe there are lots of such=20 apps.
do you think of something like this: http://www.developerga= rden.com/startseite ?=20 It's a REST-based API to set up voice calls or conferences. It's an = attempt to=20 hide SIP's complexity from web developers.
 

Wolfgang=20 Beck

 

 

Deutsche=20 Telekom Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Wolfgang=20 Beck
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 628 = 2832=20 (Tel.)
www.telekom.com =

Erleben,=20 was verbindet.=20

 

Deutsche = Telekom=20 Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn=20 (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn = (Vorsitzender),=20 Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB=20 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE = 814645262

 

 

Von: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] Im Auftrag von Henry=20 Sinnreich
Gesendet: Donnerstag, 4. Februar 2010 = 17:11
An:=20 Peter Musgrave; Alan Johnston
Cc: dispatch mailing=20 list
Betreff: Re: [dispatch] I-D=20 ACTION:draft-sinnreich-sip-web-apis-00.txt

Peter,

>e.g. How does a SIP API = compare to=20 e.g. Jingle (which uses RTP, has SDP-like media constructs, uses ICE and = if I=20 recall correctly does put address inside messages). 

As = mentioned,=20 our expertise and focus here is in SIP and similar APIs for Jingle would = give=20 developers a bigger choice, depending on the usage scenario.
As for = ICE, we=20 argue it to work in HIP for all application protocols alike, besides all = the=20 other reasons for using HIP.

>If I had a web API which allowed = direct=20 connections to SIP endpoints/media servers I think that would be=20 powerful.
Yes, since all or most of the telecom gear supports SIP, we = believe=20 there are lots of such apps.

Henry
 
------_=_NextPart_001_01CAA5B5.BE5A0F94-- From henry.sinnreich@gmail.com Thu Feb 4 08:35:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569AA3A68DE for ; Thu, 4 Feb 2010 08:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6GeCSSxXu-q for ; Thu, 4 Feb 2010 08:35:28 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id 6900C3A689B for ; Thu, 4 Feb 2010 08:35:28 -0800 (PST) Received: by yxe32 with SMTP id 32so2122588yxe.5 for ; Thu, 04 Feb 2010 08:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type; bh=4cqCg8DVmzVQZpZekaXMgQ78r4KFpR4HpZYDNvSoA7g=; b=PIqpzAAKBCGce3VX1SpEaBArTTAv6pY07WpKwAyDz5htK2FSyQKmc7Hwgcp0OimTiQ 66/nVnh9xVbQsx9sMOzo+Y8RN9RWs+itONwRMT5UfHq5Wt2YIRGC+RX+KpJht7U+XbgB dh7u84SwL53kvInXgjkwzCl+I9c+r32lo87oU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=sGdgclbVlKhPFBMYC+LV0rcIiS66rgaxYOo/YeX5Ez9mqV+pOYwrD/k6SbaLyq3g+D pARltIV1IUXNA17Y7CSCCWGDcu0FFYXzoh0LU/t/Y+LdWs+codNcFT6ahMsre6Vbrge7 nRNvoJvwKYSDVoo5Xua+M3+p5oe0uoNdjsyhI= Received: by 10.150.193.3 with SMTP id q3mr2290152ybf.221.1265301371049; Thu, 04 Feb 2010 08:36:11 -0800 (PST) Received: from ?192.168.0.31? (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 36sm89954yxh.31.2010.02.04.08.36.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 08:36:10 -0800 (PST) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 04 Feb 2010 10:36:05 -0600 From: Henry Sinnreich To: , , Alan Johnston Message-ID: Thread-Topic: AW: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt Thread-Index: AcqltKaGODzUkdqAhEOOJpg2zm8LJAAAHCBQAADDirE= In-Reply-To: <4A956CE47D1066408D5C7EB34368A51105B98D1E@S4DE8PSAAQC.mitte.t-com.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3348124569_1619064" Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 16:35:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3348124569_1619064 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable http://www.developergarden.com/startseite Shows we don=B9t have a monopoly in trying to hide SIP complexity from developers. Examples like Conf Call light are very convincing. The next step is allowing Web application developers to mix and match RIA and SIP-like apps in a seamless manner within the same IDE. Or has someone done it already as well? Henry On 2/4/10 10:18 AM, "BeckW@telekom.de" wrote: > Henry wrote >> > Peter Musgrave wrote: >>> >> If I had a web API which allowed direct connections to SIP >>> endpoints/media servers I think that would be powerful. >> > Yes, since all or most of the telecom gear supports SIP, we believe th= ere >> are lots of such apps. > do you think of something like this: http://www.developergarden.com/start= seite > ? It's a REST-based API to set up voice calls or conferences. It's an att= empt > to hide SIP's complexity from web developers. > =20 > Wolfgang Beck >=20 > =20 >=20 > =20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Wolfgang Beck > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628 2832 (Tel.) > www.telekom.com >=20 > Erleben, was verbindet. >=20 > =20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis= , > Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 > =20 > =20 >=20 >=20 > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auft= rag > von Henry Sinnreich > Gesendet: Donnerstag, 4. Februar 2010 17:11 > An: Peter Musgrave; Alan Johnston > Cc: dispatch mailing list > Betreff: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt >=20 > Peter, >=20 >> >e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP= -like >> media constructs, uses ICE and if I recall correctly does put address in= side >> messages).=20 >=20 > As mentioned, our expertise and focus here is in SIP and similar APIs for > Jingle would give developers a bigger choice, depending on the usage scen= ario. > As for ICE, we argue it to work in HIP for all application protocols alik= e, > besides all the other reasons for using HIP. >=20 >> >If I had a web API which allowed direct connections to SIP endpoints/me= dia >> servers I think that would be powerful. > Yes, since all or most of the telecom gear supports SIP, we believe there= are > lots of such apps. >=20 > Henry >=20 >=20 >> =20 >=20 --B_3348124569_1619064 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: AW: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '><a href=3D"http://www.developergarden.com/startseite">http://www.developerga= rden.com/startseite</a><BR> <BR> Shows we don’t have a monopoly in trying to hide SIP complexity from = developers.<BR> Examples like Conf Call light are very convincing.<BR> <BR> The next step is allowing Web application developers to mix and match RIA a= nd SIP-like apps in a seamless manner within the same IDE.<BR> Or has someone done it already as well?<BR> <BR> Henry<BR> <BR> <BR> On 2/4/10 10:18 AM, "<a href=3D"BeckW@telekom.de">BeckW@telekom.de</a>&q= uot; <<a href=3D"BeckW@telekom.de">BeckW@telekom.de</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= FONT SIZE=3D"5"><SPAN STYLE=3D'font-size:24pt'>Henry wrote<BR> > Peter Musgrave wrote:<BR> >></SPAN></FONT><SPAN STYLE=3D'font-size:13pt'> If I had a web API whic= h allowed direct connections to SIP endpoints/media servers I think that wou= ld be powerful.<BR> > Yes, since all or most of the telecom gear supports SIP, we believe th= ere are lots of such apps.<BR> </SPAN></FONT><SPAN STYLE=3D'font-size:13pt'><FONT COLOR=3D"#0000FF"><FONT FACE= =3D"Arial">do you think of something like this: <a href=3D"http://www.developerg= arden.com/startseite">http://www.developergarden.com/startseite</a> ? It's a= REST-based API to set up voice calls or conferences. It's an attempt to hid= e SIP's complexity from web developers. <BR> </FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"> <BR> </FONT></SPAN><FONT SIZE=3D"1"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:10pt= '>Wolfgang Beck<BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'><BR> </SPAN></FONT><FONT SIZE=3D"0"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:8pt'= > <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'><BR> </SPAN></FONT><FONT SIZE=3D"0"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:8pt'= > <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'><BR> </SPAN></FONT><FONT COLOR=3D"#979797"><FONT SIZE=3D"0"><FONT FACE=3D"Arial"><SPAN= STYLE=3D'font-size:8pt'>Deutsche Telekom Netzproduktion GmbH<BR> Zentrum Technik Einführung<BR> Wolfgang Beck<BR> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt<BR> +49 6151 628 2832 (Tel.)<BR> www.telekom.com <<a href=3D"http:www.telekom.com">http:www.telekom.com</a>= >  <BR> </SPAN></FONT></FONT></FONT><FONT SIZE=3D"0"><FONT FACE=3D"Arial"><SPAN STYLE=3D'= font-size:8pt'><FONT COLOR=3D"#E20074"><BR> Erleben, was verbindet.</FONT><FONT COLOR=3D"#808000"> <BR> </FONT></SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:13pt'><BR> </SPAN></FONT><FONT SIZE=3D"0"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:8pt'= > <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'><BR> </SPAN></FONT><FONT COLOR=3D"#979797"><FONT SIZE=3D"0"><FONT FACE=3D"Arial"><SPAN= STYLE=3D'font-size:8pt'>Deutsche Telekom Netzproduktion GmbH<BR> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)<BR> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert= Matheis, Klaus Peren<BR> Handelsregister: Amtsgericht Bonn HRB 14190<BR> Sitz der Gesellschaft: Bonn<BR> USt-IdNr. DE 814645262<BR> </SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:13pt'><BR> </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:10pt= '> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'> <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></SPAN></FONT><SPAN STYLE=3D'font-size= :13pt'><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>Von:</B> <a href=3D"d= ispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a> [<a href=3D"mailto:dis= patch-bounces@ietf.org">mailto:dispatch-bounces@ietf.org</a>] <B>Im Auftrag = von </B>Henry Sinnreich<BR> <B>Gesendet:</B> Donnerstag, 4. Februar 2010 17:11<BR> <B>An:</B> Peter Musgrave; Alan Johnston<BR> <B>Cc:</B> dispatch mailing list<BR> <B>Betreff:</B> Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.t= xt<BR> </FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR> Peter,<BR> <BR> >e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP= -like media constructs, uses ICE and if I recall correctly does put address = inside messages). <BR> <BR> As mentioned, our expertise and focus here is in SIP and similar APIs for J= ingle would give developers a bigger choice, depending on the usage scenario= .<BR> As for ICE, we argue it to work in HIP for all application protocols alike,= besides all the other reasons for using HIP.<BR> <BR> >If I had a web API which allowed direct connections to SIP endpoints/me= dia servers I think that would be powerful.<BR> Yes, since all or most of the telecom gear supports SIP, we believe there a= re lots of such apps.<BR> <BR> Henry<BR> <BR> <BR> </FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:13pt'><FONT FACE=3D"Calibri,= Verdana, Helvetica, Arial"> <BR> </FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:13pt'><FONT FACE=3D"Calibri= , Verdana, Helvetica, Arial"><BR> </FONT></SPAN></BLOCKQUOTE> </BODY> </HTML> --B_3348124569_1619064-- From pkyzivat@cisco.com Thu Feb 4 08:41:56 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7BAA3A69ED for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH33DlygVSoh for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:41:55 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 78E343A676A for <dispatch@ietf.org>; Thu, 4 Feb 2010 08:41:55 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGuHakutJV2b/2dsb2JhbADAFJgDhEwE X-IronPort-AV: E=Sophos;i="4.49,405,1262563200"; d="scan'208";a="84048123" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2010 16:42:41 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o14GgfJN004218; Thu, 4 Feb 2010 16:42:41 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 10:42:41 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 10:42:40 -0600 Message-ID: <4B6AF912.3060706@cisco.com> Date: Thu, 04 Feb 2010 11:42:58 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" <john.elwell@siemens-enterprise.com> References: <4B69B30E.3010909@gmail.com> <C78F19F0.C5F5%henry.sinnreich@gmail.com> <A444A0F8084434499206E78C106220CAB92101A3@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAB92101A3@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2010 16:42:40.0738 (UTC) FILETIME=[11119C20:01CAA5B9] Cc: dispatch mailing list <dispatch@ietf.org> Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 16:41:56 -0000 I like this draft. I find it much more to the point than was the simple sip draft. And it makes the case much better. I agree with John that unless some simplification is done, a "web api" won't be any simpler than what we have. The key to that is coming up with a higher level abstraction, that has all the degrees of freedom that are needed, while hiding everything else. This is very hard to do. And doing so successfully requires very carefully identifying the audience. ISTM that developing such a new level of abstraction is a prerequisite to other progress on this front. I'm uncertain if IETF is or is not the right place to do that. Thanks, Paul Elwell, John wrote: > Henry, > > Where the draft talks about "porting core SIP functions to standards XML based API" (section 4.5), can you shed some more light on this? Is it just a case of adopting existing SIP semantics and defining a new syntax (XML)? If so, this would seem to require the web application to support the same complex SIP state machine, with its notions of transactions, dialogs, early dialogs, backwards compatibility capabilities, tolerance of unreliable transports, offer-answer rules, and at least some of the many SIP extensions. Or had you intended some sort of simplification, and if so can you give more detail? > > Thanks, > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich >> Sent: 03 February 2010 18:18 >> To: dispatch mailing list >> Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt >> >> We have published an I-D on "SIP APIs for Web Communications" >> and would >> appreciate any comments and input. >> >> Here is the link and the announcement: >> >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap >> is-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : SIP APIs for Communications on the Web >> Author(s) : H. Sinnreich, A. Johnston >> Filename : draft-sinnreich-sip-web-apis-00.txt >> Pages : 19 >> Date : 2010-1-19 >> >> Interactive communications are becoming part of rich Internet >> applications (RIA). This can be accomplished entirely by using Web >> technology and developing it as an Internet standard. Voice over IP >> (VoIP) features developed for Session Initiation Protocol (SIP 2.0) >> can be preserved in rich multimedia communications and applications >> on the web. Hyper Text Transport Protocol (HTTP) is used >> for control >> and signaling data and RTP for interactive media transport >> respectively. No other network application protocols are required. >> Web, fixed and mobile device application development tools can thus >> be used to include components and widgets for Internet presence, >> Instant Messaging (IM), voice and video. This opens Internet >> communications, including voice to application developers and will >> also enhance the user experience with real-time Web and mobile >> communications. Usage scenarios include service providers, private >> IP networks, device application developers and media companies >> providing a mix of integrated communications, applications >> and media. >> This memo argues for the development and standardization of >> Application Programming Interfaces (APIs) to allow the benefits of >> SIP to be used by Rich Internet Applications (RIA), for fixed and >> mobile devices. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-ap >> is-00.txt >> >> ------ End of Forwarded Message >> >> Thanks in advance for your comments. >> >> Henry >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From lorenzo@meetecho.com Thu Feb 4 08:44:15 2010 Return-Path: <lorenzo@meetecho.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397CC3A6C62 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE8L9F1IUZWj for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:44:14 -0800 (PST) Received: from smtp6.aruba.it (smtp7.aruba.it [62.149.128.206]) by core3.amsl.com (Postfix) with SMTP id 8A1BE3A676A for <dispatch@ietf.org>; Thu, 4 Feb 2010 08:44:13 -0800 (PST) Received: (qmail 12519 invoked by uid 89); 4 Feb 2010 16:44:57 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.172) by smtp6.ad.aruba.it with SMTP; 4 Feb 2010 16:44:57 -0000 Date: Thu, 4 Feb 2010 17:43:48 +0100 From: Lorenzo Miniero <lorenzo@meetecho.com> To: Leon Portman <Leon.Portman@nice.com> Message-Id: <20100204174348.a1532afb.lorenzo@meetecho.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37DAB9A2CB@TLVMBX01.nice.com> References: <mailman.1593.1265154947.4761.dispatch@ietf.org> <fd28af9f4a38.4a38fd28af9f@huawei.com> <07465C1D981ABC41A344374066AE1A2C37DAB9A2CB@TLVMBX01.nice.com> Organization: Meetecho X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp6.ad.aruba.it 1.6.2 0/1000/N Cc: "dispatch@ietf.org" <dispatch@ietf.org>, zhouzhipeng 54906 <zhouzp@huawei.com> Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 16:44:15 -0000 Hi Leon and Zhipeng, just for your knowledge, I remind the ML of the existence of a draft we wrote a few months ago that is related to session recording and playback: http://tools.ietf.org/html/draft-romano-dcon-recording-01 It is not currently based on web services or RESTful interfaces, but it still is a standard approach, since it makes use of SMIL to synchronize the recorded streams and play them back to interested users. In case anyone is interested in working on a document related to this topic just let us know. Lorenzo On Thu, 4 Feb 2010 18:05:33 +0200 Leon Portman <Leon.Portman@nice.com> wrote: > Zhipeng, Hi > > The core point of this document is to define a SIP based protocol that will allow Active VoIP recording, where a some entity from communication system (gateway, phone, media server) will fork media of the call to recording server. > > The interface for querying and playback of recorded sessions are currently out of scope of this work because it probably should be a web service or REST interface. However we are definitely considering to work on it as well. > > Regards > > Leon > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of zhouzhipeng 54906 > Sent: Wednesday, February 03, 2010 11:52 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 > > Dear all, > I have got much valuable information from related emails. > As I cited as following, > > > [rj] This can range anywhere from proprietary VoIP media and > > signaling protocols to things such as SCCP, UNISTIM, H.323, TDM > > and analog phones. Most such phones are not SIP UAs. Some other > > entity (such as a SIP-enabled mixer) may provide the RC media > > forking point functionality in these cases. > > there have been many years for the application of recording. > So, may the author give us a brief summary what have been advanced based on current recording solutions, for example the call center architecture. So we can easily catch the core point of this document. > > Another point is: does the diagram need to add the interface between UA to the RS for the search or query functions. > > Thanks very much. > Zhipeng > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Lorenzo Miniero Meetecho s.r.l. http://www.meetecho.com/ From Leon.Portman@nice.com Thu Feb 4 08:49:04 2010 Return-Path: <Leon.Portman@nice.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94153A6B28 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJoJu+JbVxMk for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 08:49:03 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 7658F3A6AFB for <dispatch@ietf.org>; Thu, 4 Feb 2010 08:49:03 -0800 (PST) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 4 Feb 2010 18:49:48 +0200 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 4 Feb 2010 18:49:48 +0200 From: Leon Portman <Leon.Portman@nice.com> To: Lorenzo Miniero <lorenzo@meetecho.com> Date: Thu, 4 Feb 2010 18:49:47 +0200 Thread-Topic: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 Thread-Index: AcqluWSQpT7sb49/Rs2f66+TZlp3zQAABYEA Message-ID: <07465C1D981ABC41A344374066AE1A2C37DAB9A2FF@TLVMBX01.nice.com> References: <mailman.1593.1265154947.4761.dispatch@ietf.org> <fd28af9f4a38.4a38fd28af9f@huawei.com> <07465C1D981ABC41A344374066AE1A2C37DAB9A2CB@TLVMBX01.nice.com> <20100204174348.a1532afb.lorenzo@meetecho.com> In-Reply-To: <20100204174348.a1532afb.lorenzo@meetecho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org>, zhouzhipeng 54906 <zhouzp@huawei.com> Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 16:49:05 -0000 Lorenzo, Hi It will be very important to continue this work for standardization how rec= ordings will be represented, specially for complex scenarios with multiple = medias and segments Regards Leon=20 -----Original Message----- From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]=20 Sent: Thursday, February 04, 2010 6:44 PM To: Leon Portman Cc: zhouzhipeng 54906; dispatch@ietf.org Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-r= eq-00 Hi Leon and Zhipeng, just for your knowledge, I remind the ML of the existence of a draft we wrote a few months ago that is related to session recording and playback: http://tools.ietf.org/html/draft-romano-dcon-recording-01 It is not currently based on web services or RESTful interfaces, but it still is a standard approach, since it makes use of SMIL to synchronize the recorded streams and play them back to interested users. In case anyone is interested in working on a document related to this topic just let us know. Lorenzo On Thu, 4 Feb 2010 18:05:33 +0200 Leon Portman <Leon.Portman@nice.com> wrote: > Zhipeng, Hi >=20 > The core point of this document is to define a SIP based protocol that wi= ll allow Active VoIP recording, where a some entity from communication syst= em (gateway, phone, media server) will fork media of the call to recording = server. >=20 > The interface for querying and playback of recorded sessions are currentl= y out of scope of this work because it probably should be a web service or = REST interface. However we are definitely considering to work on it as well= . >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of zhouzhipeng 54906 > Sent: Wednesday, February 03, 2010 11:52 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording= -req-00 >=20 > Dear all, > I have got much valuable information from related emails. > As I cited as following, >=20 > > [rj] This can range anywhere from proprietary VoIP media and=20 > > signaling protocols to things such as SCCP, UNISTIM, H.323, TDM=20 > > and analog phones. Most such phones are not SIP UAs. Some other=20 > > entity (such as a SIP-enabled mixer) may provide the RC media=20 > > forking point functionality in these cases. >=20 > there have been many years for the application of recording.=20 > So, may the author give us a brief summary what have been advanced based = on current recording solutions, for example the call center architecture. S= o we can easily catch the core point of this document. >=20 > Another point is: does the diagram need to add the interface between UA t= o the RS for the search or query functions. >=20 > Thanks very much. > Zhipeng >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 --=20 Lorenzo Miniero Meetecho s.r.l. http://www.meetecho.com/ From xavier.marjou@gmail.com Thu Feb 4 09:00:39 2010 Return-Path: <xavier.marjou@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4960C28C0EB for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 09:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLxRtvfFVK3s for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 09:00:37 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id EBAB83A68F9 for <dispatch@ietf.org>; Thu, 4 Feb 2010 09:00:36 -0800 (PST) Received: by yxe32 with SMTP id 32so2148971yxe.5 for <dispatch@ietf.org>; Thu, 04 Feb 2010 09:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ztOY4+1nhOSFDKKMErEWiwZ11C1JHowqv/d87CG1hBc=; b=E7hagu0MDS+my7JJORiCTVbvxzsNHBSKxtB5menPU0pOO+LW4Uev00wTuHqfaNtaPw tIcT7F5vN5uP0S2afZPc8JIXOAtO169powNEuW8nPkX85/HoGyqDoOs74UxqncfLMdFL LHy9AXHl8f1D61gfI/MohJEIm43JWvpA5mxI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rPxdVY3HTgE4kX3PFGUFJKqh2PCCKPN+/g3dxBrBcv4OTSAeo3nWCR4JW/RM7lC9sz t75iGzQVlxzjIoDAhc1R++hzoWCod+rWsh171h++c4Xo6bx1Vp6zd3ynzEdKAP5XGZ6Z RYvh1Oxbmxtc0pHoyPhXqA3hV03LR1qGrvkx8= MIME-Version: 1.0 Received: by 10.90.148.3 with SMTP id v3mr1508029agd.40.1265302871956; Thu, 04 Feb 2010 09:01:11 -0800 (PST) Date: Thu, 4 Feb 2010 18:01:11 +0100 Message-ID: <458913681002040901u4e387a45mfa70799ff531bb0f@mail.gmail.com> From: Xavier Marjou <xavier.marjou@gmail.com> To: Mary Barnes <mary.barnes@nortel.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: [dispatch] When will UUI WG be created? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 17:00:39 -0000 Hi, The first two WG proposals of IETF75 have been created (codec, sipclf), but what about Call Control User-to-User Information WG? When will it be created? Thank you, Xavier On Thu, Jan 21, 2010 at 7:56 PM, Mary Barnes <mary.barnes@nortel.com> wrote= : > Hi all, > > I've added a summary of the dispatched items to the Wiki on the DISPATCH > WG tools page: > http://trac.tools.ietf.org/wg/dispatch/trac/wiki > > I've included both the work that has been chartered or completely > dispatched along with that for which the chartering work is still > underway. I'll update it with the appropriate WG information as it > becomes available. > > Please let me know if the format is useful or if you find any > inaccuracies. > > Thanks, > Mary. > > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Wednesday, December 09, 2009 9:33 AM > To: Brett Tate; dispatch@ietf.org > Subject: RE: [dispatch] locating spawns of DISPATCH > > Hi Brett, > > That's a good point. I had been summarizing such in the status emails, > but can see the value in keeping this in a single place. I'll add a page > to the supplementary webpage on softarmor and send a note to the list > when that's done. > > Thanks, > Mary. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Brett Tate > Sent: Wednesday, December 09, 2009 7:04 AM > To: dispatch@ietf.org > Subject: [dispatch] locating spawns of DISPATCH > > Greetings, > > Are the working group spawns of DISPATCH collected somewhere to easily > notice them (without searching email archive)? =A0For instance, will they > be linked somehow to DISPATCH charter, status, or a supplemental > DISPATCH webpage? > > Thanks, > Brett > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From tom111.taylor@bell.net Thu Feb 4 09:46:58 2010 Return-Path: <tom111.taylor@bell.net> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F703A6A27 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 09:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxe45+i3ROi1 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 09:46:58 -0800 (PST) Received: from blu0-omc4-s7.blu0.hotmail.com (blu0-omc4-s7.blu0.hotmail.com [65.55.111.146]) by core3.amsl.com (Postfix) with ESMTP id 261623A69F9 for <dispatch@ietf.org>; Thu, 4 Feb 2010 09:46:58 -0800 (PST) Received: from BLU0-SMTP54 ([65.55.111.136]) by blu0-omc4-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 09:47:45 -0800 X-Originating-IP: [76.64.156.247] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: <BLU0-SMTP546F6064E1A19079C60149D8550@phx.gbl> Received: from [192.168.2.11] ([76.64.156.247]) by BLU0-SMTP54.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 09:47:44 -0800 Date: Thu, 04 Feb 2010 12:47:43 -0500 From: Tom Taylor <tom111.taylor@bell.net> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat <pkyzivat@cisco.com> References: <4B69B30E.3010909@gmail.com> <C78F19F0.C5F5%henry.sinnreich@gmail.com> <A444A0F8084434499206E78C106220CAB92101A3@MCHP058A.global-ad.net> <4B6ACD6A.3030706@gmail.com> <8e5ec72f1002040616r4ac95411k8bb5eb6a8261027a@mail.gmail.com> <4B6AF18F.3090107@cisco.com> In-Reply-To: <4B6AF18F.3090107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2010 17:47:44.0700 (UTC) FILETIME=[2802EFC0:01CAA5C2] Cc: dispatch mailing list <dispatch@ietf.org> Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 17:46:59 -0000 Joerg and his student certainly tried, with SDPng. Maybe with the rise of XML SDPng's time has come. Paul Kyzivat wrote: > > > Peter Musgrave wrote: >> I also agree that SDP is getting a bit tired. > > SDP was tired in 2000. It should have been buried long ago. > > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From gonzalo.camarillo@ericsson.com Thu Feb 4 11:17:31 2010 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938EB28C1C2 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 11:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.382 X-Spam-Level: X-Spam-Status: No, score=-103.382 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+2LNCKKVDrm for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 11:17:30 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7AE1528C1B8 for <dispatch@ietf.org>; Thu, 4 Feb 2010 11:17:30 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-fc-4b6b1d78b50e Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D1.1A.31641.87D1B6B4; Thu, 4 Feb 2010 20:18:16 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 20:18:16 +0100 Received: from [131.160.126.251] ([131.160.126.251]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 20:18:15 +0100 Message-ID: <4B6B1D77.8030405@ericsson.com> Date: Thu, 04 Feb 2010 21:18:15 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Xavier Marjou <xavier.marjou@gmail.com> References: <458913681002040901u4e387a45mfa70799ff531bb0f@mail.gmail.com> In-Reply-To: <458913681002040901u4e387a45mfa70799ff531bb0f@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2010 19:18:15.0713 (UTC) FILETIME=[CD25C110:01CAA5CE] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Mary Barnes <mary.barnes@nortel.com> Subject: Re: [dispatch] When will UUI WG be created? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 19:17:31 -0000 Hi, as DISPATCH chairs, once we send a charter proposal to the ADs, it is in their hands. You can check with them (I know they have been quite busy). Cheers, Gonzalo Xavier Marjou wrote: > Hi, > > The first two WG proposals of IETF75 have been created (codec, > sipclf), but what about Call Control User-to-User Information WG? When > will it be created? > > Thank you, > Xavier > > > > On Thu, Jan 21, 2010 at 7:56 PM, Mary Barnes <mary.barnes@nortel.com> wrote: >> Hi all, >> >> I've added a summary of the dispatched items to the Wiki on the DISPATCH >> WG tools page: >> http://trac.tools.ietf.org/wg/dispatch/trac/wiki >> >> I've included both the work that has been chartered or completely >> dispatched along with that for which the chartering work is still >> underway. I'll update it with the appropriate WG information as it >> becomes available. >> >> Please let me know if the format is useful or if you find any >> inaccuracies. >> >> Thanks, >> Mary. >> >> -----Original Message----- >> From: Barnes, Mary (RICH2:AR00) >> Sent: Wednesday, December 09, 2009 9:33 AM >> To: Brett Tate; dispatch@ietf.org >> Subject: RE: [dispatch] locating spawns of DISPATCH >> >> Hi Brett, >> >> That's a good point. I had been summarizing such in the status emails, >> but can see the value in keeping this in a single place. I'll add a page >> to the supplementary webpage on softarmor and send a note to the list >> when that's done. >> >> Thanks, >> Mary. >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Brett Tate >> Sent: Wednesday, December 09, 2009 7:04 AM >> To: dispatch@ietf.org >> Subject: [dispatch] locating spawns of DISPATCH >> >> Greetings, >> >> Are the working group spawns of DISPATCH collected somewhere to easily >> notice them (without searching email archive)? For instance, will they >> be linked somehow to DISPATCH charter, status, or a supplemental >> DISPATCH webpage? >> >> Thanks, >> Brett >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From hgs@cs.columbia.edu Thu Feb 4 11:28:43 2010 Return-Path: <hgs@cs.columbia.edu> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE6F3A6CAD for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 11:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHQIcJimkFYp for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 11:28:41 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id AD2C83A6C8F for <dispatch@ietf.org>; Thu, 4 Feb 2010 11:28:41 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o14JTQbs001968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 14:29:27 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne <hgs@cs.columbia.edu> In-Reply-To: <4A956CE47D1066408D5C7EB34368A51105B98C93@S4DE8PSAAQC.mitte.t-com.de> Date: Thu, 4 Feb 2010 14:29:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <FFED8FA0-51F3-44B6-8CC0-EBA566B2F56B@cs.columbia.edu> References: <BLU137-DS62656FB99E349C1E5E7F793560@phx.gbl> <C78F86EC.C648%henry.sinnreich@gmail.com> <4A956CE47D1066408D5C7EB34368A51105B98C93@S4DE8PSAAQC.mitte.t-com.de> To: "<BeckW@telekom.de>" <BeckW@telekom.de> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2010 19:28:43 -0000 I think for most of us, voice human-to-human, real-time communication is = just a smaller part of the communication universe. The average cell = phone user talks for 459 minutes a month (claims = http://wiki.answers.com/Q/How_many_minutes_does_the_average_cell_phone_cus= tomer_use_per_month), i.e., 15 minutes a day. Most of us spend far more = time on other Internet applications. Except for tele marketers and other = voice-dependent professions, most of our needs so far tend to be fairly = straightforward: reach a person (rather than a device) reliably and = cheaply, preferably without disturbing the person accidentally. Henning On Feb 4, 2010, at 9:56 AM, <BeckW@telekom.de> <BeckW@telekom.de> wrote: >=20 >> 2.1. SIP 2.0 is too expensive for Web application developers > The big question is whether SIP is to blame for this complexity or if = it's in the nature of telephony. Web standards are as complex as SIP. = Only very few web browsers pass the acid3 test. XML is not the most = elegant technology either. >=20 > There must be a different reason why so many develop for the web and = so few for voice. With Flash, it is already possible to do SIP-like = voice/video connections between users. It's rarely used, though. When = eBay bought Skype, everybody expected exciting mash-ups. Nothing = happened.=20 >=20 >> 4.1.1. Applications reside in endpoints of the Internet > Kind of. The success of Web 2.0 was the success of Javascript; = applications run on the endpoint, but are maintained on the server. The = user has no choice which javascript applet to use when accessing a web = 2.0 site. The site owner can update the applet without having to ask the = browser owner for approval. >=20 >=20 > Wolfgang Beck >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Wolfgang Beck > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628 2832 (Tel.) > http://www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From eburger@standardstrack.com Thu Feb 4 17:08:16 2010 Return-Path: <eburger@standardstrack.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7225B3A69D8 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 17:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTyKMTg-L8t7 for <dispatch@core3.amsl.com>; Thu, 4 Feb 2010 17:08:15 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 8B5763A698B for <dispatch@ietf.org>; Thu, 4 Feb 2010 17:08:15 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.178]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1NdCgq-0004G9-AQ; Thu, 04 Feb 2010 17:08:56 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Eric Burger <eburger@standardstrack.com> In-Reply-To: <8e5ec72f1002031221we5a4da6s16c84d8a31543e90@mail.gmail.com> Date: Thu, 4 Feb 2010 20:08:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <BB8E464E-E8C2-4EB0-AE93-0C4DBBF849B2@standardstrack.com> References: <4B69B30E.3010909@gmail.com> <C78F19F0.C5F5%henry.sinnreich@gmail.com> <8e5ec72f1002031221we5a4da6s16c84d8a31543e90@mail.gmail.com> To: Henry Sinnreich <henry.sinnreich@gmail.com> X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: dispatch mailing list <dispatch@ietf.org> Subject: Re: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 01:08:16 -0000 What is totally missing is a comparison to Parlay X. We need something a = bit deeper than REST vs. Web Serivces. On Feb 3, 2010, at 3:21 PM, Peter Musgrave wrote: > Hi Henry,=20 >=20 > (Based on a one-pass read through) >=20 > I like the ideas expressed in this draft. The summary of SIP 2.0 is on = target and the definition of a web API is a good idea. It is something I = can use. >=20 > Moving to HIP is a good idea. >=20 > Regards,=20 >=20 > Peter Musgrave >=20 > On Wed, Feb 3, 2010 at 1:17 PM, Henry Sinnreich = <henry.sinnreich@gmail.com> wrote: > We have published an I-D on "SIP APIs for Web Communications" and = would > appreciate any comments and input. >=20 > Here is the link and the announcement: >=20 > = http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : SIP APIs for Communications on the Web > Author(s) : H. Sinnreich, A. Johnston > Filename : draft-sinnreich-sip-web-apis-00.txt > Pages : 19 > Date : 2010-1-19 >=20 > Interactive communications are becoming part of rich Internet > applications (RIA). This can be accomplished entirely by using Web > technology and developing it as an Internet standard. Voice over IP > (VoIP) features developed for Session Initiation Protocol (SIP 2.0) > can be preserved in rich multimedia communications and applications > on the web. Hyper Text Transport Protocol (HTTP) is used for = control > and signaling data and RTP for interactive media transport > respectively. No other network application protocols are required. > Web, fixed and mobile device application development tools can thus > be used to include components and widgets for Internet presence, > Instant Messaging (IM), voice and video. This opens Internet > communications, including voice to application developers and will > also enhance the user experience with real-time Web and mobile > communications. Usage scenarios include service providers, private > IP networks, device application developers and media companies > providing a mix of integrated communications, applications and = media. > This memo argues for the development and standardization of > Application Programming Interfaces (APIs) to allow the benefits of > SIP to be used by Rich Internet Applications (RIA), for fixed and > mobile devices. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt >=20 > ------ End of Forwarded Message >=20 > Thanks in advance for your comments. >=20 > Henry >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From gonzalo.camarillo@ericsson.com Fri Feb 5 03:12:31 2010 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4629A3A6B68 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 03:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.342 X-Spam-Level: X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zJsrJ9gkv5Q for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 03:12:30 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 021483A69B6 for <dispatch@ietf.org>; Fri, 5 Feb 2010 03:12:29 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-22-4b6bfd4e30db Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 1E.F0.02429.E4DFB6B4; Fri, 5 Feb 2010 12:13:18 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 12:12:39 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 12:12:39 +0100 Message-ID: <4B6BFD27.8060603@ericsson.com> Date: Fri, 05 Feb 2010 13:12:39 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH <dispatch@ietf.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2010 11:12:39.0312 (UTC) FILETIME=[20E98900:01CAA654] X-Brightmail-Tracker: AAAAAA== Cc: Mary Barnes <mbarnes@nortelnetworks.com> Subject: [dispatch] Feedback on the process of chartering mini WGs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 11:12:32 -0000 Folks, Now that we are gaining experience with the new RAI processes, it is important to get feedback on how they are working. We have received some emails indicating that the fact that mini WGs sometimes take a while to get chartered can slow things down. Of course, the faster the mini WGs get chartered the better. However, it is important that folks continue with their technical work in parallel with the chartering process. That is, the technical work does not need to stop when DISPATCH decides to charter a given effort and resume when the mini WG is chartered. It is expected that people continue working while the ADs take care of the chartering process. We have created many mailing lists before the chartering process is over and even face-to-face meetings could be arranged as DISPATCH ad-hocs, if really needed (we have already indicated that work can often progress without face-to-face meetings). So, the tools for people to perform their technical work should be available. Also, we have received feedback regarding chairing mini WGs. It seems some companies see chairing a WG as a long-term commitment and do not make it easy for their people to take on chair roles. Note that the charter of the mini WGs we will be chartering will say that they are short-term focused efforts. Therefore, after two or three IETF cycles the WG will be either done with its deliverables or will be shut down because it did not manage to deliver. In both cases, the chair is not required to make a long-term commitment. Getting further feedback and ideas on these or related issues would of course be great. Thanks, Gonzalo DISPATCH co-chair From john.elwell@siemens-enterprise.com Fri Feb 5 03:40:52 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E9D3A6BDD for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 03:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et23WC2AW5K5 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 03:40:51 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6AEC33A6BF8 for <dispatch@ietf.org>; Fri, 5 Feb 2010 03:40:51 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-790612; Fri, 5 Feb 2010 12:41:40 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 405841EB82AB; Fri, 5 Feb 2010 12:41:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Feb 2010 12:41:40 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: DISPATCH <dispatch@ietf.org> Date: Fri, 5 Feb 2010 12:41:38 +0100 Thread-Topic: Session Recording (RE: [dispatch] Feedback on the process of chartering mini WGs) Thread-Index: AcqmVD0CP3AMnM6DSGW5h/tje5GFcAAA0rSg Message-ID: <A444A0F8084434499206E78C106220CAB9210963@MCHP058A.global-ad.net> References: <4B6BFD27.8060603@ericsson.com> In-Reply-To: <4B6BFD27.8060603@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mary Barnes <mbarnes@nortelnetworks.com> Subject: [dispatch] Session Recording (RE: Feedback on the process of chartering mini WGs) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 11:40:52 -0000 With particular reference to the proposed session recording WG, it seems I = will be called upon to chair this, when it is finally established. I believ= e those interested in this work are keen to see it progressing quickly, so = we should aim to have topics to discuss at IETF#77, either at a meeting of = the new WG, if it is formed by then, or at a DISPATCH ad hoc meeting. So du= ring the next week or so, please give some thought to this and suggest poss= ible agenda items. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 05 February 2010 11:13 > To: DISPATCH > Cc: Mary Barnes > Subject: [dispatch] Feedback on the process of chartering mini WGs >=20 > Folks, >=20 > Now that we are gaining experience with the new RAI processes, it is > important to get feedback on how they are working. >=20 > We have received some emails indicating that the fact that mini WGs > sometimes take a while to get chartered can slow things down.=20 > Of course, > the faster the mini WGs get chartered the better. However, it is > important that folks continue with their technical work in=20 > parallel with > the chartering process. That is, the technical work does not need to > stop when DISPATCH decides to charter a given effort and=20 > resume when the > mini WG is chartered. It is expected that people continue=20 > working while > the ADs take care of the chartering process. We have created many > mailing lists before the chartering process is over and even > face-to-face meetings could be arranged as DISPATCH ad-hocs, if really > needed (we have already indicated that work can often progress without > face-to-face meetings). So, the tools for people to perform their > technical work should be available. >=20 > Also, we have received feedback regarding chairing mini WGs. It seems > some companies see chairing a WG as a long-term commitment and do not > make it easy for their people to take on chair roles. Note that the > charter of the mini WGs we will be chartering will say that they are > short-term focused efforts. Therefore, after two or three IETF cycles > the WG will be either done with its deliverables or will be shut down > because it did not manage to deliver. In both cases, the chair is not > required to make a long-term commitment. >=20 > Getting further feedback and ideas on these or related issues would of > course be great. >=20 > Thanks, >=20 > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From dromasca@avaya.com Fri Feb 5 04:20:34 2010 Return-Path: <dromasca@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66ECB3A6D75 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 04:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmPAbaEXQtfQ for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 04:20:31 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4462C3A6E14 for <dispatch@ietf.org>; Fri, 5 Feb 2010 04:20:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,413,1262581200"; d="scan'208";a="175374086" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Feb 2010 07:21:16 -0500 X-IronPort-AV: E=Sophos;i="4.49,413,1262581200"; d="scan'208";a="442831832" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2010 07:21:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Feb 2010 13:20:54 +0100 Message-ID: <EDC652A26FB23C4EB6384A4584434A0401F0D794@307622ANEX5.global.avaya.com> In-Reply-To: <4B6BFD27.8060603@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Feedback on the process of chartering mini WGs Thread-Index: AcqmVDzHPSoXMF8aRXewIc0iEQ9MSwACGRZA References: <4B6BFD27.8060603@ericsson.com> From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>, "DISPATCH" <dispatch@ietf.org> Cc: Mary Barnes <mbarnes@nortelnetworks.com> Subject: Re: [dispatch] Feedback on the process of chartering mini WGs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 12:20:34 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >=20 > Also, we have received feedback regarding chairing mini WGs.=20 > It seems some companies see chairing a WG as a long-term=20 > commitment and do not make it easy for their people to take=20 > on chair roles. Note that the charter of the mini WGs we will=20 > be chartering will say that they are short-term focused=20 > efforts. Therefore, after two or three IETF cycles the WG=20 > will be either done with its deliverables or will be shut=20 > down because it did not manage to deliver. In both cases, the=20 > chair is not required to make a long-term commitment. >=20 Do we already have experience with any dispatch-originated mini-WG having completed in 2-3 IETF cycles? We need to be careful here, I think, as the task of the WG chairs does not end with the submission of the documents to the IESG but continues during all the review period (with strong involvment in the cases when the chair is also shepherding documents) and we tend to declare WG's concluded and shut them down after the last document in the charter was published. So, shorter life cycles than the usual WG's - yes, two-three cycles as typical life time - I do not know.=20 Dan From ranjit@motorola.com Fri Feb 5 04:24:11 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E74E3A6C05 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 04:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFf0YBm4gngh for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 04:24:09 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 0F84C28C0D0 for <dispatch@ietf.org>; Fri, 5 Feb 2010 04:24:05 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1265372694!16001227!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 31227 invoked from network); 5 Feb 2010 12:24:54 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-11.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Feb 2010 12:24:54 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id o15COrSL015595 for <dispatch@ietf.org>; Fri, 5 Feb 2010 05:24:54 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o15COrjC016972 for <dispatch@ietf.org>; Fri, 5 Feb 2010 06:24:53 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o15COqCm016962 for <dispatch@ietf.org>; Fri, 5 Feb 2010 06:24:53 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Feb 2010 20:24:30 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A2CCF69@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A28B452@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]Commentsrequestedon draft-avasarala-dispatch-comm-div-notification thread-index: Acqfczyz2U7KPqHRQHS3LaMRUH9MSABS1+FwAWffq0A= References: <4B4F2403.7010200@ericsson.com><A444A0F8084434499206E78C106220CA6A158AD0@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com><F1553508-31EC-4947-8696-0545284791F4@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B452@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Cullen Jennings" <fluffy@cisco.com>, "DISPATCH" <dispatch@ietf.org> X-CFilter-Loop: Reflected Subject: Re: [dispatch] Commentsrequestedon draft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 12:24:11 -0000 Hi All Any comments on how we can progress this I-D? Thanks=20 Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Friday, January 29, 2010 2:26 PM To: Cullen Jennings; DISPATCH Subject: Re: [dispatch]Commentsrequestedon draft-avasarala-dispatch-comm-div-notification Hi Cullen This draft is kind of straight forward as it proposes a SIP based XML event package for reporting call diversions that occur in the network on behalf of the subscribers that set call forwarding rules based on various criteria like "incoming caller identity", "time-of-day", etc. The IPR is essentially based on the proposed event package and the call diversion notification service that gets triggered whenever a call gets diverted on behalf of a subscriber. This service is standardized in 3GPP TS 24.604. Now since 3GPP does not standardize XML packages, there was a need to submit an IETF draft and get it standardized. With this intent, we proposed an informational I-D on communication diversion notification event package. So I really do not think there is any other alternate way to accomplish what we are trying to propose in this I-D.=20 Comments welcome Thanks Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, January 27, 2010 10:37 PM To: DISPATCH Subject: Re: [dispatch] Commentsrequestedon draft-avasarala-dispatch-comm-div-notification There are way to accomplish the same end goals as this draft suggests using things that are very likely to predate RIM's IPR on the topic. For example the ideas on using things similar to the dialog events package or reporting events about call forking on proxies. I have a strong preference for doing this in an IPR free way. I strongly encourage the WG to explore alternative ways to solve these problems before deciding what to do with this draft.=20 Cullen <in my individual contributor role> On Jan 15, 2010, at 2:49 AM, Avasarala Ranjit-A20990 wrote: > Hi John >=20 > Yes the notifications are generated for the AoR (contact) for which=20 > the diversion has occurred. >=20 > So even though there could be multiple contacts registered for a=20 > particular AoR, if the diversion has occurred for a particular contact > say alice at cellphone, then the notification information would go=20 > only to her cellphone and not to all registered contacts. This way we > would be limiting the number of notifications that are sent. >=20 > In current call diversion service configurations, there is no concept=20 > of notifying subscribers when a particular call gets diverted based on > a particular rule. >=20 > Considering the case of Alice@example.com. Lets say Alice has setup a=20 > call diversion rule for her cellphone to divert all calls from a=20 > particular caller between 9 AM and 10 AM to her voicemail. But for=20 > some reason she could have wrongly configured the rule as 9 to 10 AM=20 > or could have put the caller id as wrong one. So it would be very=20 > difficult for her to manually spot this error by reviewing the=20 > complete set of call diversion services. So in order to facilitate=20 > Alice to effectively find out the error, a notification mechanism is required. >=20 > So here th URI for subscription would be the URI that is associated=20 > with diversion . E.g. Alice@cellhone or Alice@deskphone, etc. >=20 > Thanks >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Friday, January 15, 2010 2:57 PM > To: Gonzalo Camarillo; DISPATCH > Subject: Re: [dispatch] Comments requestedon=20 > draft-avasarala-dispatch-comm-div-notification >=20 > I reserve judgement on how useful this would be. Concerning comments=20 > from Paul, I could imagine that the SUBSCRIBE request is addressed to=20 > the AOR URI for which notifications of diverted inbound requests are=20 > required, and that information from that AOR's domain proxy would be=20 > used as the basis for notifications. So the notifier would need=20 > somehow to be coupled to the domain proxy. This could certainly do=20 > with clarification. >=20 > It is unclear to me how one would handle a subscription in the=20 > following circumstances. The subscription is to alice@example.com. At=20 > any given time, there might be several contacts registered against=20 > alice@example.com. According to relative priorities of those contacts, > scripting rules at the proxy, caller preferences, etc., a given=20 > inbound request to Alice would go to one or more of those contacts. Is > it the intention that those contacts that do not receive that inbound=20 > request would receive a notification within the context of this event package? > So if Alice's deskphone is one contact and her cellphone is another=20 > contact, if her current rules are for calls to go to her cellphone,=20 > her deskphone would receive notifications, and vice versa? >=20 > Or is that out of scope? Is the intention to limit the scope to cases=20 > where an inbound communication is diverted away from the AOR concerned? >=20 > John >=20 >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: 14 January 2010 14:03 >> To: DISPATCH >> Subject: [dispatch] Comments requested on=20 >> draft-avasarala-dispatch-comm-div-notification >>=20 >> Hi, >>=20 >> we would like to ask for comments on the following draft. Do you find >> it useful? Do you think it should be published as an RFC? >>=20 >> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n >> otification-02 >>=20 >> Based on the comments received, we will talk to our ADs about this=20 >> piece of work. >>=20 >> Thanks, >>=20 >> Gonzalo >> DISPATCH co-chair >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From gonzalo.camarillo@ericsson.com Fri Feb 5 05:29:58 2010 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5653728C10A for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.307 X-Spam-Level: X-Spam-Status: No, score=-103.307 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ3ia89h4zXU for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:29:57 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 55A613A6F02 for <dispatch@ietf.org>; Fri, 5 Feb 2010 05:29:57 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-15-4b6c1d857ba0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4A.86.31641.58D1C6B4; Fri, 5 Feb 2010 14:30:45 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 14:30:45 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 14:30:45 +0100 Message-ID: <4B6C1D85.3020306@ericsson.com> Date: Fri, 05 Feb 2010 15:30:45 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" <dromasca@avaya.com> References: <4B6BFD27.8060603@ericsson.com> <EDC652A26FB23C4EB6384A4584434A0401F0D794@307622ANEX5.global.avaya.com> In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401F0D794@307622ANEX5.global.avaya.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2010 13:30:45.0169 (UTC) FILETIME=[6BAAFA10:01CAA667] X-Brightmail-Tracker: AAAAAA== Cc: Mary Barnes <mbarnes@nortelnetworks.com>, DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Feedback on the process of chartering mini WGs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 13:29:58 -0000 Hi Dan, good point. This is something worthwhile considering. In any case, after the WG submits all its documents to the IESG, the chair/shepherd's commitment level is comparable to that of a document editor. That is, it has to monitor (and help with) the progression of the draft but does not need to perform many other administrative-oriented activities chairs normally do. Therefore, their work load should be lower at that point in time. Thanks for the feedback! Gonzalo Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > >> Also, we have received feedback regarding chairing mini WGs. >> It seems some companies see chairing a WG as a long-term >> commitment and do not make it easy for their people to take >> on chair roles. Note that the charter of the mini WGs we will >> be chartering will say that they are short-term focused >> efforts. Therefore, after two or three IETF cycles the WG >> will be either done with its deliverables or will be shut >> down because it did not manage to deliver. In both cases, the >> chair is not required to make a long-term commitment. >> > > Do we already have experience with any dispatch-originated mini-WG > having completed in 2-3 IETF cycles? We need to be careful here, I > think, as the task of the WG chairs does not end with the submission of > the documents to the IESG but continues during all the review period > (with strong involvment in the cases when the chair is also shepherding > documents) and we tend to declare WG's concluded and shut them down > after the last document in the charter was published. So, shorter life > cycles than the usual WG's - yes, two-three cycles as typical life time > - I do not know. > > Dan From scottlawrenc@avaya.com Fri Feb 5 05:34:55 2010 Return-Path: <scottlawrenc@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DA43A6805 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DtLwVSBpPLO for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:34:54 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9B1AE28C11A for <dispatch@ietf.org>; Fri, 5 Feb 2010 05:34:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,413,1262581200"; d="scan'208";a="175381973" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Feb 2010 08:35:42 -0500 X-IronPort-AV: E=Sophos;i="4.49,413,1262581200"; d="scan'208";a="442851112" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2010 08:35:40 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o15DZJl10143; Fri, 5 Feb 2010 13:35:19 GMT Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o15DZH720955; Fri, 5 Feb 2010 13:35:17 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 08:35:16 -0500 From: "Scott Lawrence" <scottlawrenc@avaya.com> To: Spencer Dawkins <spencer@wonderhamster.org> In-Reply-To: <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD@mail> <010201ca8335$9e5a3de0$db0eb9a0$@us> <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> Content-Type: text/plain Organization: Avaya Date: Fri, 05 Feb 2010 08:35:15 -0500 Message-Id: <1265376915.3931.153.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2010 13:35:16.0498 (UTC) FILETIME=[0D647F20:01CAA668] Cc: dispatch@ietf.org, 'Hadriel Kaplan' <HKaplan@acmepacket.com> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 13:34:55 -0000 Hadriel Kaplan wrote: > >> I've re-submitted a draft I originally submitted to the SIP WG back > >> when it was in existence. The draft defines a session correlation > >> identifier for troubleshooting purposes. > >> > There are several reasons for having a globally unique session > >> > identifier for the same SIP session, which can be maintained across > >> > B2BUAs and other SIP middle-boxes. This draft proposes a new SIP > >> > header to carry such a value: Session-ID. Spencer Dawkins adds: > I'm remembering that Hadriel had two drafts at about the same time - one was > a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot of > confusion during discussions. > > So I'm hoping that at least some of the objection was caused by confusion! > > https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ and > https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just for > the record... I agree with Hadriel that the 'secure call id' draft actually solves some different problems (and think that draft should certainly be progressed - we've already started implementing the ideas in it in some of our user agents). The problem of correlation across middleboxes of various kinds is certainly an important one, and deserving of attention. I'd like to point out that there is another draft that helps with some of the other more complex scenarios in which one is attempting to determine the relationship between different sessions: http://tools.ietf.org/html/draft-worley-references The References Header for SIP we've also been using this in our products and found it very useful. With respect to what to do about the session-id proposal: I think that in some perfect world that we don't live in, it would be better to adopt the secure-call-id proposal and also make the rule that such ids MUST NOT be changed when passing through a B2BUA; the call-id would then have the characteristics that the session-id needs. I accept, however, that this big a change to the handling of call-id by existing products is unlikely. It seems to me that session-id as proposed is valuable iff we can reach a consensus that existing non-proxy middleboxes (whether they are called SBCs or Application Servers or whatever) will pass these through unmodified, or at least that in some reasonable time they can be convinced to start doing so. Based on the discussion to date, I'm not yet convinced of that... I wonder whether or not it's time that we bit the bullet and try to actually comprehensively write down what the correct and harmful behaviors for non-proxy middleboxes are? From peter.musgrave@magorcorp.com Fri Feb 5 05:47:08 2010 Return-Path: <peter.musgrave@magorcorp.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52B028C10A for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz9tDjfcXu6Q for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:47:08 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id AB8FE28C159 for <dispatch@ietf.org>; Fri, 5 Feb 2010 05:47:07 -0800 (PST) Received: by ewy28 with SMTP id 28so4296801ewy.28 for <dispatch@ietf.org>; Fri, 05 Feb 2010 05:47:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.90.208 with SMTP id e58mr456829wef.57.1265377674621; Fri, 05 Feb 2010 05:47:54 -0800 (PST) In-Reply-To: <1265376915.3931.153.camel@scott> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD@mail> <010201ca8335$9e5a3de0$db0eb9a0$@us> <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> <1265376915.3931.153.camel@scott> Date: Fri, 5 Feb 2010 08:47:53 -0500 Message-ID: <8e5ec72f1002050547k72aa1923p6fdffb5f8eb1fcf4@mail.gmail.com> From: Peter Musgrave <peter.musgrave@magorcorp.com> To: Scott Lawrence <scottlawrenc@avaya.com> Content-Type: multipart/alternative; boundary=0016e6db2ae7cd735b047edab249 Cc: dispatch@ietf.org, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 13:47:08 -0000 --0016e6db2ae7cd735b047edab249 Content-Type: text/plain; charset=ISO-8859-1 > I wonder whether or not it's time that we bit the bullet and try to > actually comprehensively write down what the correct and harmful > behaviors for non-proxy middleboxes are? > I think there is merit is providing guidance. SIP middle boxes are here to stay. There is some stuff along these line in the expired http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 (although I Just noticed Dale's new draft http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 and I'm not sure if there is any overlap). Peter --0016e6db2ae7cd735b047edab249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I wonder whether or not it's time that we bit the bullet and try to<br> actually comprehensively write down what the correct and harmful<br> behaviors for non-proxy middleboxes are?<br></blockquote><div><br></div><di= v>I think there is merit is providing guidance. SIP middle boxes are here t= o stay.</div><div><br></div><div>There is some stuff along these line in th= e expired <a href=3D"http://tools.ietf.org/html/draft-marjou-sipping-b2bua-= 01">http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01</a></div> <div><br></div><div>(although I Just noticed Dale's new draft =A0<a hre= f=3D"http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00">htt= p://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00</a> and I= 9;m not sure if there is any overlap).</div> <div><br></div><div>Peter</div></div><br> --0016e6db2ae7cd735b047edab249-- From john.elwell@siemens-enterprise.com Fri Feb 5 05:55:44 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1910928C15A for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj+RpEps8TaP for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 05:55:43 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CE2543A692A for <dispatch@ietf.org>; Fri, 5 Feb 2010 05:55:42 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-793156; Fri, 5 Feb 2010 14:56:29 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id EACB523F0278; Fri, 5 Feb 2010 14:56:29 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Feb 2010 14:56:29 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Scott Lawrence <scottlawrenc@avaya.com>, Spencer Dawkins <spencer@wonderhamster.org> Date: Fri, 5 Feb 2010 14:56:28 +0100 Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: AcqmaCEC/5FADvR9Qd2RZAgQukqEHAAAec8Q Message-ID: <A444A0F8084434499206E78C106220CAB9210A7C@MCHP058A.global-ad.net> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD@mail> <010201ca8335$9e5a3de0$db0eb9a0$@us> <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> <1265376915.3931.153.camel@scott> In-Reply-To: <1265376915.3931.153.camel@scott> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org>, 'Hadriel Kaplan' <HKaplan@acmepacket.com> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 13:55:44 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence > Sent: 05 February 2010 13:35 > To: Spencer Dawkins > Cc: dispatch@ietf.org; 'Hadriel Kaplan' > Subject: Re: [dispatch] FW:=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hadriel Kaplan wrote: >=20 > > >> I've re-submitted a draft I originally submitted to the=20 > SIP WG back > > >> when it was in existence. The draft defines a session=20 > correlation > > >> identifier for troubleshooting purposes. >=20 > > >> > There are several reasons for having a globally unique session > > >> > identifier for the same SIP session, which can be=20 > maintained across > > >> > B2BUAs and other SIP middle-boxes. This draft=20 > proposes a new SIP > > >> > header to carry such a value: Session-ID. >=20 > Spencer Dawkins adds: >=20 > > I'm remembering that Hadriel had two drafts at about the=20 > same time - one was=20 > > a BCP on Call-ID, and one was on Session ID, and I'm=20 > remembering a lot of=20 > > confusion during discussions. > >=20 > > So I'm hoping that at least some of the objection was=20 > caused by confusion! > >=20 > >=20 > https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-ca > ll-id/ and > >=20 > https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-i > d/, just for=20 > > the record... >=20 > I agree with Hadriel that the 'secure call id' draft actually solves > some different problems (and think that draft should certainly be > progressed - we've already started implementing the ideas in=20 > it in some > of our user agents).=20 >=20 > The problem of correlation across middleboxes of various kinds is > certainly an important one, and deserving of attention. =20 >=20 > I'd like to point out that there is another draft that helps with some > of the other more complex scenarios in which one is attempting to > determine the relationship between different sessions:=20 >=20 > http://tools.ietf.org/html/draft-worley-references > The References Header for SIP >=20 > we've also been using this in our products and found it very useful. >=20 > With respect to what to do about the session-id proposal: I think that > in some perfect world that we don't live in, it would be=20 > better to adopt > the secure-call-id proposal and also make the rule that such ids MUST > NOT be changed when passing through a B2BUA; the call-id=20 > would then have > the characteristics that the session-id needs. I accept,=20 > however, that > this big a change to the handling of call-id by existing products is > unlikely. >=20 > It seems to me that session-id as proposed is valuable iff we=20 > can reach > a consensus that existing non-proxy middleboxes (whether they=20 > are called > SBCs or Application Servers or whatever) will pass these through > unmodified, or at least that in some reasonable time they can be > convinced to start doing so. Based on the discussion to date, I'm not > yet convinced of that... >=20 > I wonder whether or not it's time that we bit the bullet and try to > actually comprehensively write down what the correct and harmful > behaviors for non-proxy middleboxes are? [JRE] If somebody is able to put together a draft, that would be good. Howe= ver, bear in mind that some non-proxy middle-boxes carry out 3PCC, and this= can lead to situations where the two ends of a call can comprise component= s of two former calls, and therefore will not have the same call-ID even if= the two former calls had the same call-ID end-to-end. Yes, I know SIP has = capabilities that theoretically make 3PCC unnecessary, but practical situat= ions are likely to mean it stays around for the foreseeable future, e.g., p= olicies that don't admit a REFER from another domain. John >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From scottlawrenc@avaya.com Fri Feb 5 06:02:59 2010 Return-Path: <scottlawrenc@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5908728C15C for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 06:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FptSf2HG-bO5 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 06:02:58 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DCB6D3A6F02 for <dispatch@ietf.org>; Fri, 5 Feb 2010 06:02:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,413,1262581200"; d="scan'208";a="175385864" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Feb 2010 09:03:46 -0500 X-IronPort-AV: E=Sophos;i="4.49,413,1262581200"; d="scan'208";a="442861854" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2010 09:03:44 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o15E3Nl18167; Fri, 5 Feb 2010 14:03:23 GMT Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o15E3Kl26903; Fri, 5 Feb 2010 14:03:20 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 09:03:17 -0500 From: "Scott Lawrence" <scottlawrenc@avaya.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com> In-Reply-To: <A444A0F8084434499206E78C106220CAB9210A7C@MCHP058A.global-ad.net> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD@mail> <010201ca8335$9e5a3de0$db0eb9a0$@us> <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> <1265376915.3931.153.camel@scott> <A444A0F8084434499206E78C106220CAB9210A7C@MCHP058A.global-ad.net> Content-Type: text/plain Organization: Avaya Date: Fri, 05 Feb 2010 09:03:16 -0500 Message-Id: <1265378596.3931.161.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2010 14:03:18.0056 (UTC) FILETIME=[F7ADE280:01CAA66B] Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Scott Lawrence <scottlawrenc@avaya.com>, 'Hadriel Kaplan' <HKaplan@acmepacket.com> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 14:02:59 -0000 On Fri, 2010-02-05 at 14:56 +0100, Elwell, John wrote: > [JRE] If somebody is able to put together a draft, that would be good. > However, bear in mind that some non-proxy middle-boxes carry out 3PCC, > and this can lead to situations where the two ends of a call can > comprise components of two former calls, and therefore will not have > the same call-ID even if the two former calls had the same call-ID > end-to-end. Yes, I know SIP has capabilities that theoretically make > 3PCC unnecessary, but practical situations are likely to mean it stays > around for the foreseeable future, e.g., policies that don't admit a > REFER from another domain. Adding a References header as proposed in Dales draft helps with correlating those situations. From Peter.Dawes@vodafone.com Fri Feb 5 06:59:02 2010 Return-Path: <Peter.Dawes@vodafone.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2217D3A690A for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 06:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHJie0FQEMyf for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 06:59:00 -0800 (PST) Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by core3.amsl.com (Postfix) with ESMTP id 37F073A6822 for <dispatch@ietf.org>; Fri, 5 Feb 2010 06:58:59 -0800 (PST) Received: from mailint06 (localhost [127.0.0.1]) by mailout06 (Postfix) with ESMTP id 17F8A846BB for <dispatch@ietf.org>; Fri, 5 Feb 2010 15:59:47 +0100 (CET) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint06 (Postfix) with ESMTPS id 07E338402B; Fri, 5 Feb 2010 15:59:47 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 15:59:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Feb 2010 15:59:44 +0100 Message-ID: <C6A11A02FF1FBF438477BB38132E474105BA6C31@EITO-MBX02.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: Acqmc9oLJApMpvsWTo+rWDRROhjahg== From: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> To: <dispatch@ietf.org> X-OriginalArrivalTime: 05 Feb 2010 14:59:48.0484 (UTC) FILETIME=[DC882440:01CAA673] Cc: Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, L.Liess@telekom.de, HKaplan@acmepacket.com Subject: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 14:59:02 -0000 Hello, Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 +0200) as "1) We have Hadriel's draft, 2) We also have the following draft, which eventually led to the disaggregated media work: http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog-correlati on-01.txt 3) We also have the SIP-XMPP work, which may also need to correlate sessions somehow." I would like to add http://tools.ietf.org/html/draft-dawes-sipping-debug-02 to this discussion of use cases for some form of correlation identifier. This draft relates to debugging/troubleshooting to meet documented requirements from 3GPP and OMA, and proposes a kind of correlation identifier in a new header. Regards, Peter Message: 2 Date: Fri, 22 Jan 2010 11:05:57 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt To: L.Liess@telekom.de Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de Message-ID: <4B59CCE5.2010202@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed L.Liess@telekom.de wrote: > Paul, >=20 > Thank you for the examples. The scenarios can be really complex. I hope we can get these correlation identifiers, whatever their names, to work correctly in all cases....=20 >=20 > I am not sure I understood your message correctly. Do you say we should have two different identifiers because we use them for two different things?=20 I think there may be more than two distinct usages that will require=20 different ones. IMO use cases should be gathered and then bucketed into sets that can be satisfied by a single mechanism, without assuming initially how many=20 buckets there will be. (But I'm still on record as not being convinced that a correlation id is needed *at all* for the case when multiple sip UAs are participating on=20 behalf of a single user in a call.) > Thanks a lot > Laura >=20 From spencer@wonderhamster.org Fri Feb 5 07:10:51 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A543A6DC8 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 07:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP61d+YAF8LI for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 07:10:49 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 156163A6DC4 for <dispatch@ietf.org>; Fri, 5 Feb 2010 07:10:49 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LaVpn-1O1RrT2KMR-00lsex; Fri, 05 Feb 2010 10:11:30 -0500 Message-ID: <E38A67DDE7774FA3A895CF003F4C5874@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com>, <dispatch@ietf.org> References: <C6A11A02FF1FBF438477BB38132E474105BA6C31@EITO-MBX02.internal.vodafone.com> Date: Fri, 5 Feb 2010 09:11:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19uyPXS+YVNxI8WPFUZDIhLqMyK6JY7Ef53+Ok DumNGQ9qK8sL+7WGFCwT1AKkHRCohu4aoNKgUMbdAME6V3tuxc ji3VPN/IFlM+h/lTvfXU5GCMvw4NOTqmMnoCzmJ624= Cc: L.Liess@telekom.de, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 15:10:51 -0000 This is all excellent, of course. My question is, what will it take for us to move forward on some flavor of a Session-ID (or other header field) that SIPCLF (for example) can use to correlate log entries collected from various SIP entities? Bar BOF in Anaheim? Or can we propose something more concrete in the next small number of weeks? Thanks, Spencer ----- Original Message ----- From: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> To: <dispatch@ietf.org> Cc: <Martin.Huelsemann@telekom.de>; <Gerold.Pinker@telekom.de>; <gonzalo.camarillo@ericsson.com>; <L.Liess@telekom.de>; <HKaplan@acmepacket.com> Sent: Friday, February 05, 2010 8:59 AM Subject: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt > Hello, > Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 +0200) as > "1) We have Hadriel's draft, 2) We also have the following draft, which > eventually led to the disaggregated media work: > http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog-correlati > on-01.txt 3) We also have the SIP-XMPP work, which may also need to > correlate sessions somehow." > > I would like to add > http://tools.ietf.org/html/draft-dawes-sipping-debug-02 to this > discussion of use cases for some form of correlation identifier. This > draft relates to debugging/troubleshooting to meet documented > requirements from 3GPP and OMA, and proposes a kind of correlation > identifier in a new header. > > Regards, > Peter > > > Message: 2 > Date: Fri, 22 Jan 2010 11:05:57 -0500 > From: Paul Kyzivat <pkyzivat@cisco.com> > Subject: Re: [dispatch] FW: > I-DAction:draft-kaplan-dispatch-session-id-00.txt > To: L.Liess@telekom.de > Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, > Gerold.Pinker@telekom.de > Message-ID: <4B59CCE5.2010202@cisco.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > L.Liess@telekom.de wrote: >> Paul, >> >> Thank you for the examples. The scenarios can be really complex. I > hope we can get these correlation identifiers, whatever their names, to > work correctly in all cases.... >> >> I am not sure I understood your message correctly. Do you say we > should have two different identifiers because we use them for two > different things? > > I think there may be more than two distinct usages that will require > different ones. > > IMO use cases should be gathered and then bucketed into sets that can be > > satisfied by a single mechanism, without assuming initially how many > buckets there will be. > > (But I'm still on record as not being convinced that a correlation id is > > needed *at all* for the case when multiple sip UAs are participating on > behalf of a single user in a call.) > >> Thanks a lot >> Laura >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Fri Feb 5 07:47:11 2010 Return-Path: <adam@nostrum.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AAF28C0F5 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 07:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3qDYvm2VO0a for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 07:47:10 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5C38D3A6813 for <dispatch@ietf.org>; Fri, 5 Feb 2010 07:47:08 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o15FlaVJ030050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 09:47:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C3D97.6080103@nostrum.com> Date: Fri, 05 Feb 2010 09:47:35 -0600 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 <ranjit@motorola.com> References: <4B4F2403.7010200@ericsson.com><A444A0F8084434499206E78C106220CA6A158AD0@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com><F1553508-31EC-4947-8696-0545284791F4@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B452@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CCF69@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A2CCF69@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Commentsrequestedon draft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 15:47:11 -0000 Sorry; I just now tripped across this. Probably the most important work the IETF does to foster innovation lies not in what we choose to standardize, but in what we choose to leave unstandardized. With rare exception, the IETF does not standardize how to implement services in SIP. One of the key philosophies that has been central to the development of the SIP protocol is that the IETF defines a rich and powerful set of protocol tools, and allows application developers to implement services using these tools. This draft, however, is standardizing a service. No part of this is re-usable in any way. So, what we really need to do here is back up to requirements: what are you trying to achieve? I looked through 24.604 briefly, and think I understand what you're trying to do here. And I'm sure you can define some generally useful, re-usable tools to achieve your goals. I would offer that a general-purpose means for subscribing to the target generation steps at a SIP proxy would be both generally useful and sufficient to implement the service you have in mind. /a On 2/5/10 6:24 AM, Avasarala Ranjit-A20990 wrote: > Hi All > > Any comments on how we can progress this I-D? > > Thanks > > > Regards > Ranjit > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Avasarala Ranjit-A20990 > Sent: Friday, January 29, 2010 2:26 PM > To: Cullen Jennings; DISPATCH > Subject: Re: [dispatch]Commentsrequestedon > draft-avasarala-dispatch-comm-div-notification > > Hi Cullen > > This draft is kind of straight forward as it proposes a SIP based XML > event package for reporting call diversions that occur in the network on > behalf of the subscribers that set call forwarding rules based on > various criteria like "incoming caller identity", "time-of-day", etc. > > The IPR is essentially based on the proposed event package and the call > diversion notification service that gets triggered whenever a call gets > diverted on behalf of a subscriber. This service is standardized in 3GPP > TS 24.604. Now since 3GPP does not standardize XML packages, there was a > need to submit an IETF draft and get it standardized. With this intent, > we proposed an informational I-D on communication diversion notification > event package. > > So I really do not think there is any other alternate way to accomplish > what we are trying to propose in this I-D. > > Comments welcome > > Thanks > > Regards > Ranjit > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Wednesday, January 27, 2010 10:37 PM > To: DISPATCH > Subject: Re: [dispatch] Commentsrequestedon > draft-avasarala-dispatch-comm-div-notification > > > > There are way to accomplish the same end goals as this draft suggests > using things that are very likely to predate RIM's IPR on the topic. For > example the ideas on using things similar to the dialog events package > or reporting events about call forking on proxies. I have a strong > preference for doing this in an IPR free way. I strongly encourage the > WG to explore alternative ways to solve these problems before deciding > what to do with this draft. > > Cullen<in my individual contributor role> > > > > On Jan 15, 2010, at 2:49 AM, Avasarala Ranjit-A20990 wrote: > > >> Hi John >> >> Yes the notifications are generated for the AoR (contact) for which >> the diversion has occurred. >> >> So even though there could be multiple contacts registered for a >> particular AoR, if the diversion has occurred for a particular contact >> > >> say alice at cellphone, then the notification information would go >> only to her cellphone and not to all registered contacts. This way we >> > >> would be limiting the number of notifications that are sent. >> >> In current call diversion service configurations, there is no concept >> of notifying subscribers when a particular call gets diverted based on >> > >> a particular rule. >> >> Considering the case of Alice@example.com. Lets say Alice has setup a >> call diversion rule for her cellphone to divert all calls from a >> particular caller between 9 AM and 10 AM to her voicemail. But for >> some reason she could have wrongly configured the rule as 9 to 10 AM >> or could have put the caller id as wrong one. So it would be very >> difficult for her to manually spot this error by reviewing the >> complete set of call diversion services. So in order to facilitate >> Alice to effectively find out the error, a notification mechanism is >> > required. > >> So here th URI for subscription would be the URI that is associated >> with diversion . E.g. Alice@cellhone or Alice@deskphone, etc. >> >> Thanks >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Elwell, John >> Sent: Friday, January 15, 2010 2:57 PM >> To: Gonzalo Camarillo; DISPATCH >> Subject: Re: [dispatch] Comments requestedon >> draft-avasarala-dispatch-comm-div-notification >> >> I reserve judgement on how useful this would be. Concerning comments >> from Paul, I could imagine that the SUBSCRIBE request is addressed to >> the AOR URI for which notifications of diverted inbound requests are >> required, and that information from that AOR's domain proxy would be >> used as the basis for notifications. So the notifier would need >> somehow to be coupled to the domain proxy. This could certainly do >> with clarification. >> >> It is unclear to me how one would handle a subscription in the >> following circumstances. The subscription is to alice@example.com. At >> any given time, there might be several contacts registered against >> alice@example.com. According to relative priorities of those contacts, >> > >> scripting rules at the proxy, caller preferences, etc., a given >> inbound request to Alice would go to one or more of those contacts. Is >> > >> it the intention that those contacts that do not receive that inbound >> request would receive a notification within the context of this event >> > package? > >> So if Alice's deskphone is one contact and her cellphone is another >> contact, if her current rules are for calls to go to her cellphone, >> her deskphone would receive notifications, and vice versa? >> >> Or is that out of scope? Is the intention to limit the scope to cases >> where an inbound communication is diverted away from the AOR >> > concerned? > >> John >> >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>> Sent: 14 January 2010 14:03 >>> To: DISPATCH >>> Subject: [dispatch] Comments requested on >>> draft-avasarala-dispatch-comm-div-notification >>> >>> Hi, >>> >>> we would like to ask for comments on the following draft. Do you find >>> > >>> it useful? Do you think it should be published as an RFC? >>> >>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n >>> otification-02 >>> >>> Based on the comments received, we will talk to our ADs about this >>> piece of work. >>> >>> Thanks, >>> >>> Gonzalo >>> DISPATCH co-chair >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ian.elz@ericsson.com Fri Feb 5 07:51:24 2010 Return-Path: <ian.elz@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057E328C171 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 07:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyn9v2H+n8VE for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 07:51:22 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 704E03A6EA3 for <dispatch@ietf.org>; Fri, 5 Feb 2010 07:51:22 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-29-4b6c3eab760a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 06.77.31641.BAE3C6B4; Fri, 5 Feb 2010 16:52:12 +0100 (CET) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.204]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 5 Feb 2010 16:52:11 +0100 From: Ian Elz <ian.elz@ericsson.com> To: Peter Musgrave <peter.musgrave@magorcorp.com>, Scott Lawrence <scottlawrenc@avaya.com> Date: Fri, 5 Feb 2010 16:52:09 +0100 Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: AcqmdYld4nvzFpU/Rou9s+aBtJdTCQAA19HQ Message-ID: <D63DB3A4C85587439C3BA6A32D1D0943036A054080@ESESSCMS0352.eemea.ericsson.se> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD@mail> <010201ca8335$9e5a3de0$db0eb9a0$@us> <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> <1265376915.3931.153.camel@scott> <8e5ec72f1002050547k72aa1923p6fdffb5f8eb1fcf4@mail.gmail.com> In-Reply-To: <8e5ec72f1002050547k72aa1923p6fdffb5f8eb1fcf4@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D63DB3A4C85587439C3BA6A32D1D0943036A054080ESESSCMS0352e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 15:51:24 -0000 --_000_D63DB3A4C85587439C3BA6A32D1D0943036A054080ESESSCMS0352e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The contents of the two drafts mentioned below is basically similar. The or= iginal draft contained more detail (and was perhaps harder to read as a res= ult) but the proposals are the same. The solution proposed is only applicable managing mapped dialog identities = in the headers which reference other dialogs. The problem should be expande= d to include bodies which reference other dialogs. This was mentioned in dr= aft-marjou but a solution was not explored. The problem with using a solution as proposed in these drafts is that to pe= rform the dialog mapping in the bodies requires every node which modifies a= dialog identity parameter (call-id,to and from tags) to be able to underst= and every body which may contain a reference to other dialogs. I don't beli= eve that this is practical. To require that every B2BUA should be able to d= ecode, modify, and re-encode every body which may contain a dialog referenc= e is impractical. Hadriel's secure call id draft goes some way to solving the problem of node= s mapping the call-id but it will not solve the issue. B2BUAs also modify t= he to and from tags in the dialogs on either side of the B2BUA. Just using = an unchanged secure call id will not solve the issue when the tags are also= mapped. The original Session-id proposal to use an end-to-end identifier which woul= d be passed transparently has more promise of a final solution. It was a sh= ame that the usage of this proposed header was deprecated to just tracing b= efore the full opportunities could be explored. I understand that there are= issues associated with forking and 3PCC but these should be resolvable. As for guidance then this is probably a good thing but it will only ever be= guidance. There are too many nodes deployed which will not follow any guid= ance to ensure that they all follow ant rules which are written now. It is = also easier to insert a B2BUA to overcome a specific problem as you can mov= e outside the defined protocol rules inside the node. Ian Elz ________________________________ From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: 05 February 2010 13:48 To: Scott Lawrence Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.t= xt I wonder whether or not it's time that we bit the bullet and try to actually comprehensively write down what the correct and harmful behaviors for non-proxy middleboxes are? I think there is merit is providing guidance. SIP middle boxes are here to = stay. There is some stuff along these line in the expired http://tools.ietf.org/h= tml/draft-marjou-sipping-b2bua-01 (although I Just noticed Dale's new draft http://tools.ietf.org/html/draft= -worley-sipcore-b2bua-passthru-00 and I'm not sure if there is any overlap)= . Peter --_000_D63DB3A4C85587439C3BA6A32D1D0943036A054080ESESSCMS0352e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18865"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>The contents of the two drafts mentioned below is bas= ically=20 similar. The original draft contained more detail (and was perhaps harder t= o=20 read as a result) but the proposals are the same.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>The solution proposed is only applicable managing map= ped=20 dialog identities in the headers which reference other dialogs. The problem= =20 should be expanded to include bodies which reference other dialogs. This wa= s=20 mentioned in draft-marjou but a solution was not explored.</FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>The problem with using a solution as proposed in thes= e drafts=20 is that to perform the dialog mapping in the bodies requires every node whi= ch=20 modifies a dialog identity parameter (call-id,to and from tags) to be able = to=20 understand every body which may contain a reference to other dialogs. I don= 't=20 believe that this is practical. To require that every B2BUA should be able = to=20 decode, modify, and re-encode every body which may contain a dialog referen= ce is=20 impractical.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>Hadriel's secure call id draft goes some way to solvi= ng the=20 problem of nodes mapping the call-id but it will not solve the issue. B2BUA= s=20 also modify the to and from tags in the dialogs on either side of the B2BUA= .=20 Just using an unchanged secure call id will not solve the issue when the ta= gs=20 are also mapped.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>The original Session-id proposal to use an end-to-end= =20 identifier which would be passed transparently has more promise of a final= =20 solution. It was a shame that the usage of this proposed header was depreca= ted=20 to just tracing before the full opportunities could be explored. I understa= nd=20 that there are issues associated with forking and 3PCC but these should be= =20 resolvable.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>As for guidance then this is probably a good thing bu= t it will=20 only ever be guidance. There are too many nodes deployed which will not fol= low=20 any guidance to ensure that they all follow ant rules which are written now= . It=20 is also easier to insert a B2BUA to overcome a specific problem as you can = move=20 outside the defined protocol rules inside the node.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D270563515-05022010><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>Ian Elz</FONT></SPAN></DIV><BR> <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"> <DIV dir=3Dltr lang=3Den-us class=3DOutlookMessageHeader align=3Dleft> <HR tabIndex=3D-1> <FONT size=3D2 face=3DTahoma><B>From:</B> Peter Musgrave=20 [mailto:peter.musgrave@magorcorp.com] <BR><B>Sent:</B> 05 February 2010=20 13:48<BR><B>To:</B> Scott Lawrence<BR><B>Cc:</B> dispatch@ietf.org; Hadri= el=20 Kaplan<BR><B>Subject:</B> Re: [dispatch] FW:=20 I-DAction:draft-kaplan-dispatch-session-id-00.txt<BR></FONT><BR></DIV> <DIV></DIV><BR> <DIV class=3Dgmail_quote> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-= LEFT: 1ex"=20 class=3Dgmail_quote>I wonder whether or not it's time that we bit the bul= let=20 and try to<BR>actually comprehensively write down what the correct and= =20 harmful<BR>behaviors for non-proxy middleboxes are?<BR></BLOCKQUOTE> <DIV><BR></DIV> <DIV>I think there is merit is providing guidance. SIP middle boxes are h= ere=20 to stay.</DIV> <DIV><BR></DIV> <DIV>There is some stuff along these line in the expired <A=20 href=3D"http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01">http://= tools.ietf.org/html/draft-marjou-sipping-b2bua-01</A></DIV> <DIV><BR></DIV> <DIV>(although I Just noticed Dale's new draft  <A=20 href=3D"http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00= ">http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00</A>=20 and I'm not sure if there is any overlap).</DIV> <DIV><BR></DIV> <DIV>Peter</DIV></DIV><BR></BLOCKQUOTE></BODY></HTML> --_000_D63DB3A4C85587439C3BA6A32D1D0943036A054080ESESSCMS0352e_-- From L.Liess@telekom.de Fri Feb 5 08:21:53 2010 Return-Path: <L.Liess@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D16928C18E for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 08:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9ePbSMeOCKO for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 08:21:50 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 5531D28C113 for <dispatch@ietf.org>; Fri, 5 Feb 2010 08:21:49 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 05 Feb 2010 17:21:41 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 17:21:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Feb 2010 17:21:39 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003EFE040@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <C6A11A02FF1FBF438477BB38132E474105BA6C31@EITO-MBX02.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: Acqmc9oLJApMpvsWTo+rWDRROhjahgABQO8g References: <C6A11A02FF1FBF438477BB38132E474105BA6C31@EITO-MBX02.internal.vodafone.com> From: <L.Liess@telekom.de> To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org>, <spencer@wonderhamster.org> X-OriginalArrivalTime: 05 Feb 2010 16:21:41.0343 (UTC) FILETIME=[4CD2EEF0:01CAA67F] Cc: Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 16:21:53 -0000 Hi Peter, My understanding is that session-id and debug-id cover different sets of = requirements.=20 Session-id is in every message. If people want to find out what happened = two days before, they can look at the old logs and the session-id is = there in every message to help them to correlate e2e. For the debug-id = to be there you have to know in advance that and which e2e traffic you = would like to have correlated. The debug-id is activated "on-demand" and = has no performance impact when it is not active, session-id is active = all the time. The advantage of the debug-id is that there is no = performance impact when debugging is not needed. Is my understanding = correct?=20 =20 I like the debug-id stuff, it's really smart and we looked at it. But = our troubleshooting and security guys want the session-id, for the = reason above. I assume every service provider has its own needs and = requirements. =20 Spencer is right. BOF, CLF whatever...we have to find some way to come = forward with the e2e correlation.=20 Thanks a lot Laura > -----Original Message----- > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com]=20 > Sent: Friday, February 05, 2010 4:00 PM > To: dispatch@ietf.org > Cc: Liess, Laura; gonzalo.camarillo@ericsson.com;=20 > HKaplan@acmepacket.com; H=FClsemann, Martin; Pinker, Gerold > Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hello, > Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03=20 > +0200) as > "1) We have Hadriel's draft, 2) We also have the following=20 > draft, which > eventually led to the disaggregated media work: > http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog > -correlati > on-01.txt 3) We also have the SIP-XMPP work, which may also need to > correlate sessions somehow." >=20 > I would like to add > http://tools.ietf.org/html/draft-dawes-sipping-debug-02 to this > discussion of use cases for some form of correlation identifier. This > draft relates to debugging/troubleshooting to meet documented > requirements from 3GPP and OMA, and proposes a kind of correlation > identifier in a new header. >=20 > Regards, > Peter >=20 >=20 > Message: 2 > Date: Fri, 22 Jan 2010 11:05:57 -0500 > From: Paul Kyzivat <pkyzivat@cisco.com> > Subject: Re: [dispatch] FW: > I-DAction:draft-kaplan-dispatch-session-id-00.txt > To: L.Liess@telekom.de > Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, > Gerold.Pinker@telekom.de > Message-ID: <4B59CCE5.2010202@cisco.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 >=20 >=20 > L.Liess@telekom.de wrote: > > Paul, > >=20 > > Thank you for the examples. The scenarios can be really complex. I > hope we can get these correlation identifiers, whatever their=20 > names, to > work correctly in all cases....=20 > >=20 > > I am not sure I understood your message correctly. Do you say we > should have two different identifiers because we use them for two > different things?=20 >=20 > I think there may be more than two distinct usages that will require=20 > different ones. >=20 > IMO use cases should be gathered and then bucketed into sets=20 > that can be >=20 > satisfied by a single mechanism, without assuming initially how many=20 > buckets there will be. >=20 > (But I'm still on record as not being convinced that a=20 > correlation id is >=20 > needed *at all* for the case when multiple sip UAs are=20 > participating on=20 > behalf of a single user in a call.) >=20 > > Thanks a lot > > Laura > >=20 >=20 From victor.pascual.avila@gmail.com Fri Feb 5 09:57:56 2010 Return-Path: <victor.pascual.avila@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4857628C126 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 09:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7qFLZB4NpwA for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 09:57:55 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 55F9F3A6F41 for <dispatch@ietf.org>; Fri, 5 Feb 2010 09:57:55 -0800 (PST) Received: by bwz19 with SMTP id 19so20721bwz.28 for <dispatch@ietf.org>; Fri, 05 Feb 2010 09:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LbPaVRY+89NYYlvn3z7zQnz3en6uTNySX550WgzJO6E=; b=GiBuG3RNurr0n5vtN2Ye8m+uc6jxYgY7rZoAJgtT2XarqsaxH4ntsWrsUkYDgzlKF5 zPBzo57V3a1UqQTPXxh66r0riaZVUaDa+XCuuT0nYV51Hm6VOU03MeChERp3AvZWcBGo Kcp/0Uy3RcavpE+yWYq8d4Hw46I1hd9IKt2Pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Scjkmv9z7TlhCmK5Tu5a3b5ufxYgQ5cYKkM78gdDFyegyMU+op+gh8d53DnNvvVIdG 6DJ9qUhQmphsZpKFVAtOH/FN+QOscy21s4OXu6hnXd64s4rgZR5SdikuptP9qpn21/fc 1ZCN6g5yUdVtGjhDQHZgFDFWyQi0DRWspzPtE= MIME-Version: 1.0 Received: by 10.204.32.196 with SMTP id e4mr1918518bkd.131.1265392719322; Fri, 05 Feb 2010 09:58:39 -0800 (PST) In-Reply-To: <1265376915.3931.153.camel@scott> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD@mail> <010201ca8335$9e5a3de0$db0eb9a0$@us> <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> <1265376915.3931.153.camel@scott> Date: Fri, 5 Feb 2010 18:58:39 +0100 Message-ID: <618e24241002050958x481f1747hd17f39a9d7c29ce4@mail.gmail.com> From: Victor Pascual Avila <victor.pascual.avila@gmail.com> To: Scott Lawrence <scottlawrenc@avaya.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 17:57:56 -0000 Hi Scott, On Fri, Feb 5, 2010 at 2:35 PM, Scott Lawrence <scottlawrenc@avaya.com> wro= te: > I wonder whether or not it's time that we bit the bullet and try to > actually comprehensively write down what the correct and harmful > behaviors for non-proxy middleboxes are? Please check draft-elwell-sip-e2e-identity-important, Section 8: Analysis of changes to SIP requests by B2BUAs http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03#secti= on-8 I believe folks may have a divergence of opinion on what is considered correct and what is considered harmful Cheers, --=20 Victor Pascual =C3=81vila From dworley@avaya.com Fri Feb 5 11:56:19 2010 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E1428C1F6 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 11:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H99t6-kJF4e9 for <dispatch@core3.amsl.com>; Fri, 5 Feb 2010 11:56:18 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id ADA9A28C1DC for <dispatch@ietf.org>; Fri, 5 Feb 2010 11:56:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,415,1262581200"; d="scan'208";a="203959265" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Feb 2010 14:57:09 -0500 X-IronPort-AV: E=Sophos;i="4.49,414,1262581200"; d="scan'208";a="442994819" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2010 14:57:09 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o15Juml22009 for <dispatch@ietf.org>; Fri, 5 Feb 2010 19:56:48 GMT Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o15Juk723574 for <dispatch@ietf.org>; Fri, 5 Feb 2010 19:56:46 GMT Received: from [47.141.31.232] ([47.141.31.232]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 14:56:45 -0500 From: "Dale Worley" <dworley@avaya.com> To: DISPATCH <dispatch@ietf.org> In-Reply-To: <A444A0F8084434499206E78C106220CAB9210A7C@MCHP058A.global-ad.net> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD@mail> <010201ca8335$9e5a3de0$db0eb9a0$@us> <B5BEC8815E734938B1E4DAC973E0CBBB@china.huawei.com> <1265376915.3931.153.camel@scott> <A444A0F8084434499206E78C106220CAB9210A7C@MCHP058A.global-ad.net> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 05 Feb 2010 14:56:45 -0500 Message-Id: <1265399805.5694.40.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2010 19:56:45.0795 (UTC) FILETIME=[587A0B30:01CAA69D] Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 05 Feb 2010 19:56:19 -0000 On Fri, 2010-02-05 at 14:56 +0100, Elwell, John wrote: > If somebody is able to put together a draft, that would be good. > However, bear in mind that some non-proxy middle-boxes carry out 3PCC, > and this can lead to situations where the two ends of a call can > comprise components of two former calls, and therefore will not have > the same call-ID even if the two former calls had the same call-ID > end-to-end. This is an important point about any proposed correlation mechanism: In various situations, as Paul describes, an element discovers that two dialogs are correlated *after* they have been in existence some time, which is after any putative correlation identifier has been assigned to each call. The advantage of Session-Id is that it addresses what is really a very narrow application scenario, a call proceeding through an SBC, but one that is very common. Because of its simplicity, it has a higher chance of being adopted. It is not a complete solution, but it provides a lot of value anyway. On the other hand, if one wants a correlation mechanism that is effective for a wide range of scenarios, one usually runs up against the correlation-post-facto problem. That more general case can't be solved by assigning each dialog a unique correlation identifier. You have to have some method of declaring the correlation of two pre-existing dialogs that share no identifiers. (That's the approach taken in http://tools.ietf.org/html/draft-worley-references.) Dale From pkyzivat@cisco.com Sun Feb 7 15:04:46 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38A63A68C7 for <dispatch@core3.amsl.com>; Sun, 7 Feb 2010 15:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdKuYiMJwNT2 for <dispatch@core3.amsl.com>; Sun, 7 Feb 2010 15:04:43 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 64BAE3A6827 for <dispatch@ietf.org>; Sun, 7 Feb 2010 15:04:43 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACfWbktAZnwN/2dsb2JhbAC/QJZJgkOCEQQ X-IronPort-AV: E=Sophos;i="4.49,423,1262563200"; d="scan'208";a="84432368" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2010 23:05:42 +0000 Received: from [10.86.250.221] (bxb-vpn3-733.cisco.com [10.86.250.221]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o17N5gBr008093; Sun, 7 Feb 2010 23:05:42 GMT Message-ID: <4B6F4742.4010500@cisco.com> Date: Sun, 07 Feb 2010 18:05:38 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 <ranjit@motorola.com> References: <4B4F2403.7010200@ericsson.com><A444A0F8084434499206E78C106220CA6A158B09@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><A444A0F8084434499206E78C106220CA6A1C3DC7@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com> <A444A0F8084434499206E78C106220CA6A1C488E@MCHP058A.global-ad.net> <4B55F6B7.60002@cisco.com> <C1C95024-5687-4C69-9468-895BD2C9AA71@softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com> <A444A0F8084434499206E78C106220CA6A233EFB@MCHP058A.global-ad.net> <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com> <4B5DA8E3.7050306@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 07 Feb 2010 23:04:46 -0000 inline... Avasarala Ranjit-A20990 wrote: >> Assuming sip:alice@office.domain.com is not an AOR, but rather is a >> registered contact to sip:alice@domain.com, where in the routing of >> the call does the server that evaluates this rule get control? >> >> <Ranjit> The server looks for the incoming caller identity and the >> destination identity to see if there is a matching rule configured. > > I guess my question wasn't clear. > Where in the routing sequence does this server reside? > > <Ranjit-Jan27> The server could be the Application Server where the > diversion rules reside and get executed. > > If it is positioned before the contact routing has occurred, then it > can't know which contact was chosen. > <Ranjit-Jan27th> No it would be before that. > Since this proposal is coming, more or less, from IMS I assume you are > imagining this is an IMS Application Server. IIRC, those get control > *before* contact routing is done by the S-CSCF. So how would the AS know > if a particular contact was chosen. (I take some issue with calling > contact routing "diversion", but lets not discuss that right now.) > > <Ranjit-Jan27th> Yes you are right. This proposal is more from a IMS and > 3GPP perspective and I am trying to generalize it for IETF. OK. So once again I have to ask for a description of the system architecture(s) in which this event package makes sense - where the notifier would have the knowledge to make the proposed kind of notifications. >> If the registered >> contact is not an AoR, then the call cannot be routed to it >> and > > Huh? Whether the registered contact is an AOR has no bearing on whether > its possible to route to it. And, its in general impossible to determine > by looking whether a URI is an AOR or not. > > <Ranjit-Jan27th> Agree with you on this. > >> hence will be routed to the main AoR i.e sip:alice@domain.com and the >> rule would not be executed. > > That statement makes me even more confused. I have no idea what it > means. > > <Ranjit-Jan27th> Here I mean, the notifications would be sent to the > main AoR with the details of "diverting-user", "diverted-to-user" being > part > Of the XML package. The notifications need not be sent to the registered > contact. For e.g if sip:alice@domain.com is the AoR and diversions are > taking > Place for sip:alice@office.domain.com, then notifications will be sent > to sip:alice@domain.com only and not to sip:alice@domain.com. This will > simplify things I feel !! I'm am getting more confused, not less. I think the draft needs some significant rewriting in terms of concepts and terminology, as well as assumed architecture, in order to be comprehensible in any context other that pure IMS. And frankly I don't understand it even if I restrict the context to IMS. >> But if sip:alice@office.domain.com is an AoR (e.g. GRUU), then the >> call could be routed and if there is adiversion rule there, >> the diversion rule would get executed and a notification >> generated towards that AoR. > > This is getting more and more confusing. So I have even more desire for > at least a detailed use case that shows all the players, their addresses > and relationships to one another, and the call flow. > > <Ranjit-Jan27th> as I mentioned above, to simplify things, lets assume > that notifications always go to the main AoR i.e the Public User > Identity (in IMS) > And not to any of the registered AoR irrespective of who the diverting > user is. So here even tough the divering user is sip:alice@office or > sip:alice@home, the notifications always go to sip:alice@domain.com. How does that simplify anything? If anything that makes it worse. Notifications go to the subscriber, and the content of that notification should in general have nothing to do with who the subscriber is. (But may be influenced by authorization policy.) Notifications are always in-dialog, to the remote target of that dialog, and hence pretty much never go to an AOR. >> How would it work in cases where the address for Alice's office phone >> is a dynamically assigned ip address rather than a dns name? >> >> <Ranjit> Since the notification gets generated dynamically when ever >> the diversion occurs, the new ip address is taken prior to sending the > >> notification. > > Again it seems my question wasn't clear. > You are showing rules that contain the contact addresses of particular > devices. If the contact URIs registered by those devices contain > dynamically assigned addresses, how would a subscriber know how to > construct the rule that selects a particular device? Or if it is > receiving all the diversions, how would it relate the reported results > to particular devices? > > <Ranjit-Jan27th> if the notifications are sent to PUI, then the contact > addresses are specified as URLs. So there is no need to send any > notifications to individual contact adsresses You are missing my point entirely. I'm not asking about where the notifications are *sent* (which is irrelevant). I'm asking about the *content* of those notifications, and of the filters that select which ones the subscriber is interested in. Assume for the moment that we have AOR sip:alice@SSP.com. And registered with that AOR are contact addresses sip:alice@mobile123.SSP.com and sip:alice@office.domain.com. Some UA (I'll not say which) is concerned about diversions related to that AOR. It subscribes to the comm-div package that sip:alice@SSP.com. It may include some sort of filter in the subscription. If a request comes in to the AOR, and neither of the contacts responds, a server serving that AOR (perhaps an AS) may eventually decide to forward the request to a VM server. I can see how this would be considered a real diversion, and how the server would know about it. So it can generate a NOTIFY reporting this diversion. Next, its possible that Alice, from her mobile phone, establishes a forwarding rule, that sends all incoming calls to the AOR to sip:bob@SSP.com. The server would apply this rule, as policy, to all incoming requests to the AOR, bypassing contact routing. Again its unremarkable that it would be able to generate a notification when carrying out such a retargeting. None of that requires any filter on the address at which diversion takes place, because it takes place exactly on diversion of requests to the same URI to which the subscription was made. Your filter package implies that the notifier can generate notifications for cases where the diversion takes place from some URI *other* than the one for which the subscriptions is made. I am guessing you mean cases when the diversion takes place after the call has been retargeted to one of the contacts. I have two problems with that: 1) how would the server for sip:alice@SSP.com know that a diversion has occurred on a request targetted to sip:alice@office.domain.com? 2) even if it had a way to discover that, how would a subscriber know the URI sip:alice@office.domain.com in order to place it in a filter? But I find I am repeating myself (see below from before.) There must be some fundamental difference in perspective that is preventing us from understanding one another. > This relates, in a way, to whether contact routing is diversion or not. > Typically what I think of as real diversion would be to a URI that *is* > an AOR, and hence stable and knowable by those formulating rules. But > typical contact routing would involve URIs that aren't very meaningful. > > If you want to be able to write rules like: "let me know when the call > is routed to the phone in my office rather than the one in my home" > (where both have the same "phone number"), then you are going to have to > find a way to give those stable URIs, like sip:alice@office.domain.com > and sip:alice@home.domain.com. AFAIK that isn't the norm, so if you are > assuming it then please make that clear. Thanks, Paul From ranjit@motorola.com Mon Feb 8 02:08:45 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CEE73A7311 for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 02:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFvkpelX+rpq for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 02:08:44 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 1FDB83A7332 for <dispatch@ietf.org>; Mon, 8 Feb 2010 02:08:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1265623784!11437425!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 23939 invoked from network); 8 Feb 2010 10:09:45 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-2.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Feb 2010 10:09:45 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id o18A9iXs026881 for <dispatch@ietf.org>; Mon, 8 Feb 2010 03:09:44 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o18A9iWd023187 for <dispatch@ietf.org>; Mon, 8 Feb 2010 04:09:44 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o18A9gBC023168 for <dispatch@ietf.org>; Mon, 8 Feb 2010 04:09:43 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Feb 2010 18:09:20 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A2CD16D@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B6F4742.4010500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification thread-index: AcqoShtUlbnG9CF5TLaWDwDBQadGCgAUqonA References: <4B4F2403.7010200@ericsson.com><A444A0F8084434499206E78C106220CA6A158B09@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><A444A0F8084434499206E78C106220CA6A1C3DC7@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com> <A444A0F8084434499206E78C106220CA6A1C488E@MCHP058A.global-ad.net> <4B55F6B7.60002@cisco.com> <C1C95024-5687-4C69-9468-895BD2C9AA71@softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com> <A444A0F8084434499206E78C106220CA6A233EFB@MCHP058A.global-ad.net> <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com> <4B5DA8E3.7050306@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com> <4B6F4 742.4010 500@cisco.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-CFilter-Loop: Reflected Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 08 Feb 2010 10:08:45 -0000 Hi Paul My comments <Ranjit-Feb08>=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, February 08, 2010 4:36 AM To: Avasarala Ranjit-A20990 Cc: Elwell, John; DISPATCH Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification inline... Avasarala Ranjit-A20990 wrote: >> Assuming sip:alice@office.domain.com is not an AOR, but rather is a=20 >> registered contact to sip:alice@domain.com, where in the routing of=20 >> the call does the server that evaluates this rule get control? >> >> <Ranjit> The server looks for the incoming caller identity and the=20 >> destination identity to see if there is a matching rule configured. >=20 > I guess my question wasn't clear. > Where in the routing sequence does this server reside? >=20 > <Ranjit-Jan27> The server could be the Application Server where the=20 > diversion rules reside and get executed. >=20 > If it is positioned before the contact routing has occurred, then it=20 > can't know which contact was chosen. > <Ranjit-Jan27th> No it would be before that.=20 > Since this proposal is coming, more or less, from IMS I assume you are > imagining this is an IMS Application Server. IIRC, those get control > *before* contact routing is done by the S-CSCF. So how would the AS=20 > know if a particular contact was chosen. (I take some issue with=20 > calling contact routing "diversion", but lets not discuss that right=20 > now.) >=20 > <Ranjit-Jan27th> Yes you are right. This proposal is more from a IMS=20 > and 3GPP perspective and I am trying to generalize it for IETF. OK. So once again I have to ask for a description of the system architecture(s) in which this event package makes sense - where the notifier would have the knowledge to make the proposed kind of notifications. <Ranjit-Feb08> The proposed I-D is actually for registering the proposed event package for the communication diversion service described in 3GPP TS 24.604. So here the notifier would the AS where the communication diversion service is running. So yes it would have knowledge of on whose behalf it is Doing the diversion and to whom it should notify. >> If the registered=20 >> contact is not an AoR, then the call cannot be routed to it=20 >> and >=20 > Huh? Whether the registered contact is an AOR has no bearing on=20 > whether its possible to route to it. And, its in general impossible to > determine by looking whether a URI is an AOR or not. >=20 > <Ranjit-Jan27th> Agree with you on this. >=20 >> hence will be routed to the main AoR i.e sip:alice@domain.com and the >> rule would not be executed. >=20 > That statement makes me even more confused. I have no idea what it=20 > means. >=20 > <Ranjit-Jan27th> Here I mean, the notifications would be sent to the=20 > main AoR with the details of "diverting-user", "diverted-to-user"=20 > being part Of the XML package. The notifications need not be sent to=20 > the registered contact. For e.g if sip:alice@domain.com is the AoR and > diversions are taking Place for sip:alice@office.domain.com, then=20 > notifications will be sent to sip:alice@domain.com only and not to=20 > sip:alice@domain.com. This will simplify things I feel !! I'm am getting more confused, not less. I think the draft needs some significant rewriting in terms of concepts and terminology, as well as assumed architecture, in order to be comprehensible in any context other that pure IMS. And frankly I don't understand it even if I restrict the context to IMS. <Ranjit-Feb08> Actually the terminology and the service in general is explained in 24.604 (Section 4.10). So we felt that this I-D would just=20 Register the proposed event package. >> But if sip:alice@office.domain.com is an AoR (e.g. GRUU), then the=20 >> call could be routed and if there is adiversion rule there, >> the diversion rule would get executed and a notification=20 >> generated towards that AoR. >=20 > This is getting more and more confusing. So I have even more desire=20 > for at least a detailed use case that shows all the players, their=20 > addresses and relationships to one another, and the call flow. >=20 > <Ranjit-Jan27th> as I mentioned above, to simplify things, lets assume > that notifications always go to the main AoR i.e the Public User Bu > Identity (in IMS) > And not to any of the registered AoR irrespective of who the diverting > user is. So here even tough the divering user is sip:alice@office or=20 > sip:alice@home, the notifications always go to sip:alice@domain.com. How does that simplify anything? If anything that makes it worse.=20 Notifications go to the subscriber, and the content of that notification should in general have nothing to do with who the subscriber is. (But may be influenced by authorization policy.) Notifications are always in-dialog, to the remote target of that dialog, and hence pretty much never go to an AOR. <Ranjit-Feb08> True. Notification go to the subscribed entity as shown in the example in 24.604.=20 >> How would it work in cases where the address for Alice's office phone >> is a dynamically assigned ip address rather than a dns name? >> >> <Ranjit> Since the notification gets generated dynamically when ever=20 >> the diversion occurs, the new ip address is taken prior to sending=20 >> the >=20 >> notification. >=20 > Again it seems my question wasn't clear. > You are showing rules that contain the contact addresses of particular > devices. If the contact URIs registered by those devices contain=20 > dynamically assigned addresses, how would a subscriber know how to=20 > construct the rule that selects a particular device? Or if it is=20 > receiving all the diversions, how would it relate the reported results > to particular devices? >=20 > <Ranjit-Jan27th> if the notifications are sent to PUI, then the=20 > contact addresses are specified as URLs. So there is no need to send=20 > any notifications to individual contact adsresses You are missing my point entirely. I'm not asking about where the notifications are *sent* (which is irrelevant). I'm asking about the *content* of those notifications, and of the filters that select which ones the subscriber is interested in. <Ranjit-Feb08> The content of notifications are the elements specified in the event pacakge. The example shows both a sample notification and the elements that can be used as filters to control the content of notifications. E.g. Section 4.10.1.1.1.2 of 24.604 Assume for the moment that we have AOR sip:alice@SSP.com. And registered with that AOR are contact addresses sip:alice@mobile123.SSP.com and sip:alice@office.domain.com. Some UA (I'll not say which) is concerned about diversions related to that AOR. It subscribes to the comm-div package that sip:alice@SSP.com.=20 It may include some sort of filter in the subscription. If a request comes in to the AOR, and neither of the contacts responds, a server serving that AOR (perhaps an AS) may eventually decide to forward the request to a VM server. I can see how this would be considered a real diversion, and how the server would know about it. So it can generate a NOTIFY reporting this diversion. <Ranjit-Feb08> True. So here the notification would be towards sip:alice@SSP.com with entity=3D"sip:alice@mobile123.SSP.com OR entity=3Dsip:alice@office.SSP.com on whose behlaf the diversion took = place or where the call landed.=20 Next, its possible that Alice, from her mobile phone, establishes a forwarding rule, that sends all incoming calls to the AOR to sip:bob@SSP.com. The server would apply this rule, as policy, to all incoming requests to the AOR, bypassing contact routing. Again its unremarkable that it would be able to generate a notification when carrying out such a retargeting. <Ranjit-Feb08> so here if Alice gets notified whenever a incoming call to her gets forwarded to Bob. If she sets a filter criteria like timeofday, then only incoming calls during that time get notified and not others. So the notifications depend on the target of the incoming call and other specified criteria.=20 None of that requires any filter on the address at which diversion takes place, because it takes place exactly on diversion of requests to the same URI to which the subscription was made. <Ranjit-Feb08> why not? Filters can be set based on time, range of time or particular day or context (alice is OOO, etc) Your filter package implies that the notifier can generate notifications for cases where the diversion takes place from some URI *other* than the one for which the subscriptions is made. I am guessing you mean cases when the diversion takes place after the call has been retargeted to one of the contacts. I have two problems with that: <Ranjit-Feb08> No No. Notifier generates notifications only for diversions that take place on behalf of the subscribed entity and not others. So here sip:alice@SSP.com subscribes to diversions taking place at any of its contacts and get notified based on filter criteria. The filter critera can specify which contacts the notification is required for and which of those notifications are not required.=20 1) how would the server for sip:alice@SSP.com know that a diversion has occurred on a request targetted to sip:alice@office.domain.com? 2) even if it had a way to discover that, how would a subscriber know the URI sip:alice@office.domain.com in order to place it in a filter? But I find I am repeating myself (see below from before.) There must be some fundamental difference in perspective that is preventing us from understanding one another. > This relates, in a way, to whether contact routing is diversion or not.=20 > Typically what I think of as real diversion would be to a URI that=20 > *is* an AOR, and hence stable and knowable by those formulating rules. > But typical contact routing would involve URIs that aren't very meaningful. >=20 > If you want to be able to write rules like: "let me know when the call > is routed to the phone in my office rather than the one in my home" > (where both have the same "phone number"), then you are going to have=20 > to find a way to give those stable URIs, like=20 > sip:alice@office.domain.com and sip:alice@home.domain.com. AFAIK that=20 > isn't the norm, so if you are assuming it then please make that clear. Thanks, Paul Regards Ranjit From drage@alcatel-lucent.com Mon Feb 8 05:42:58 2010 Return-Path: <drage@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE223A7372 for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 05:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxTpJhfLpWbP for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 05:42:57 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 70B0D3A73AD for <dispatch@ietf.org>; Mon, 8 Feb 2010 05:42:56 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o18DhC1e016793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 8 Feb 2010 14:43:14 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 8 Feb 2010 14:43:12 +0100 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Avasarala Ranjit-A20990 <ranjit@motorola.com>, Paul Kyzivat <pkyzivat@cisco.com> Date: Mon, 8 Feb 2010 14:43:09 +0100 Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification Thread-Index: AcqoShtUlbnG9CF5TLaWDwDBQadGCgAUqonAAAnjfUA= Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20AF618AE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <4B4F2403.7010200@ericsson.com><A444A0F8084434499206E78C106220CA6A158B09@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><A444A0F8084434499206E78C106220CA6A1C3DC7@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com> <A444A0F8084434499206E78C106220CA6A1C488E@MCHP058A.global-ad.net> <4B55F6B7.60002@cisco.com> <C1C95024-5687-4C69-9468-895BD2C9AA71@softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com> <A444A0F8084434499206E78C106220CA6A233EFB@MCHP058A.global-ad.net> <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com> <4B5DA8E3.7050306@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com> <4B6F4 742.4010 500@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD16D@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A2CD16D@ZMY16EXM66.ds.mot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 08 Feb 2010 13:42:58 -0000 Can I understand where this discussion is going? The relevant paragraph of http://tools.ietf.org/id/draft-peterson-rai-rfc34= 27bis-04.txt is: Individuals may wish to publish SIP Event packages that they believe fall outside the scope of any chartered work currently in RAI. Individual proposals for registration of a SIP event package MUST first be published as Internet-drafts for review by the DISPATCH Working Group, or the working group, mailing list, or expert designated by the RAI Area Directors if the DISPATCH Working Group has closed. Proposals should include a strong motivational section, a thorough description of the proposed syntax and semantics, event package considerations, security considerations, and examples of usage. Authors should submit their proposals as individual Internet- Drafts, and post an announcement to the working group mailing list to begin discussion. The DISPATCH Working Group will determine if a proposed package is a) an appropriate usage of SIP which should be spun into a new effort, b) applicable to SIP but not sufficiently interesting, general, or in-scope to adopt as a working group effort, c) contrary to similar work chartered in an existing effort, or d) recommended to be adopted as or merged with chartered work elsewhere in RAI.=20 Are we still trying to prove somehow that this is generally applicable, for= which I strongly suspect the answer is NO and it never will be no matter h= ow much manipulation it requires. Are are we trying to identify that there is some error in the documentation= that needs correction? regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > Ranjit-A20990 > Sent: Monday, February 08, 2010 10:09 AM > To: Paul Kyzivat > Cc: DISPATCH > Subject: Re: [dispatch] Comments=20 > requestedondraft-avasarala-dispatch-comm-div-notification >=20 > Hi Paul >=20 > My comments <Ranjit-Feb08>=20 >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, February 08, 2010 4:36 AM > To: Avasarala Ranjit-A20990 > Cc: Elwell, John; DISPATCH > Subject: Re: [dispatch] Comments > requestedondraft-avasarala-dispatch-comm-div-notification >=20 > inline... >=20 > Avasarala Ranjit-A20990 wrote: >=20 > >> Assuming sip:alice@office.domain.com is not an AOR, but=20 > rather is a=20 > >> registered contact to sip:alice@domain.com, where in the=20 > routing of=20 > >> the call does the server that evaluates this rule get control? > >> > >> <Ranjit> The server looks for the incoming caller identity and the=20 > >> destination identity to see if there is a matching rule configured. > >=20 > > I guess my question wasn't clear. > > Where in the routing sequence does this server reside? > >=20 > > <Ranjit-Jan27> The server could be the Application Server where the=20 > > diversion rules reside and get executed. > >=20 > > If it is positioned before the contact routing has=20 > occurred, then it=20 > > can't know which contact was chosen. > > <Ranjit-Jan27th> No it would be before that.=20 >=20 > > Since this proposal is coming, more or less, from IMS I=20 > assume you are >=20 > > imagining this is an IMS Application Server. IIRC, those get control > > *before* contact routing is done by the S-CSCF. So how would the AS=20 > > know if a particular contact was chosen. (I take some issue with=20 > > calling contact routing "diversion", but lets not discuss that right > > now.) > >=20 > > <Ranjit-Jan27th> Yes you are right. This proposal is more=20 > from a IMS=20 > > and 3GPP perspective and I am trying to generalize it for IETF. >=20 > OK. So once again I have to ask for a description of the system > architecture(s) in which this event package makes sense -=20 > where the notifier would have the knowledge to make the=20 > proposed kind of notifications. >=20 > <Ranjit-Feb08> The proposed I-D is actually for registering=20 > the proposed event package for the communication diversion=20 > service described in 3GPP TS 24.604. So here the notifier=20 > would the AS where the communication diversion service is=20 > running. So yes it would have knowledge of on whose behalf it=20 > is Doing the diversion and to whom it should notify. >=20 > >> If the registered=20 > >> contact is not an AoR, then the call cannot be=20 > routed to it=20 > >> and > >=20 > > Huh? Whether the registered contact is an AOR has no bearing on=20 > > whether its possible to route to it. And, its in general=20 > impossible to >=20 > > determine by looking whether a URI is an AOR or not. > >=20 > > <Ranjit-Jan27th> Agree with you on this. > >=20 > >> hence will be routed to the main AoR i.e=20 > sip:alice@domain.com and the >=20 > >> rule would not be executed. > >=20 > > That statement makes me even more confused. I have no idea what it=20 > > means. > >=20 > > <Ranjit-Jan27th> Here I mean, the notifications would be=20 > sent to the=20 > > main AoR with the details of "diverting-user", "diverted-to-user" > > being part Of the XML package. The notifications need not=20 > be sent to=20 > > the registered contact. For e.g if sip:alice@domain.com is=20 > the AoR and >=20 > > diversions are taking Place for sip:alice@office.domain.com, then=20 > > notifications will be sent to sip:alice@domain.com only and not to=20 > > sip:alice@domain.com. This will simplify things I feel !! >=20 > I'm am getting more confused, not less. >=20 > I think the draft needs some significant rewriting in terms=20 > of concepts and terminology, as well as assumed architecture,=20 > in order to be comprehensible in any context other that pure=20 > IMS. And frankly I don't understand it even if I restrict the=20 > context to IMS. >=20 > <Ranjit-Feb08> Actually the terminology and the service in=20 > general is explained in 24.604 (Section 4.10). So we felt=20 > that this I-D would just Register the proposed event package. >=20 > >> But if sip:alice@office.domain.com is an AoR (e.g. GRUU), then the=20 > >> call could be routed and if there is adiversion rule there, > >> the diversion rule would get executed and a notification=20 > >> generated towards that AoR. > >=20 > > This is getting more and more confusing. So I have even more desire=20 > > for at least a detailed use case that shows all the players, their=20 > > addresses and relationships to one another, and the call flow. > >=20 > > <Ranjit-Jan27th> as I mentioned above, to simplify things,=20 > lets assume >=20 > > that notifications always go to the main AoR i.e the Public User Bu=20 > > Identity (in IMS) >=20 > > And not to any of the registered AoR irrespective of who=20 > the diverting >=20 > > user is. So here even tough the divering user is=20 > sip:alice@office or=20 > > sip:alice@home, the notifications always go to sip:alice@domain.com. >=20 > How does that simplify anything? If anything that makes it worse.=20 > Notifications go to the subscriber, and the content of that=20 > notification should in general have nothing to do with who=20 > the subscriber is. (But may be influenced by authorization=20 > policy.) Notifications are always in-dialog, to the remote=20 > target of that dialog, and hence pretty much never go to an AOR. >=20 > <Ranjit-Feb08> True. Notification go to the subscribed entity=20 > as shown in the example in 24.604.=20 >=20 > >> How would it work in cases where the address for Alice's=20 > office phone >=20 > >> is a dynamically assigned ip address rather than a dns name? > >> > >> <Ranjit> Since the notification gets generated dynamically=20 > when ever=20 > >> the diversion occurs, the new ip address is taken prior to sending=20 > >> the > >=20 > >> notification. > >=20 > > Again it seems my question wasn't clear. > > You are showing rules that contain the contact addresses of=20 > particular >=20 > > devices. If the contact URIs registered by those devices contain=20 > > dynamically assigned addresses, how would a subscriber know how to=20 > > construct the rule that selects a particular device? Or if it is=20 > > receiving all the diversions, how would it relate the=20 > reported results >=20 > > to particular devices? > >=20 > > <Ranjit-Jan27th> if the notifications are sent to PUI, then the=20 > > contact addresses are specified as URLs. So there is no=20 > need to send=20 > > any notifications to individual contact adsresses >=20 > You are missing my point entirely. I'm not asking about where=20 > the notifications are *sent* (which is irrelevant). I'm=20 > asking about the > *content* of those notifications, and of the filters that=20 > select which ones the subscriber is interested in. >=20 > <Ranjit-Feb08> The content of notifications are the elements=20 > specified in the event pacakge. The example shows both a=20 > sample notification and the elements that can be used as=20 > filters to control the content of notifications. E.g. Section=20 > 4.10.1.1.1.2 of 24.604 >=20 > Assume for the moment that we have AOR sip:alice@SSP.com. > And registered with that AOR are contact addresses=20 > sip:alice@mobile123.SSP.com and sip:alice@office.domain.com. >=20 > Some UA (I'll not say which) is concerned about diversions=20 > related to that AOR. It subscribes to the comm-div package=20 > that sip:alice@SSP.com.=20 > It may include some sort of filter in the subscription. >=20 > If a request comes in to the AOR, and neither of the contacts=20 > responds, a server serving that AOR (perhaps an AS) may=20 > eventually decide to forward the request to a VM server. I=20 > can see how this would be considered a real diversion, and=20 > how the server would know about it. So it can generate a=20 > NOTIFY reporting this diversion. >=20 > <Ranjit-Feb08> True. So here the notification would be=20 > towards sip:alice@SSP.com with=20 > entity=3D"sip:alice@mobile123.SSP.com OR=20 > entity=3Dsip:alice@office.SSP.com on whose behlaf the diversion=20 > took place or where the call landed.=20 >=20 > Next, its possible that Alice, from her mobile phone,=20 > establishes a forwarding rule, that sends all incoming calls=20 > to the AOR to sip:bob@SSP.com. The server would apply this=20 > rule, as policy, to all incoming requests to the AOR,=20 > bypassing contact routing. Again its unremarkable that it=20 > would be able to generate a notification when carrying out=20 > such a retargeting. >=20 > <Ranjit-Feb08> so here if Alice gets notified whenever a=20 > incoming call to her gets forwarded to Bob. If she sets a=20 > filter criteria like timeofday, then only incoming calls=20 > during that time get notified and not others. So the=20 > notifications depend on the target of the incoming call and=20 > other specified criteria.=20 >=20 > None of that requires any filter on the address at which=20 > diversion takes place, because it takes place exactly on=20 > diversion of requests to the same URI to which the=20 > subscription was made. >=20 > <Ranjit-Feb08> why not? Filters can be set based on time,=20 > range of time or particular day or context (alice is OOO, etc) >=20 > Your filter package implies that the notifier can generate=20 > notifications for cases where the diversion takes place from=20 > some URI *other* than the one for which the subscriptions is=20 > made. I am guessing you mean cases when the diversion takes=20 > place after the call has been retargeted to one of the=20 > contacts. I have two problems with that: >=20 > <Ranjit-Feb08> No No. Notifier generates notifications only=20 > for diversions that take place on behalf of the subscribed=20 > entity and not others. So here sip:alice@SSP.com subscribes=20 > to diversions taking place at any of its contacts and get=20 > notified based on filter criteria. The filter critera can=20 > specify which contacts the notification is required for and=20 > which of those notifications are not required.=20 >=20 > 1) how would the server for sip:alice@SSP.com know that a=20 > diversion has occurred on a request targetted to=20 > sip:alice@office.domain.com? >=20 > 2) even if it had a way to discover that, how would a=20 > subscriber know the URI sip:alice@office.domain.com in order=20 > to place it in a filter? >=20 > But I find I am repeating myself (see below from before.)=20 > There must be some fundamental difference in perspective that=20 > is preventing us from understanding one another. >=20 > > This relates, in a way, to whether contact routing is diversion or > not.=20 > > Typically what I think of as real diversion would be to a URI that > > *is* an AOR, and hence stable and knowable by those=20 > formulating rules. >=20 > > But typical contact routing would involve URIs that aren't very > meaningful. > >=20 > > If you want to be able to write rules like: "let me know=20 > when the call >=20 > > is routed to the phone in my office rather than the one in my home" > > (where both have the same "phone number"), then you are=20 > going to have=20 > > to find a way to give those stable URIs, like=20 > > sip:alice@office.domain.com and sip:alice@home.domain.com.=20 > AFAIK that=20 > > isn't the norm, so if you are assuming it then please make=20 > that clear. >=20 > Thanks, > Paul >=20 > Regards > Ranjit > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From pkyzivat@cisco.com Mon Feb 8 06:09:24 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349323A73C1 for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 06:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWMJA3wk1A8Z for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 06:09:22 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3387E3A7193 for <dispatch@ietf.org>; Mon, 8 Feb 2010 06:09:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEeqb0tAZnwN/2dsb2JhbADAT5Z5gkIBghEEgyuLHg X-IronPort-AV: E=Sophos;i="4.49,429,1262563200"; d="scan'208";a="84667502" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2010 14:10:23 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o18EAN0f024559; Mon, 8 Feb 2010 14:10:23 GMT Message-ID: <4B701B50.1070804@cisco.com> Date: Mon, 08 Feb 2010 09:10:24 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><A444A0F8084434499206E78C106220CA6A1C3DC7@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com> <A444A0F8084434499206E78C106220CA6A1C488E@MCHP058A.global-ad.net> <4B55F6B7.60002@cisco.com> <C1C95024-5687-4C69-9468-895BD2C9AA71@softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com> <A444A0F8084434499206E78C106220CA6A233EFB@MCHP058A.global-ad.net> <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com> <4B5DA8E3.7050306@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com> <4B6F4 742.4010 500@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD16D@ZMY16EXM66.ds.mot.com> <EDC0A1AE77C57744B664A310A0B23AE20AF618AE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20AF618AE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 08 Feb 2010 14:09:24 -0000 DRAGE, Keith (Keith) wrote: > Can I understand where this discussion is going? > > The relevant paragraph of http://tools.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt is: > > Individuals may wish to publish SIP Event packages that they believe > fall outside the scope of any chartered work currently in RAI. > Individual proposals for registration of a SIP event package MUST > first be published as Internet-drafts for review by the DISPATCH > Working Group, or the working group, mailing list, or expert > designated by the RAI Area Directors if the DISPATCH Working Group > has closed. Proposals should include a strong motivational section, > a thorough description of the proposed syntax and semantics, event > package considerations, security considerations, and examples of > usage. Authors should submit their proposals as individual Internet- > Drafts, and post an announcement to the working group mailing list to > begin discussion. The DISPATCH Working Group will determine if a > proposed package is a) an appropriate usage of SIP which should be > spun into a new effort, b) applicable to SIP but not sufficiently > interesting, general, or in-scope to adopt as a working group effort, > c) contrary to similar work chartered in an existing effort, or d) > recommended to be adopted as or merged with chartered work elsewhere > in RAI. > > Are we still trying to prove somehow that this is generally applicable, for which I strongly suspect the answer is NO and it never will be no matter how much manipulation it requires. I started out with the working assumption that this could be of general interest. I still think something addressing the same general area might be. But I am reaching the conclusion that the authors have no particular interest in generalizing it. So I think it is probably better viewed as something specific for the IMS community. If I understand the procedures, it would be ok to publish this as such, but think the text should be very clear about the area of applicability. As currently worded I think people outside the IMS community might attempt to implement it without the guidance of additional IMS documents. IMO if they did so the likelihood of interoperable implementations would be slim to none. Thanks, Paul > Are are we trying to identify that there is some error in the documentation that needs correction? > > regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala >> Ranjit-A20990 >> Sent: Monday, February 08, 2010 10:09 AM >> To: Paul Kyzivat >> Cc: DISPATCH >> Subject: Re: [dispatch] Comments >> requestedondraft-avasarala-dispatch-comm-div-notification >> >> Hi Paul >> >> My comments <Ranjit-Feb08> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, February 08, 2010 4:36 AM >> To: Avasarala Ranjit-A20990 >> Cc: Elwell, John; DISPATCH >> Subject: Re: [dispatch] Comments >> requestedondraft-avasarala-dispatch-comm-div-notification >> >> inline... >> >> Avasarala Ranjit-A20990 wrote: >> >>>> Assuming sip:alice@office.domain.com is not an AOR, but >> rather is a >>>> registered contact to sip:alice@domain.com, where in the >> routing of >>>> the call does the server that evaluates this rule get control? >>>> >>>> <Ranjit> The server looks for the incoming caller identity and the >>>> destination identity to see if there is a matching rule configured. >>> I guess my question wasn't clear. >>> Where in the routing sequence does this server reside? >>> >>> <Ranjit-Jan27> The server could be the Application Server where the >>> diversion rules reside and get executed. >>> >>> If it is positioned before the contact routing has >> occurred, then it >>> can't know which contact was chosen. >>> <Ranjit-Jan27th> No it would be before that. >>> Since this proposal is coming, more or less, from IMS I >> assume you are >> >>> imagining this is an IMS Application Server. IIRC, those get control >>> *before* contact routing is done by the S-CSCF. So how would the AS >>> know if a particular contact was chosen. (I take some issue with >>> calling contact routing "diversion", but lets not discuss that right >>> now.) >>> >>> <Ranjit-Jan27th> Yes you are right. This proposal is more >> from a IMS >>> and 3GPP perspective and I am trying to generalize it for IETF. >> OK. So once again I have to ask for a description of the system >> architecture(s) in which this event package makes sense - >> where the notifier would have the knowledge to make the >> proposed kind of notifications. >> >> <Ranjit-Feb08> The proposed I-D is actually for registering >> the proposed event package for the communication diversion >> service described in 3GPP TS 24.604. So here the notifier >> would the AS where the communication diversion service is >> running. So yes it would have knowledge of on whose behalf it >> is Doing the diversion and to whom it should notify. >> >>>> If the registered >>>> contact is not an AoR, then the call cannot be >> routed to it >>>> and >>> Huh? Whether the registered contact is an AOR has no bearing on >>> whether its possible to route to it. And, its in general >> impossible to >> >>> determine by looking whether a URI is an AOR or not. >>> >>> <Ranjit-Jan27th> Agree with you on this. >>> >>>> hence will be routed to the main AoR i.e >> sip:alice@domain.com and the >> >>>> rule would not be executed. >>> That statement makes me even more confused. I have no idea what it >>> means. >>> >>> <Ranjit-Jan27th> Here I mean, the notifications would be >> sent to the >>> main AoR with the details of "diverting-user", "diverted-to-user" >>> being part Of the XML package. The notifications need not >> be sent to >>> the registered contact. For e.g if sip:alice@domain.com is >> the AoR and >> >>> diversions are taking Place for sip:alice@office.domain.com, then >>> notifications will be sent to sip:alice@domain.com only and not to >>> sip:alice@domain.com. This will simplify things I feel !! >> I'm am getting more confused, not less. >> >> I think the draft needs some significant rewriting in terms >> of concepts and terminology, as well as assumed architecture, >> in order to be comprehensible in any context other that pure >> IMS. And frankly I don't understand it even if I restrict the >> context to IMS. >> >> <Ranjit-Feb08> Actually the terminology and the service in >> general is explained in 24.604 (Section 4.10). So we felt >> that this I-D would just Register the proposed event package. >> >>>> But if sip:alice@office.domain.com is an AoR (e.g. GRUU), then the >>>> call could be routed and if there is adiversion rule there, >>>> the diversion rule would get executed and a notification >>>> generated towards that AoR. >>> This is getting more and more confusing. So I have even more desire >>> for at least a detailed use case that shows all the players, their >>> addresses and relationships to one another, and the call flow. >>> >>> <Ranjit-Jan27th> as I mentioned above, to simplify things, >> lets assume >> >>> that notifications always go to the main AoR i.e the Public User Bu >>> Identity (in IMS) >>> And not to any of the registered AoR irrespective of who >> the diverting >> >>> user is. So here even tough the divering user is >> sip:alice@office or >>> sip:alice@home, the notifications always go to sip:alice@domain.com. >> How does that simplify anything? If anything that makes it worse. >> Notifications go to the subscriber, and the content of that >> notification should in general have nothing to do with who >> the subscriber is. (But may be influenced by authorization >> policy.) Notifications are always in-dialog, to the remote >> target of that dialog, and hence pretty much never go to an AOR. >> >> <Ranjit-Feb08> True. Notification go to the subscribed entity >> as shown in the example in 24.604. >> >>>> How would it work in cases where the address for Alice's >> office phone >> >>>> is a dynamically assigned ip address rather than a dns name? >>>> >>>> <Ranjit> Since the notification gets generated dynamically >> when ever >>>> the diversion occurs, the new ip address is taken prior to sending >>>> the >>>> notification. >>> Again it seems my question wasn't clear. >>> You are showing rules that contain the contact addresses of >> particular >> >>> devices. If the contact URIs registered by those devices contain >>> dynamically assigned addresses, how would a subscriber know how to >>> construct the rule that selects a particular device? Or if it is >>> receiving all the diversions, how would it relate the >> reported results >> >>> to particular devices? >>> >>> <Ranjit-Jan27th> if the notifications are sent to PUI, then the >>> contact addresses are specified as URLs. So there is no >> need to send >>> any notifications to individual contact adsresses >> You are missing my point entirely. I'm not asking about where >> the notifications are *sent* (which is irrelevant). I'm >> asking about the >> *content* of those notifications, and of the filters that >> select which ones the subscriber is interested in. >> >> <Ranjit-Feb08> The content of notifications are the elements >> specified in the event pacakge. The example shows both a >> sample notification and the elements that can be used as >> filters to control the content of notifications. E.g. Section >> 4.10.1.1.1.2 of 24.604 >> >> Assume for the moment that we have AOR sip:alice@SSP.com. >> And registered with that AOR are contact addresses >> sip:alice@mobile123.SSP.com and sip:alice@office.domain.com. >> >> Some UA (I'll not say which) is concerned about diversions >> related to that AOR. It subscribes to the comm-div package >> that sip:alice@SSP.com. >> It may include some sort of filter in the subscription. >> >> If a request comes in to the AOR, and neither of the contacts >> responds, a server serving that AOR (perhaps an AS) may >> eventually decide to forward the request to a VM server. I >> can see how this would be considered a real diversion, and >> how the server would know about it. So it can generate a >> NOTIFY reporting this diversion. >> >> <Ranjit-Feb08> True. So here the notification would be >> towards sip:alice@SSP.com with >> entity="sip:alice@mobile123.SSP.com OR >> entity=sip:alice@office.SSP.com on whose behlaf the diversion >> took place or where the call landed. >> >> Next, its possible that Alice, from her mobile phone, >> establishes a forwarding rule, that sends all incoming calls >> to the AOR to sip:bob@SSP.com. The server would apply this >> rule, as policy, to all incoming requests to the AOR, >> bypassing contact routing. Again its unremarkable that it >> would be able to generate a notification when carrying out >> such a retargeting. >> >> <Ranjit-Feb08> so here if Alice gets notified whenever a >> incoming call to her gets forwarded to Bob. If she sets a >> filter criteria like timeofday, then only incoming calls >> during that time get notified and not others. So the >> notifications depend on the target of the incoming call and >> other specified criteria. >> >> None of that requires any filter on the address at which >> diversion takes place, because it takes place exactly on >> diversion of requests to the same URI to which the >> subscription was made. >> >> <Ranjit-Feb08> why not? Filters can be set based on time, >> range of time or particular day or context (alice is OOO, etc) >> >> Your filter package implies that the notifier can generate >> notifications for cases where the diversion takes place from >> some URI *other* than the one for which the subscriptions is >> made. I am guessing you mean cases when the diversion takes >> place after the call has been retargeted to one of the >> contacts. I have two problems with that: >> >> <Ranjit-Feb08> No No. Notifier generates notifications only >> for diversions that take place on behalf of the subscribed >> entity and not others. So here sip:alice@SSP.com subscribes >> to diversions taking place at any of its contacts and get >> notified based on filter criteria. The filter critera can >> specify which contacts the notification is required for and >> which of those notifications are not required. >> >> 1) how would the server for sip:alice@SSP.com know that a >> diversion has occurred on a request targetted to >> sip:alice@office.domain.com? >> >> 2) even if it had a way to discover that, how would a >> subscriber know the URI sip:alice@office.domain.com in order >> to place it in a filter? >> >> But I find I am repeating myself (see below from before.) >> There must be some fundamental difference in perspective that >> is preventing us from understanding one another. >> >>> This relates, in a way, to whether contact routing is diversion or >> not. >>> Typically what I think of as real diversion would be to a URI that >>> *is* an AOR, and hence stable and knowable by those >> formulating rules. >> >>> But typical contact routing would involve URIs that aren't very >> meaningful. >>> If you want to be able to write rules like: "let me know >> when the call >> >>> is routed to the phone in my office rather than the one in my home" >>> (where both have the same "phone number"), then you are >> going to have >>> to find a way to give those stable URIs, like >>> sip:alice@office.domain.com and sip:alice@home.domain.com. >> AFAIK that >>> isn't the norm, so if you are assuming it then please make >> that clear. >> >> Thanks, >> Paul >> >> Regards >> Ranjit >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From Peter.Dawes@vodafone.com Mon Feb 8 07:57:23 2010 Return-Path: <Peter.Dawes@vodafone.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A8328C124 for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 07:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYnRrDXhtHqM for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 07:57:21 -0800 (PST) Received: from mailout05.vodafone.com (mailout05.vodafone.com [195.232.224.74]) by core3.amsl.com (Postfix) with ESMTP id 2F6ED3A7404 for <dispatch@ietf.org>; Mon, 8 Feb 2010 07:57:21 -0800 (PST) Received: from mailint05 (localhost [127.0.0.1]) by mailout05 (Postfix) with ESMTP id 859831466A6 for <dispatch@ietf.org>; Mon, 8 Feb 2010 16:58:21 +0100 (CET) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint05 (Postfix) with ESMTPS id 767441466A2; Mon, 8 Feb 2010 16:58:21 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 16:58:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Feb 2010 16:58:21 +0100 Message-ID: <C6A11A02FF1FBF438477BB38132E474105BA6F17@EITO-MBX02.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: Acqo14mggLu69m5STuyR9yNLZwFOTw== From: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> To: <dispatch@ietf.org> X-OriginalArrivalTime: 08 Feb 2010 15:58:22.0566 (UTC) FILETIME=[8A53C060:01CAA8D7] Cc: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com>, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 08 Feb 2010 15:57:23 -0000 Hi Laura, What you describe below about debug-id is the correct understanding. I am not convinced that using session-id for troubleshooting is practical because it implies that everything has to be logged everywhere in the network all the time so that you can, for example, look at any signalling that happened two days ago. The debug-id is inserted as required, and also policed at a couple of entities (first proxy, registrar) to take the burden of deciding whether or not to log away from the rest of the network. The debug-id is also based on 3GPP and OMA requirements, as I mentioned, but these requirements are, I believe, necessary to minimize burden on the network.=20 Starting to read through the threads that consider the idea from Paul Kyzivat: > IMO use cases should be gathered and then bucketed into sets that can=20 > be >=20 > satisfied by a single mechanism, without assuming initially how many=20 > buckets there will be. the beginning of a list of use cases seems to be 3rd-party CC, correlating multiple parallel dialogs, forked requests, requests that pass through B2BUAs. I guess that if an unambiguous test can be expressed for whether a particular session belongs to a set of related sessions, then one header to hold the id that correlates them is enough, even if populating it is difficult for some use cases. For example, I imagine that the debug-id draft could be re-written to use session-id (if session-id is chosen as the single "correlation id" header) to hold the "correlation id" with an added header field parameter to indicate the extra functionality for reducing the network burden of troubleshooting. This would satisfy the troubleshooting and 3GPP/OMA requirements without limiting the meaning of the "correlation id" to troubleshooting.=20 Like you, I would like to find some way forward with the e2e correlation topic (Spencer is right. BOF, CLF whatever...we have to find some way to come forward with the e2e correlation.). Also, our network guys consider session-id to be useful, but I would also like to satisfy some OMA/3GPP requirements that it does not cover. =20 Best Regards, Peter Message: 3 Date: Fri, 5 Feb 2010 17:21:39 +0100 From: <L.Liess@telekom.de> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org>, <spencer@wonderhamster.org> Cc: Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003EFE040@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=3D"iso-8859-1" Hi Peter, My understanding is that session-id and debug-id cover different sets of requirements.=20 Session-id is in every message. If people want to find out what happened two days before, they can look at the old logs and the session-id is there in every message to help them to correlate e2e. For the debug-id to be there you have to know in advance that and which e2e traffic you would like to have correlated. The debug-id is activated "on-demand" and has no performance impact when it is not active, session-id is active all the time. The advantage of the debug-id is that there is no performance impact when debugging is not needed. Is my understanding correct?=20 I like the debug-id stuff, it's really smart and we looked at it. But our troubleshooting and security guys want the session-id, for the reason above. I assume every service provider has its own needs and requirements.=20 Spencer is right. BOF, CLF whatever...we have to find some way to come forward with the e2e correlation.=20 Thanks a lot Laura =20 =20 > -----Original Message----- > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com <mailto:Peter.Dawes@vodafone.com> ] > Sent: Friday, February 05, 2010 4:00 PM > To: dispatch@ietf.org > Cc: Liess, Laura; gonzalo.camarillo@ericsson.com;=20 > HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold > Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hello, > Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 > +0200) as > "1) We have Hadriel's draft, 2) We also have the following draft,=20 > which eventually led to the disaggregated media work: > http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog>=20 > -correlati > on-01.txt 3) We also have the SIP-XMPP work, which may also need to=20 > correlate sessions somehow." >=20 > I would like to add > http://tools.ietf.org/html/draft-dawes-sipping-debug-02 <http://tools.ietf.org/html/draft-dawes-sipping-debug-02> to this=20 > discussion of use cases for some form of correlation identifier. This=20 > draft relates to debugging/troubleshooting to meet documented=20 > requirements from 3GPP and OMA, and proposes a kind of correlation=20 > identifier in a new header. >=20 > Regards, > Peter >=20 >=20 > Message: 2 > Date: Fri, 22 Jan 2010 11:05:57 -0500 > From: Paul Kyzivat <pkyzivat@cisco.com> > Subject: Re: [dispatch] FW: > I-DAction:draft-kaplan-dispatch-session-id-00.txt > To: L.Liess@telekom.de > Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, > Gerold.Pinker@telekom.de > Message-ID: <4B59CCE5.2010202@cisco.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 >=20 >=20 > L.Liess@telekom.de wrote: > > Paul, > >=20 > > Thank you for the examples. The scenarios can be really complex. I > hope we can get these correlation identifiers, whatever their names,=20 > to work correctly in all cases.... > >=20 > > I am not sure I understood your message correctly. Do you say we > should have two different identifiers because we use them for two=20 > different things? >=20 > I think there may be more than two distinct usages that will require=20 > different ones. >=20 > IMO use cases should be gathered and then bucketed into sets that can=20 > be >=20 > satisfied by a single mechanism, without assuming initially how many=20 > buckets there will be. >=20 > (But I'm still on record as not being convinced that a correlation id=20 > is >=20 > needed *at all* for the case when multiple sip UAs are participating=20 > on behalf of a single user in a call.) >=20 > > Thanks a lot > > Laura > >=20 >=20 =20 =20 From ranjit@motorola.com Mon Feb 8 08:45:21 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4484828C165 for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 08:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DywfkxV1Gte for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 08:45:19 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 2CC5828C161 for <dispatch@ietf.org>; Mon, 8 Feb 2010 08:45:19 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1265647580!36141794!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28634 invoked from network); 8 Feb 2010 16:46:20 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Feb 2010 16:46:20 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o18GkK88011640 for <dispatch@ietf.org>; Mon, 8 Feb 2010 09:46:20 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o18GkKlK010146 for <dispatch@ietf.org>; Mon, 8 Feb 2010 10:46:20 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o18GkISU010137 for <dispatch@ietf.org>; Mon, 8 Feb 2010 10:46:19 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Feb 2010 00:45:54 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A2CD1E2@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B701B50.1070804@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification thread-index: AcqoyHhbGZpQSdoiQkyh3AKHxM1PNwAFVJBQ References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><A444A0F8084434499206E78C106220CA6A1C3DC7@MCHP058A.global-ad.net><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com> <A444A0F8084434499206E78C106220CA6A1C488E@MCHP058A.global-ad.net> <4B55F6B7.60002@cisco.com> <C1C95024-5687-4C69-9468-895BD2C9AA71@softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com> <A444A0F8084434499206E78C106220CA6A233EFB@MCHP058A.global-ad.net> <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com> <4B5DA8E3.7050306@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com> <4B6F4 742.4010 500@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD16D@ZMY16EXM66.ds.mot.com> <EDC0A1AE77C57744B664A310A0B23AE20AF618AE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B701B50.1070804@ cisco.co m> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com>, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> X-CFilter-Loop: Reflected Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 08 Feb 2010 16:45:21 -0000 Hi Paul, Keith True. This event package is intended for CDIV procedures outlined in 24.604. The specific CDIV procedures and the event package are already described in 24.604. The schema too is well explained. But 3GPP wanted the event package and the schema to be registered through a informational or standards track RFC as per IETF. So we submitted an I-D proposing the CDIV notification event package putting reference to 24.604.=20 Thanks=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, February 08, 2010 7:40 PM To: DRAGE, Keith (Keith) Cc: Avasarala Ranjit-A20990; DISPATCH Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification DRAGE, Keith (Keith) wrote: > Can I understand where this discussion is going? >=20 > The relevant paragraph of http://tools.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt is: >=20 > Individuals may wish to publish SIP Event packages that they believe > fall outside the scope of any chartered work currently in RAI. > Individual proposals for registration of a SIP event package MUST > first be published as Internet-drafts for review by the DISPATCH > Working Group, or the working group, mailing list, or expert > designated by the RAI Area Directors if the DISPATCH Working Group > has closed. Proposals should include a strong motivational section, > a thorough description of the proposed syntax and semantics, event > package considerations, security considerations, and examples of > usage. Authors should submit their proposals as individual Internet- > Drafts, and post an announcement to the working group mailing list to > begin discussion. The DISPATCH Working Group will determine if a > proposed package is a) an appropriate usage of SIP which should be > spun into a new effort, b) applicable to SIP but not sufficiently > interesting, general, or in-scope to adopt as a working group effort, > c) contrary to similar work chartered in an existing effort, or d) > recommended to be adopted as or merged with chartered work elsewhere > in RAI.=20 >=20 > Are we still trying to prove somehow that this is generally applicable, for which I strongly suspect the answer is NO and it never will be no matter how much manipulation it requires. I started out with the working assumption that this could be of general interest. I still think something addressing the same general area might be. But I am reaching the conclusion that the authors have no particular interest in generalizing it. So I think it is probably better viewed as something specific for the IMS community. If I understand the procedures, it would be ok to publish this as such, but think the text should be very clear about the area of applicability. As currently worded I think people outside the IMS community might attempt to implement it without the guidance of additional IMS documents. IMO if they did so the likelihood of interoperable implementations would be slim to none. Thanks, Paul > Are are we trying to identify that there is some error in the documentation that needs correction? >=20 > regards >=20 > Keith >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 >> Ranjit-A20990 >> Sent: Monday, February 08, 2010 10:09 AM >> To: Paul Kyzivat >> Cc: DISPATCH >> Subject: Re: [dispatch] Comments >> requestedondraft-avasarala-dispatch-comm-div-notification >> >> Hi Paul >> >> My comments <Ranjit-Feb08> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, February 08, 2010 4:36 AM >> To: Avasarala Ranjit-A20990 >> Cc: Elwell, John; DISPATCH >> Subject: Re: [dispatch] Comments >> requestedondraft-avasarala-dispatch-comm-div-notification >> >> inline... >> >> Avasarala Ranjit-A20990 wrote: >> >>>> Assuming sip:alice@office.domain.com is not an AOR, but >> rather is a >>>> registered contact to sip:alice@domain.com, where in the >> routing of >>>> the call does the server that evaluates this rule get control? >>>> >>>> <Ranjit> The server looks for the incoming caller identity and the=20 >>>> destination identity to see if there is a matching rule configured. >>> I guess my question wasn't clear. >>> Where in the routing sequence does this server reside? >>> >>> <Ranjit-Jan27> The server could be the Application Server where the=20 >>> diversion rules reside and get executed. >>> >>> If it is positioned before the contact routing has >> occurred, then it >>> can't know which contact was chosen. >>> <Ranjit-Jan27th> No it would be before that.=20 >>> Since this proposal is coming, more or less, from IMS I >> assume you are >> >>> imagining this is an IMS Application Server. IIRC, those get control >>> *before* contact routing is done by the S-CSCF. So how would the AS=20 >>> know if a particular contact was chosen. (I take some issue with=20 >>> calling contact routing "diversion", but lets not discuss that right >>> now.) >>> >>> <Ranjit-Jan27th> Yes you are right. This proposal is more >> from a IMS >>> and 3GPP perspective and I am trying to generalize it for IETF. >> OK. So once again I have to ask for a description of the system >> architecture(s) in which this event package makes sense - where the=20 >> notifier would have the knowledge to make the proposed kind of=20 >> notifications. >> >> <Ranjit-Feb08> The proposed I-D is actually for registering the=20 >> proposed event package for the communication diversion service=20 >> described in 3GPP TS 24.604. So here the notifier would the AS where=20 >> the communication diversion service is running. So yes it would have=20 >> knowledge of on whose behalf it is Doing the diversion and to whom it >> should notify. >> >>>> If the registered=20 >>>> contact is not an AoR, then the call cannot be >> routed to it >>>> and >>> Huh? Whether the registered contact is an AOR has no bearing on=20 >>> whether its possible to route to it. And, its in general >> impossible to >> >>> determine by looking whether a URI is an AOR or not. >>> >>> <Ranjit-Jan27th> Agree with you on this. >>> >>>> hence will be routed to the main AoR i.e >> sip:alice@domain.com and the >> >>>> rule would not be executed. >>> That statement makes me even more confused. I have no idea what it=20 >>> means. >>> >>> <Ranjit-Jan27th> Here I mean, the notifications would be >> sent to the >>> main AoR with the details of "diverting-user", "diverted-to-user" >>> being part Of the XML package. The notifications need not >> be sent to >>> the registered contact. For e.g if sip:alice@domain.com is >> the AoR and >> >>> diversions are taking Place for sip:alice@office.domain.com, then=20 >>> notifications will be sent to sip:alice@domain.com only and not to=20 >>> sip:alice@domain.com. This will simplify things I feel !! >> I'm am getting more confused, not less. >> >> I think the draft needs some significant rewriting in terms of=20 >> concepts and terminology, as well as assumed architecture, in order=20 >> to be comprehensible in any context other that pure IMS. And frankly=20 >> I don't understand it even if I restrict the context to IMS. >> >> <Ranjit-Feb08> Actually the terminology and the service in general is >> explained in 24.604 (Section 4.10). So we felt that this I-D would=20 >> just Register the proposed event package. >> >>>> But if sip:alice@office.domain.com is an AoR (e.g. GRUU), then the=20 >>>> call could be routed and if there is adiversion rule there, >>>> the diversion rule would get executed and a notification=20 >>>> generated towards that AoR. >>> This is getting more and more confusing. So I have even more desire=20 >>> for at least a detailed use case that shows all the players, their=20 >>> addresses and relationships to one another, and the call flow. >>> >>> <Ranjit-Jan27th> as I mentioned above, to simplify things, >> lets assume >> >>> that notifications always go to the main AoR i.e the Public User Bu=20 >>> Identity (in IMS) And not to any of the registered AoR irrespective=20 >>> of who >> the diverting >> >>> user is. So here even tough the divering user is >> sip:alice@office or >>> sip:alice@home, the notifications always go to sip:alice@domain.com. >> How does that simplify anything? If anything that makes it worse.=20 >> Notifications go to the subscriber, and the content of that=20 >> notification should in general have nothing to do with who the=20 >> subscriber is. (But may be influenced by authorization >> policy.) Notifications are always in-dialog, to the remote target of=20 >> that dialog, and hence pretty much never go to an AOR. >> >> <Ranjit-Feb08> True. Notification go to the subscribed entity as=20 >> shown in the example in 24.604. >> >>>> How would it work in cases where the address for Alice's >> office phone >> >>>> is a dynamically assigned ip address rather than a dns name? >>>> >>>> <Ranjit> Since the notification gets generated dynamically >> when ever >>>> the diversion occurs, the new ip address is taken prior to sending=20 >>>> the notification. >>> Again it seems my question wasn't clear. >>> You are showing rules that contain the contact addresses of >> particular >> >>> devices. If the contact URIs registered by those devices contain=20 >>> dynamically assigned addresses, how would a subscriber know how to=20 >>> construct the rule that selects a particular device? Or if it is=20 >>> receiving all the diversions, how would it relate the >> reported results >> >>> to particular devices? >>> >>> <Ranjit-Jan27th> if the notifications are sent to PUI, then the=20 >>> contact addresses are specified as URLs. So there is no >> need to send >>> any notifications to individual contact adsresses >> You are missing my point entirely. I'm not asking about where the=20 >> notifications are *sent* (which is irrelevant). I'm asking about the >> *content* of those notifications, and of the filters that select=20 >> which ones the subscriber is interested in. >> >> <Ranjit-Feb08> The content of notifications are the elements=20 >> specified in the event pacakge. The example shows both a sample=20 >> notification and the elements that can be used as filters to control=20 >> the content of notifications. E.g. Section >> 4.10.1.1.1.2 of 24.604 >> >> Assume for the moment that we have AOR sip:alice@SSP.com. >> And registered with that AOR are contact addresses=20 >> sip:alice@mobile123.SSP.com and sip:alice@office.domain.com. >> >> Some UA (I'll not say which) is concerned about diversions related to >> that AOR. It subscribes to the comm-div package that=20 >> sip:alice@SSP.com. >> It may include some sort of filter in the subscription. >> >> If a request comes in to the AOR, and neither of the contacts=20 >> responds, a server serving that AOR (perhaps an AS) may eventually=20 >> decide to forward the request to a VM server. I can see how this=20 >> would be considered a real diversion, and how the server would know=20 >> about it. So it can generate a NOTIFY reporting this diversion. >> >> <Ranjit-Feb08> True. So here the notification would be towards=20 >> sip:alice@SSP.com with entity=3D"sip:alice@mobile123.SSP.com OR=20 >> entity=3Dsip:alice@office.SSP.com on whose behlaf the diversion took=20 >> place or where the call landed. >> >> Next, its possible that Alice, from her mobile phone, establishes a=20 >> forwarding rule, that sends all incoming calls to the AOR to=20 >> sip:bob@SSP.com. The server would apply this rule, as policy, to all=20 >> incoming requests to the AOR, bypassing contact routing. Again its=20 >> unremarkable that it would be able to generate a notification when=20 >> carrying out such a retargeting. >> >> <Ranjit-Feb08> so here if Alice gets notified whenever a incoming=20 >> call to her gets forwarded to Bob. If she sets a filter criteria like >> timeofday, then only incoming calls during that time get notified and >> not others. So the notifications depend on the target of the incoming >> call and other specified criteria. >> >> None of that requires any filter on the address at which diversion=20 >> takes place, because it takes place exactly on diversion of requests=20 >> to the same URI to which the subscription was made. >> >> <Ranjit-Feb08> why not? Filters can be set based on time, range of=20 >> time or particular day or context (alice is OOO, etc) >> >> Your filter package implies that the notifier can generate=20 >> notifications for cases where the diversion takes place from some URI >> *other* than the one for which the subscriptions is made. I am=20 >> guessing you mean cases when the diversion takes place after the call >> has been retargeted to one of the contacts. I have two problems with=20 >> that: >> >> <Ranjit-Feb08> No No. Notifier generates notifications only for=20 >> diversions that take place on behalf of the subscribed entity and not >> others. So here sip:alice@SSP.com subscribes to diversions taking=20 >> place at any of its contacts and get notified based on filter=20 >> criteria. The filter critera can specify which contacts the=20 >> notification is required for and which of those notifications are not >> required. >> >> 1) how would the server for sip:alice@SSP.com know that a diversion=20 >> has occurred on a request targetted to sip:alice@office.domain.com? >> >> 2) even if it had a way to discover that, how would a subscriber know >> the URI sip:alice@office.domain.com in order to place it in a filter? >> >> But I find I am repeating myself (see below from before.) There must=20 >> be some fundamental difference in perspective that is preventing us=20 >> from understanding one another. >> >>> This relates, in a way, to whether contact routing is diversion or >> not.=20 >>> Typically what I think of as real diversion would be to a URI that >>> *is* an AOR, and hence stable and knowable by those >> formulating rules. >> >>> But typical contact routing would involve URIs that aren't very >> meaningful. >>> If you want to be able to write rules like: "let me know >> when the call >> >>> is routed to the phone in my office rather than the one in my home" >>> (where both have the same "phone number"), then you are >> going to have >>> to find a way to give those stable URIs, like=20 >>> sip:alice@office.domain.com and sip:alice@home.domain.com. >> AFAIK that >>> isn't the norm, so if you are assuming it then please make >> that clear. >> >> Thanks, >> Paul >> >> Regards >> Ranjit >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From dean.willis@softarmor.com Mon Feb 8 14:38:41 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5A73A74BA for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 14:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziaXeWiUX4Uj for <dispatch@core3.amsl.com>; Mon, 8 Feb 2010 14:38:40 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C59D93A74A8 for <dispatch@ietf.org>; Mon, 8 Feb 2010 14:38:40 -0800 (PST) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o18MdGIt029386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Feb 2010 16:39:17 -0600 From: Dean Willis <dean.willis@softarmor.com> To: Avasarala Ranjit-A20990 <ranjit@motorola.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A2CD1E2@ZMY16EXM66.ds.mot.com> References: <4B4F2403.7010200@ericsson.com> <750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com> <A444A0F8084434499206E78C106220CA6A1C3DC7@MCHP058A.global-ad.net> <750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com> <A444A0F8084434499206E78C106220CA6A1C488E@MCHP058A.global-ad.net> <4B55F6B7.60002@cisco.com> <C1C95024-5687-4C69-9468-895BD2C9AA71@softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com> <A444A0F8084434499206E78C106220CA6A233EFB@MCHP058A.global-ad.net> <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com> <4B5DA8E3.7050306@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com> <4B6F4 742.4010 500@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD16D@ZMY16EXM66.ds.mot.com> <EDC0A1AE77C57744B664A310A0B23AE20AF618AE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B701B50.1070804@ cisco.co m> <750BBC72E178114F9DC4872EBFF29A5B0A2CD1E2@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 08 Feb 2010 16:39:09 -0600 Message-ID: <1265668749.12865.48.camel@damnable-lx> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 08 Feb 2010 22:38:41 -0000 On Tue, 2010-02-09 at 00:45 +0800, Avasarala Ranjit-A20990 wrote: > Hi Paul, Keith > > True. This event package is intended for CDIV procedures outlined in > 24.604. The specific CDIV procedures and the event package are already > described in 24.604. The schema too is well explained. But 3GPP wanted > the event package and the schema to be registered through a > informational or standards track RFC as per IETF. > > So we submitted an I-D proposing the CDIV notification event package > putting reference to 24.604. > So I think we're jut arguing about the applicability statement. Something like "Applicability Statement: The event package defined in this specification is designed to work in the context of IMS, using specifics thereof which are defined in 3GPP specification 24.604.", along with appropriate bibliography entries. Further, the AS should go on to state how the target environment, in general, differs from the "general SIP environment", specifically discussing the assumptions about which servers know about diversion and can act as notifiers. -- Dean From gonzalo.camarillo@ericsson.com Tue Feb 9 01:15:24 2010 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CBB528C0CE for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 01:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.245 X-Spam-Level: X-Spam-Status: No, score=-103.245 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a46deKEfu7rN for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 01:15:21 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id F13AB3A6A3D for <dispatch@ietf.org>; Tue, 9 Feb 2010 01:15:20 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-bf-4b7127e8f042 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DB.C3.02429.8E7217B4; Tue, 9 Feb 2010 10:16:24 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 10:16:24 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 10:16:24 +0100 Message-ID: <4B7127E7.8050403@ericsson.com> Date: Tue, 09 Feb 2010 11:16:23 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH <dispatch@ietf.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2010 09:16:24.0452 (UTC) FILETIME=[8D395C40:01CAA968] X-Brightmail-Tracker: AAAAAA== Cc: Mary Barnes <mbarnes@nortelnetworks.com> Subject: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 09:15:24 -0000 Hi, there have been a set of messages on the list providing comments on the draft below: http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-02 As you know, the process for defining SIP event packages is documented here: http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#section-4.1 Based on the feedback received, the authors need to decide whether they want to generalize their solution so that is is generally applicable to the public Internet or if they want to (further) clarify that this mechanism is intended to work only in IMS networks that provide a CDIV service. If the authors choose the latter approach, we (the DISPATCH chairs) will choose a "Designated Expert" who will check the draft against the 7 points described in the document above. Cheers, Gonzalo DISPATCH co-chair From drage@alcatel-lucent.com Tue Feb 9 07:05:01 2010 Return-Path: <drage@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433D23A71DC for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.326 X-Spam-Level: X-Spam-Status: No, score=-5.326 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJUHowq1d2F7 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:05:00 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 011473A71D4 for <dispatch@ietf.org>; Tue, 9 Feb 2010 07:04:59 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o19EsGfd032564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 9 Feb 2010 16:06:02 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 9 Feb 2010 16:05:09 +0100 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, DISPATCH <dispatch@ietf.org> Date: Tue, 9 Feb 2010 16:05:08 +0100 Thread-Topic: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 Thread-Index: AcqpaJVmMl5h43+pSiiRpyOAY8HnewAMCxBA Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <4B7127E7.8050403@ericsson.com> In-Reply-To: <4B7127E7.8050403@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Mary Barnes <mbarnes@nortelnetworks.com> Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 15:05:01 -0000 At the moment, I think those of us looking at this from the 3GPP way of doi= ng things do not see a more general application of this. I do not have a problem with doing it more generally, but I guess the peopl= e who see a clear use case for that need to speak up and identify their use= cases.=20 Otherwise we end up designing a general event package that no one else ever= uses. As opposed to the alternative of clearly stating the restricted use = to a particular applicability, approving it, and moving on to something els= e with our restricted amount of resources. regards Keith=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Tuesday, February 09, 2010 9:16 AM > To: DISPATCH > Cc: Mary Barnes > Subject: [dispatch] Prorgessing=20 > draft-avasarala-dispatch-comm-div-notification-02 >=20 > Hi, >=20 > there have been a set of messages on the list providing=20 > comments on the draft below: >=20 > http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n > otification-02 >=20 > As you know, the process for defining SIP event packages is=20 > documented here: >=20 > http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se > ction-4.1 >=20 > Based on the feedback received, the authors need to decide=20 > whether they want to generalize their solution so that is is=20 > generally applicable to the public Internet or if they want=20 > to (further) clarify that this mechanism is intended to work=20 > only in IMS networks that provide a CDIV service. >=20 > If the authors choose the latter approach, we (the DISPATCH=20 > chairs) will choose a "Designated Expert" who will check the=20 > draft against the 7 points described in the document above. >=20 > Cheers, >=20 > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From L.Liess@telekom.de Tue Feb 9 07:45:33 2010 Return-Path: <L.Liess@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C60A928C208 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zABrH883o5nb for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:45:31 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id D0FBF28C12F for <dispatch@ietf.org>; Tue, 9 Feb 2010 07:45:30 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 09 Feb 2010 16:46:30 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 16:46:30 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 9 Feb 2010 16:46:31 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003EFE9A7@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <C6A11A02FF1FBF438477BB38132E474105BA6F17@EITO-MBX02.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: RE: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt thread-index: Acqo14mggLu69m5STuyR9yNLZwFOTwAtsEtw References: <C6A11A02FF1FBF438477BB38132E474105BA6F17@EITO-MBX02.internal.vodafone.com> From: <L.Liess@telekom.de> To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org> X-OriginalArrivalTime: 09 Feb 2010 15:46:30.0604 (UTC) FILETIME=[0C60B8C0:01CAA99F] Cc: gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 15:45:33 -0000 Hi Peter,=20 I agree. We should put together a first draft describing the use cases = and, I think, the requirements for each use case. We already have a lot = of stuff in the existing drafts.=20 However, Salvatore tried this about two years ago and it didn't work = then. I think there were two reasons for this (just my personal = opinion):=20 2) People involved with the issue (Hadriel, Dale, myself) had other, = more urgent things to do then. (I think you were not involved in the = discussion then, but I am not sure.) 1) The draft included the disagregated media correlation, which is quite = difficult to compare with the other stuff and this made things quite = complicated. Two or three weeks ago we discussed again the issue = session-id vs. disagregated media correlation and Salvatore and I came = to the conclusion that they are different and we need different = identifiers for them. I don't know if other people agreed to this view.=20 I am not sure it is realistic and very usefull to try submitting a new = draft about the use cases/requirements draft before Anaheim. I am now = quite busy myself and I think other people have the same problem. I = could offer to do main editor for the use cases draft, but after = Anaheim. Or maybe we could begin with Sal's expired use cases draft.=20 I would propose that before Anaheim people interested in the issue try = to read the drafts existing on this issue. Depending on who will attend = Anaheim, we could meet there and discuss first the existing drafts, = overlapping requirements/use cases and the differences. What do you think? Do you intend to attend Anaheim?=20 Laura =20 =20 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dawes, Peter, VF-Group > Sent: Monday, February 08, 2010 4:58 PM > To: dispatch@ietf.org > Cc: Dawes, Peter, VF-Group; gonzalo.camarillo@ericsson.com;=20 > HKaplan@acmepacket.com; H=FClsemann, Martin; Pinker, Gerold > Subject: Re: [dispatch]=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hi Laura, > What you describe below about debug-id is the correct understanding. I > am not convinced that using session-id for troubleshooting is=20 > practical > because it implies that everything has to be logged everywhere in the > network all the time so that you can, for example, look at any > signalling that happened two days ago. The debug-id is inserted as > required, and also policed at a couple of entities (first proxy, > registrar) to take the burden of deciding whether or not to log away > from the rest of the network. The debug-id is also based on=20 > 3GPP and OMA > requirements, as I mentioned, but these requirements are, I believe, > necessary to minimize burden on the network.=20 >=20 > Starting to read through the threads that consider the idea from Paul > Kyzivat: >=20 > > IMO use cases should be gathered and then bucketed into=20 > sets that can=20 >=20 > > be >=20 > >=20 >=20 > > satisfied by a single mechanism, without assuming initially=20 > how many=20 >=20 > > buckets there will be. >=20 > the beginning of a list of use cases seems to be 3rd-party CC, > correlating multiple parallel dialogs, forked requests, requests that > pass through B2BUAs. I guess that if an unambiguous test can be > expressed for whether a particular session belongs to a set of related > sessions, then one header to hold the id that correlates them=20 > is enough, > even if populating it is difficult for some use cases. For example, I > imagine that the debug-id draft could be re-written to use session-id > (if session-id is chosen as the single "correlation id"=20 > header) to hold > the "correlation id" with an added header field parameter to indicate > the extra functionality for reducing the network burden of > troubleshooting. This would satisfy the troubleshooting and 3GPP/OMA > requirements without limiting the meaning of the "correlation id" to > troubleshooting.=20 >=20 > Like you, I would like to find some way forward with the e2e=20 > correlation > topic (Spencer is right. BOF, CLF whatever...we have to find=20 > some way to > come forward with the e2e correlation.). Also, our network=20 > guys consider > session-id to be useful, but I would also like to satisfy=20 > some OMA/3GPP > requirements that it does not cover. =20 >=20 > Best Regards, > Peter >=20 >=20 >=20 >=20 >=20 >=20 > Message: 3 >=20 > Date: Fri, 5 Feb 2010 17:21:39 +0100 >=20 > From: <L.Liess@telekom.de> >=20 > Subject: Re: [dispatch] >=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org>, >=20 > <spencer@wonderhamster.org> >=20 > Cc: Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, >=20 > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de >=20 > Message-ID: >=20 > <40FB0FFB97588246A1BEFB05759DC8A003EFE040@S4DE9JSAANI.ost.t-com.de> >=20 > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Hi Peter, >=20 > My understanding is that session-id and debug-id cover=20 > different sets of > requirements.=20 >=20 > Session-id is in every message. If people want to find out=20 > what happened > two days before, they can look at the old logs and the session-id is > there in every message to help them to correlate e2e. For the debug-id > to be there you have to know in advance that and which e2e traffic you > would like to have correlated. The debug-id is activated=20 > "on-demand" and > has no performance impact when it is not active, session-id is active > all the time. The advantage of the debug-id is that there is no > performance impact when debugging is not needed. Is my understanding > correct?=20 >=20 > I like the debug-id stuff, it's really smart and we looked at it. But > our troubleshooting and security guys want the session-id, for the > reason above. I assume every service provider has its own needs and > requirements.=20 >=20 > Spencer is right. BOF, CLF whatever...we have to find some way to come > forward with the e2e correlation.=20 >=20 > Thanks a lot >=20 > Laura >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- >=20 > > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com > <mailto:Peter.Dawes@vodafone.com> ] >=20 > > Sent: Friday, February 05, 2010 4:00 PM >=20 > > To: dispatch@ietf.org >=20 > > Cc: Liess, Laura; gonzalo.camarillo@ericsson.com;=20 >=20 > > HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold >=20 > > Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > >=20 >=20 > > Hello, >=20 > > Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 >=20 > > +0200) as >=20 > > "1) We have Hadriel's draft, 2) We also have the following draft,=20 >=20 > > which eventually led to the disaggregated media work: >=20 > > http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog>=20 >=20 > > -correlati >=20 > > on-01.txt 3) We also have the SIP-XMPP work, which may also need to=20 >=20 > > correlate sessions somehow." >=20 > >=20 >=20 > > I would like to add >=20 > > http://tools.ietf.org/html/draft-dawes-sipping-debug-02 > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02> to this=20 >=20 > > discussion of use cases for some form of correlation=20 > identifier. This=20 >=20 > > draft relates to debugging/troubleshooting to meet documented=20 >=20 > > requirements from 3GPP and OMA, and proposes a kind of correlation=20 >=20 > > identifier in a new header. >=20 > >=20 >=20 > > Regards, >=20 > > Peter >=20 > >=20 >=20 > >=20 >=20 > > Message: 2 >=20 > > Date: Fri, 22 Jan 2010 11:05:57 -0500 >=20 > > From: Paul Kyzivat <pkyzivat@cisco.com> >=20 > > Subject: Re: [dispatch] FW: >=20 > > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > > To: L.Liess@telekom.de >=20 > > Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, >=20 > > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, >=20 > > Gerold.Pinker@telekom.de >=20 > > Message-ID: <4B59CCE5.2010202@cisco.com> >=20 > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > L.Liess@telekom.de wrote: >=20 > > > Paul, >=20 > > >=20 >=20 > > > Thank you for the examples. The scenarios can be really complex. I >=20 > > hope we can get these correlation identifiers, whatever=20 > their names,=20 >=20 > > to work correctly in all cases.... >=20 > > >=20 >=20 > > > I am not sure I understood your message correctly. Do you say we >=20 > > should have two different identifiers because we use them for two=20 >=20 > > different things? >=20 > >=20 >=20 > > I think there may be more than two distinct usages that=20 > will require=20 >=20 > > different ones. >=20 > >=20 >=20 > > IMO use cases should be gathered and then bucketed into=20 > sets that can=20 >=20 > > be >=20 > >=20 >=20 > > satisfied by a single mechanism, without assuming initially=20 > how many=20 >=20 > > buckets there will be. >=20 > >=20 >=20 > > (But I'm still on record as not being convinced that a=20 > correlation id=20 >=20 > > is >=20 > >=20 >=20 > > needed *at all* for the case when multiple sip UAs are=20 > participating=20 >=20 > > on behalf of a single user in a call.) >=20 > >=20 >=20 > > > Thanks a lot >=20 > > > Laura >=20 > > >=20 >=20 > >=20 >=20 > =20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From L.Liess@telekom.de Tue Feb 9 07:50:02 2010 Return-Path: <L.Liess@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0295C3A73B3 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFf6B9kbVo2I for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:50:00 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id BA8323A708D for <dispatch@ietf.org>; Tue, 9 Feb 2010 07:49:59 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 09 Feb 2010 16:51:04 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 16:51:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 9 Feb 2010 16:51:03 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003EFE9AB@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <C6A11A02FF1FBF438477BB38132E474105BA6F17@EITO-MBX02.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt thread-index: Acqo14mggLu69m5STuyR9yNLZwFOTwAx4oZA References: <C6A11A02FF1FBF438477BB38132E474105BA6F17@EITO-MBX02.internal.vodafone.com> From: <L.Liess@telekom.de> To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org> X-OriginalArrivalTime: 09 Feb 2010 15:51:04.0278 (UTC) FILETIME=[AF800F60:01CAA99F] Cc: gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 15:50:02 -0000 Hi Peter,=20 One more question.=20 >For example, I > imagine that the debug-id draft could be re-written to use session-id > (if session-id is chosen as the single "correlation id"=20 > header) to hold > the "correlation id" with an added header field parameter to indicate > the extra functionality for reducing the network burden of > troubleshooting.=20 I is not realy clear to me how you intend to use the new parameter = field. Could you give me more details? Thanks a lot, Laura > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dawes, Peter, VF-Group > Sent: Monday, February 08, 2010 4:58 PM > To: dispatch@ietf.org > Cc: Dawes, Peter, VF-Group; gonzalo.camarillo@ericsson.com;=20 > HKaplan@acmepacket.com; H=FClsemann, Martin; Pinker, Gerold > Subject: Re: [dispatch]=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hi Laura, > What you describe below about debug-id is the correct understanding. I > am not convinced that using session-id for troubleshooting is=20 > practical > because it implies that everything has to be logged everywhere in the > network all the time so that you can, for example, look at any > signalling that happened two days ago. The debug-id is inserted as > required, and also policed at a couple of entities (first proxy, > registrar) to take the burden of deciding whether or not to log away > from the rest of the network. The debug-id is also based on=20 > 3GPP and OMA > requirements, as I mentioned, but these requirements are, I believe, > necessary to minimize burden on the network.=20 >=20 > Starting to read through the threads that consider the idea from Paul > Kyzivat: >=20 > > IMO use cases should be gathered and then bucketed into=20 > sets that can=20 >=20 > > be >=20 > >=20 >=20 > > satisfied by a single mechanism, without assuming initially=20 > how many=20 >=20 > > buckets there will be. >=20 > the beginning of a list of use cases seems to be 3rd-party CC, > correlating multiple parallel dialogs, forked requests, requests that > pass through B2BUAs. I guess that if an unambiguous test can be > expressed for whether a particular session belongs to a set of related > sessions, then one header to hold the id that correlates them=20 > is enough, > even if populating it is difficult for some use cases. For example, I > imagine that the debug-id draft could be re-written to use session-id > (if session-id is chosen as the single "correlation id"=20 > header) to hold > the "correlation id" with an added header field parameter to indicate > the extra functionality for reducing the network burden of > troubleshooting. This would satisfy the troubleshooting and 3GPP/OMA > requirements without limiting the meaning of the "correlation id" to > troubleshooting.=20 >=20 > Like you, I would like to find some way forward with the e2e=20 > correlation > topic (Spencer is right. BOF, CLF whatever...we have to find=20 > some way to > come forward with the e2e correlation.). Also, our network=20 > guys consider > session-id to be useful, but I would also like to satisfy=20 > some OMA/3GPP > requirements that it does not cover. =20 >=20 > Best Regards, > Peter >=20 >=20 >=20 >=20 >=20 >=20 > Message: 3 >=20 > Date: Fri, 5 Feb 2010 17:21:39 +0100 >=20 > From: <L.Liess@telekom.de> >=20 > Subject: Re: [dispatch] >=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org>, >=20 > <spencer@wonderhamster.org> >=20 > Cc: Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, >=20 > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de >=20 > Message-ID: >=20 > <40FB0FFB97588246A1BEFB05759DC8A003EFE040@S4DE9JSAANI.ost.t-com.de> >=20 > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Hi Peter, >=20 > My understanding is that session-id and debug-id cover=20 > different sets of > requirements.=20 >=20 > Session-id is in every message. If people want to find out=20 > what happened > two days before, they can look at the old logs and the session-id is > there in every message to help them to correlate e2e. For the debug-id > to be there you have to know in advance that and which e2e traffic you > would like to have correlated. The debug-id is activated=20 > "on-demand" and > has no performance impact when it is not active, session-id is active > all the time. The advantage of the debug-id is that there is no > performance impact when debugging is not needed. Is my understanding > correct?=20 >=20 > I like the debug-id stuff, it's really smart and we looked at it. But > our troubleshooting and security guys want the session-id, for the > reason above. I assume every service provider has its own needs and > requirements.=20 >=20 > Spencer is right. BOF, CLF whatever...we have to find some way to come > forward with the e2e correlation.=20 >=20 > Thanks a lot >=20 > Laura >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- >=20 > > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com > <mailto:Peter.Dawes@vodafone.com> ] >=20 > > Sent: Friday, February 05, 2010 4:00 PM >=20 > > To: dispatch@ietf.org >=20 > > Cc: Liess, Laura; gonzalo.camarillo@ericsson.com;=20 >=20 > > HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold >=20 > > Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > >=20 >=20 > > Hello, >=20 > > Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 >=20 > > +0200) as >=20 > > "1) We have Hadriel's draft, 2) We also have the following draft,=20 >=20 > > which eventually led to the disaggregated media work: >=20 > > http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog>=20 >=20 > > -correlati >=20 > > on-01.txt 3) We also have the SIP-XMPP work, which may also need to=20 >=20 > > correlate sessions somehow." >=20 > >=20 >=20 > > I would like to add >=20 > > http://tools.ietf.org/html/draft-dawes-sipping-debug-02 > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02> to this=20 >=20 > > discussion of use cases for some form of correlation=20 > identifier. This=20 >=20 > > draft relates to debugging/troubleshooting to meet documented=20 >=20 > > requirements from 3GPP and OMA, and proposes a kind of correlation=20 >=20 > > identifier in a new header. >=20 > >=20 >=20 > > Regards, >=20 > > Peter >=20 > >=20 >=20 > >=20 >=20 > > Message: 2 >=20 > > Date: Fri, 22 Jan 2010 11:05:57 -0500 >=20 > > From: Paul Kyzivat <pkyzivat@cisco.com> >=20 > > Subject: Re: [dispatch] FW: >=20 > > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > > To: L.Liess@telekom.de >=20 > > Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, >=20 > > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, >=20 > > Gerold.Pinker@telekom.de >=20 > > Message-ID: <4B59CCE5.2010202@cisco.com> >=20 > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > L.Liess@telekom.de wrote: >=20 > > > Paul, >=20 > > >=20 >=20 > > > Thank you for the examples. The scenarios can be really complex. I >=20 > > hope we can get these correlation identifiers, whatever=20 > their names,=20 >=20 > > to work correctly in all cases.... >=20 > > >=20 >=20 > > > I am not sure I understood your message correctly. Do you say we >=20 > > should have two different identifiers because we use them for two=20 >=20 > > different things? >=20 > >=20 >=20 > > I think there may be more than two distinct usages that=20 > will require=20 >=20 > > different ones. >=20 > >=20 >=20 > > IMO use cases should be gathered and then bucketed into=20 > sets that can=20 >=20 > > be >=20 > >=20 >=20 > > satisfied by a single mechanism, without assuming initially=20 > how many=20 >=20 > > buckets there will be. >=20 > >=20 >=20 > > (But I'm still on record as not being convinced that a=20 > correlation id=20 >=20 > > is >=20 > >=20 >=20 > > needed *at all* for the case when multiple sip UAs are=20 > participating=20 >=20 > > on behalf of a single user in a call.) >=20 > >=20 >=20 > > > Thanks a lot >=20 > > > Laura >=20 > > >=20 >=20 > >=20 >=20 > =20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Tue Feb 9 07:56:06 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD3C3A73D8 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2fD6HbCOCv5 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 07:56:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 61EBC3A7221 for <dispatch@ietf.org>; Tue, 9 Feb 2010 07:56:05 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJoUcUtAZnwN/2dsb2JhbADCXJgRgkKCEgQ X-IronPort-AV: E=Sophos;i="4.49,436,1262563200"; d="scan'208";a="84939111" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2010 15:57:11 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o19FvBNq003262; Tue, 9 Feb 2010 15:57:11 GMT Message-ID: <4B7185D8.1090807@cisco.com> Date: Tue, 09 Feb 2010 10:57:12 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> References: <4B7127E7.8050403@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mary Barnes <mbarnes@nortelnetworks.com>, DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 15:56:06 -0000 I don't have a problem with it being IMS-specific. I just want it to *say* that it is IMS-specific. Thanks, Paul DRAGE, Keith (Keith) wrote: > At the moment, I think those of us looking at this from the 3GPP way of doing things do not see a more general application of this. > > I do not have a problem with doing it more generally, but I guess the people who see a clear use case for that need to speak up and identify their use cases. > > Otherwise we end up designing a general event package that no one else ever uses. As opposed to the alternative of clearly stating the restricted use to a particular applicability, approving it, and moving on to something else with our restricted amount of resources. > > regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Tuesday, February 09, 2010 9:16 AM >> To: DISPATCH >> Cc: Mary Barnes >> Subject: [dispatch] Prorgessing >> draft-avasarala-dispatch-comm-div-notification-02 >> >> Hi, >> >> there have been a set of messages on the list providing >> comments on the draft below: >> >> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n >> otification-02 >> >> As you know, the process for defining SIP event packages is >> documented here: >> >> http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se >> ction-4.1 >> >> Based on the feedback received, the authors need to decide >> whether they want to generalize their solution so that is is >> generally applicable to the public Internet or if they want >> to (further) clarify that this mechanism is intended to work >> only in IMS networks that provide a CDIV service. >> >> If the authors choose the latter approach, we (the DISPATCH >> chairs) will choose a "Designated Expert" who will check the >> draft against the 7 points described in the document above. >> >> Cheers, >> >> Gonzalo >> DISPATCH co-chair >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Peter.Dawes@vodafone.com Tue Feb 9 08:14:52 2010 Return-Path: <Peter.Dawes@vodafone.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B8C28C21F for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 08:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK4Lqiwgs-7z for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 08:14:49 -0800 (PST) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by core3.amsl.com (Postfix) with ESMTP id E6D643A73F5 for <dispatch@ietf.org>; Tue, 9 Feb 2010 08:14:48 -0800 (PST) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id 95987453A for <dispatch@ietf.org>; Tue, 9 Feb 2010 17:15:47 +0100 (CET) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint01 (Postfix) with ESMTPS id 7AB544383; Tue, 9 Feb 2010 17:15:47 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 17:15:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Feb 2010 17:15:44 +0100 Message-ID: <C6A11A02FF1FBF438477BB38132E474105C45818@EITO-MBX02.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt Thread-Index: AcqpoyF50ogewnVESnKkGMAsgdnlcQ== From: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> To: <L.Liess@telekom.de>, <dispatch@ietf.org> X-OriginalArrivalTime: 09 Feb 2010 16:15:46.0725 (UTC) FILETIME=[231B8550:01CAA9A3] Cc: gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 16:14:52 -0000 Hi Laura, As I understand it, the session-id header field is included in all requests. I think it would be possible to define a header field parameter for session-id, say "; debug", that is added to session-id by a UA iff certain conditions are met. This is similar to including the debug-id header field iff pre-supplied trigger conditions are matched in the UA. The first proxy can then police sesssion-id header fields containing this parameter (and let others go through unchecked), this parameter can trigger logging in downsteam SIP entities and so on to provide all functions of the debug draft. It might even be possible to use Proxy-Require based on this new parameter to make sure that the logging happens.=20 I am not sure that I want to re-write my draft this way, but it could be a way to separate correlation-id in general from a specific use case (troubleshooting). Best Regards, Peter Message: 5 Date: Tue, 9 Feb 2010 16:51:03 +0100 From: <L.Liess@telekom.de> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org> Cc: gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003EFE9AB@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=3D"iso-8859-1" Hi Peter,=20 One more question.=20 >For example, I > imagine that the debug-id draft could be re-written to use session-id=20 >(if session-id is chosen as the single "correlation id" > header) to hold > the "correlation id" with an added header field parameter to indicate=20 >the extra functionality for reducing the network burden of=20 >troubleshooting. I is not realy clear to me how you intend to use the new parameter field. Could you give me more details? Thanks a lot, Laura > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org <mailto:dispatch-bounces@ietf.org> ] On Behalf Of Dawes, Peter, VF-Group > Sent: Monday, February 08, 2010 4:58 PM > To: dispatch@ietf.org > Cc: Dawes, Peter, VF-Group; gonzalo.camarillo@ericsson.com;=20 > HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold > Subject: Re: [dispatch] > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hi Laura, > What you describe below about debug-id is the correct understanding. I > am not convinced that using session-id for troubleshooting is=20 > practical because it implies that everything has to be logged=20 > everywhere in the network all the time so that you can, for example,=20 > look at any signalling that happened two days ago. The debug-id is=20 > inserted as required, and also policed at a couple of entities (first=20 > proxy, > registrar) to take the burden of deciding whether or not to log away=20 > from the rest of the network. The debug-id is also based on 3GPP and=20 > OMA requirements, as I mentioned, but these requirements are, I=20 > believe, necessary to minimize burden on the network. >=20 > Starting to read through the threads that consider the idea from Paul > Kyzivat: >=20 > > IMO use cases should be gathered and then bucketed into > sets that can >=20 > > be >=20 > >=20 >=20 > > satisfied by a single mechanism, without assuming initially > how many >=20 > > buckets there will be. >=20 > the beginning of a list of use cases seems to be 3rd-party CC,=20 > correlating multiple parallel dialogs, forked requests, requests that=20 > pass through B2BUAs. I guess that if an unambiguous test can be=20 > expressed for whether a particular session belongs to a set of related > sessions, then one header to hold the id that correlates them is=20 > enough, even if populating it is difficult for some use cases. For=20 > example, I imagine that the debug-id draft could be re-written to use=20 > session-id (if session-id is chosen as the single "correlation id" > header) to hold > the "correlation id" with an added header field parameter to indicate=20 > the extra functionality for reducing the network burden of=20 > troubleshooting. This would satisfy the troubleshooting and 3GPP/OMA=20 > requirements without limiting the meaning of the "correlation id" to=20 > troubleshooting. >=20 > Like you, I would like to find some way forward with the e2e=20 > correlation topic (Spencer is right. BOF, CLF whatever...we have to=20 > find some way to come forward with the e2e correlation.). Also, our=20 > network guys consider session-id to be useful, but I would also like=20 > to satisfy some OMA/3GPP requirements that it does not cover. >=20 > Best Regards, > Peter >=20 >=20 >=20 >=20 >=20 >=20 > Message: 3 >=20 > Date: Fri, 5 Feb 2010 17:21:39 +0100 >=20 > From: <L.Liess@telekom.de> >=20 > Subject: Re: [dispatch] >=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org>, >=20 > <spencer@wonderhamster.org> >=20 > Cc: Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, >=20 > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de >=20 > Message-ID: >=20 > <40FB0FFB97588246A1BEFB05759DC8A003EFE040@S4DE9JSAANI.ost.t-com.de> >=20 > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Hi Peter, >=20 > My understanding is that session-id and debug-id cover different sets=20 > of requirements. >=20 > Session-id is in every message. If people want to find out what=20 > happened two days before, they can look at the old logs and the=20 > session-id is there in every message to help them to correlate e2e.=20 > For the debug-id to be there you have to know in advance that and=20 > which e2e traffic you would like to have correlated. The debug-id is=20 > activated "on-demand" and has no performance impact when it is not=20 > active, session-id is active all the time. The advantage of the=20 > debug-id is that there is no performance impact when debugging is not=20 > needed. Is my understanding correct? >=20 > I like the debug-id stuff, it's really smart and we looked at it. But=20 > our troubleshooting and security guys want the session-id, for the=20 > reason above. I assume every service provider has its own needs and=20 > requirements. >=20 > Spencer is right. BOF, CLF whatever...we have to find some way to come > forward with the e2e correlation. >=20 > Thanks a lot >=20 > Laura >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- >=20 > > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com <mailto:Peter.Dawes@vodafone.com>=20 > <mailto:Peter.Dawes@vodafone.com <mailto:Peter.Dawes@vodafone.com> > ] >=20 > > Sent: Friday, February 05, 2010 4:00 PM >=20 > > To: dispatch@ietf.org >=20 > > Cc: Liess, Laura; gonzalo.camarillo@ericsson.com; >=20 > > HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold >=20 > > Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > >=20 >=20 > > Hello, >=20 > > Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 >=20 > > +0200) as >=20 > > "1) We have Hadriel's draft, 2) We also have the following draft, >=20 > > which eventually led to the disaggregated media work: >=20 > > http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog>=20 > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog> > >=20 > > -correlati >=20 > > on-01.txt 3) We also have the SIP-XMPP work, which may also need to >=20 > > correlate sessions somehow." >=20 > >=20 >=20 > > I would like to add >=20 > > http://tools.ietf.org/html/draft-dawes-sipping-debug-02 <http://tools.ietf.org/html/draft-dawes-sipping-debug-02>=20 > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02 <http://tools.ietf.org/html/draft-dawes-sipping-debug-02> > to this >=20 > > discussion of use cases for some form of correlation > identifier. This >=20 > > draft relates to debugging/troubleshooting to meet documented >=20 > > requirements from 3GPP and OMA, and proposes a kind of correlation >=20 > > identifier in a new header. >=20 > >=20 >=20 > > Regards, >=20 > > Peter >=20 > >=20 >=20 > >=20 >=20 > > Message: 2 >=20 > > Date: Fri, 22 Jan 2010 11:05:57 -0500 >=20 > > From: Paul Kyzivat <pkyzivat@cisco.com> >=20 > > Subject: Re: [dispatch] FW: >=20 > > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > > To: L.Liess@telekom.de >=20 > > Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, >=20 > > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, >=20 > > Gerold.Pinker@telekom.de >=20 > > Message-ID: <4B59CCE5.2010202@cisco.com> >=20 > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > L.Liess@telekom.de wrote: >=20 > > > Paul, >=20 > > >=20 >=20 > > > Thank you for the examples. The scenarios can be really complex. I >=20 > > hope we can get these correlation identifiers, whatever > their names, >=20 > > to work correctly in all cases.... >=20 > > >=20 >=20 > > > I am not sure I understood your message correctly. Do you say we >=20 > > should have two different identifiers because we use them for two >=20 > > different things? >=20 > >=20 >=20 > > I think there may be more than two distinct usages that > will require >=20 > > different ones. >=20 > >=20 >=20 > > IMO use cases should be gathered and then bucketed into > sets that can >=20 > > be >=20 > >=20 >=20 > > satisfied by a single mechanism, without assuming initially > how many >=20 > > buckets there will be. >=20 > >=20 >=20 > > (But I'm still on record as not being convinced that a > correlation id >=20 > > is >=20 > >=20 >=20 > > needed *at all* for the case when multiple sip UAs are > participating >=20 > > on behalf of a single user in a call.) >=20 > >=20 >=20 > > > Thanks a lot >=20 > > > Laura >=20 > > >=20 >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>=20 >=20 =20 ------------------------------ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>=20 =20 End of dispatch Digest, Vol 11, Issue 21 **************************************** =20 =20 From drage@alcatel-lucent.com Tue Feb 9 08:53:32 2010 Return-Path: <drage@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E093A741E for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 08:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYKHYXBThxXL for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 08:53:31 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 48AB33A6881 for <dispatch@ietf.org>; Tue, 9 Feb 2010 08:53:31 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o19Grwlo030372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 9 Feb 2010 17:53:58 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 9 Feb 2010 17:53:58 +0100 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Paul Kyzivat <pkyzivat@cisco.com> Date: Tue, 9 Feb 2010 17:53:57 +0100 Thread-Topic: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 Thread-Index: AcqpoJ0dtEmpDTSsSmep6dflug/NxwAB38HQ Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <4B7127E7.8050403@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B7185D8.1090807@cisco.com> In-Reply-To: <4B7185D8.1090807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Mary Barnes <mbarnes@nortelnetworks.com>, DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 16:53:32 -0000 I think that is a given and if that is the way to go, I'm sure we'll all ma= ke sure the words on the front cover go that way. But there seemed to be some prior responses trying to take potential use ca= ses beyond that, and I wanted to make sure that if they existed, they were = explicitly declared. regards Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, February 09, 2010 3:57 PM > To: DRAGE, Keith (Keith) > Cc: Gonzalo Camarillo; DISPATCH; Mary Barnes > Subject: Re: [dispatch] Prorgessing=20 > draft-avasarala-dispatch-comm-div-notification-02 >=20 > I don't have a problem with it being IMS-specific. > I just want it to *say* that it is IMS-specific. >=20 > Thanks, > Paul >=20 > DRAGE, Keith (Keith) wrote: > > At the moment, I think those of us looking at this from the=20 > 3GPP way of doing things do not see a more general=20 > application of this. > >=20 > > I do not have a problem with doing it more generally, but I=20 > guess the people who see a clear use case for that need to=20 > speak up and identify their use cases.=20 > >=20 > > Otherwise we end up designing a general event package that=20 > no one else ever uses. As opposed to the alternative of=20 > clearly stating the restricted use to a particular=20 > applicability, approving it, and moving on to something else=20 > with our restricted amount of resources. > >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > >> Sent: Tuesday, February 09, 2010 9:16 AM > >> To: DISPATCH > >> Cc: Mary Barnes > >> Subject: [dispatch] Prorgessing > >> draft-avasarala-dispatch-comm-div-notification-02 > >> > >> Hi, > >> > >> there have been a set of messages on the list providing=20 > comments on=20 > >> the draft below: > >> > >> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n > >> otification-02 > >> > >> As you know, the process for defining SIP event packages is=20 > >> documented here: > >> > >> http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se > >> ction-4.1 > >> > >> Based on the feedback received, the authors need to decide whether=20 > >> they want to generalize their solution so that is is generally=20 > >> applicable to the public Internet or if they want to (further)=20 > >> clarify that this mechanism is intended to work only in=20 > IMS networks=20 > >> that provide a CDIV service. > >> > >> If the authors choose the latter approach, we (the DISPATCH > >> chairs) will choose a "Designated Expert" who will check the draft=20 > >> against the 7 points described in the document above. > >> > >> Cheers, > >> > >> Gonzalo > >> DISPATCH co-chair > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > = From ranjit@motorola.com Tue Feb 9 09:01:05 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B257928C142 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 09:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNaBu2URC2Ev for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 09:01:04 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 6960F28C136 for <dispatch@ietf.org>; Tue, 9 Feb 2010 09:01:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1265734926!21658199!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 19377 invoked from network); 9 Feb 2010 17:02:07 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-12.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Feb 2010 17:02:06 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o19H26R0028566 for <dispatch@ietf.org>; Tue, 9 Feb 2010 10:02:06 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o19H25N4008295 for <dispatch@ietf.org>; Tue, 9 Feb 2010 11:02:05 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o19H24GW008277 for <dispatch@ietf.org>; Tue, 9 Feb 2010 11:02:05 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 01:01:41 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A2CD3CE@ZMY16EXM66.ds.mot.com> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]Prorgessing draft-avasarala-dispatch-comm-div-notification-02 thread-index: AcqpoJ0dtEmpDTSsSmep6dflug/NxwAB38HQAABN05A= References: <4B7127E7.8050403@ericsson.com><EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><4B7185D8.1090807@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Paul Kyzivat" <pkyzivat@cisco.com> X-CFilter-Loop: Reflected Cc: Mary Barnes <mbarnes@nortelnetworks.com>, DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 17:01:05 -0000 Hi all Sure. I am updating the I-D with the comments and modifying the applicability statement to reflect that it is specific to IMS. Will submit the updated (-03) version of the I-D and then take it forward with Option-2 as suggested by Camarillo. Thanks=20 Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Tuesday, February 09, 2010 10:24 PM To: Paul Kyzivat Cc: Mary Barnes; DISPATCH Subject: Re: [dispatch]Prorgessing draft-avasarala-dispatch-comm-div-notification-02 I think that is a given and if that is the way to go, I'm sure we'll all make sure the words on the front cover go that way. But there seemed to be some prior responses trying to take potential use cases beyond that, and I wanted to make sure that if they existed, they were explicitly declared. regards Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 09, 2010 3:57 PM > To: DRAGE, Keith (Keith) > Cc: Gonzalo Camarillo; DISPATCH; Mary Barnes > Subject: Re: [dispatch] Prorgessing > draft-avasarala-dispatch-comm-div-notification-02 >=20 > I don't have a problem with it being IMS-specific. > I just want it to *say* that it is IMS-specific. >=20 > Thanks, > Paul >=20 > DRAGE, Keith (Keith) wrote: > > At the moment, I think those of us looking at this from the > 3GPP way of doing things do not see a more general application of=20 > this. > >=20 > > I do not have a problem with doing it more generally, but I > guess the people who see a clear use case for that need to speak up=20 > and identify their use cases. > >=20 > > Otherwise we end up designing a general event package that > no one else ever uses. As opposed to the alternative of clearly=20 > stating the restricted use to a particular applicability, approving=20 > it, and moving on to something else with our restricted amount of=20 > resources. > >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > >> Sent: Tuesday, February 09, 2010 9:16 AM > >> To: DISPATCH > >> Cc: Mary Barnes > >> Subject: [dispatch] Prorgessing > >> draft-avasarala-dispatch-comm-div-notification-02 > >> > >> Hi, > >> > >> there have been a set of messages on the list providing > comments on > >> the draft below: > >> > >> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n > >> otification-02 > >> > >> As you know, the process for defining SIP event packages is=20 > >> documented here: > >> > >> http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se > >> ction-4.1 > >> > >> Based on the feedback received, the authors need to decide whether=20 > >> they want to generalize their solution so that is is generally=20 > >> applicable to the public Internet or if they want to (further)=20 > >> clarify that this mechanism is intended to work only in > IMS networks > >> that provide a CDIV service. > >> > >> If the authors choose the latter approach, we (the DISPATCH > >> chairs) will choose a "Designated Expert" who will check the draft=20 > >> against the 7 points described in the document above. > >> > >> Cheers, > >> > >> Gonzalo > >> DISPATCH co-chair > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From salvatore.loreto@ericsson.com Tue Feb 9 09:26:50 2010 Return-Path: <salvatore.loreto@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F214F28C1FE for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 09:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhDpEiVOaf7k for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 09:26:48 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CD5E028C21B for <dispatch@ietf.org>; Tue, 9 Feb 2010 09:26:47 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-59-4b719b192106 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 7C.A0.02429.91B917B4; Tue, 9 Feb 2010 18:27:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 18:27:53 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 18:27:52 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C3E0724C5 for <dispatch@ietf.org>; Tue, 9 Feb 2010 19:27:52 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B9FD721A41 for <dispatch@ietf.org>; Tue, 9 Feb 2010 19:27:52 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3E6C5219CE for <dispatch@ietf.org>; Tue, 9 Feb 2010 19:27:52 +0200 (EET) Message-ID: <4B719B17.6090907@ericsson.com> Date: Tue, 09 Feb 2010 19:27:51 +0200 From: Salvatore Loreto <salvatore.loreto@ericsson.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <C6A11A02FF1FBF438477BB38132E474105C45818@EITO-MBX02.internal.vodafone.com> In-Reply-To: <C6A11A02FF1FBF438477BB38132E474105C45818@EITO-MBX02.internal.vodafone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 Feb 2010 17:27:52.0925 (UTC) FILETIME=[35B940D0:01CAA9AD] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 17:26:50 -0000 Peter, I think your proposal to use a header parameter like "debug" is a reasonable solution. However I would suggest to start from requirements and then arrive to the actual solution. /Sal On 02/09/2010 06:15 PM, Dawes, Peter, VF-Group wrote: > Hi Laura, > As I understand it, the session-id header field is included in all > requests. I think it would be possible to define a header field > parameter for session-id, say "; debug", that is added to session-id by > a UA iff certain conditions are met. This is similar to including the > debug-id header field iff pre-supplied trigger conditions are matched in > the UA. The first proxy can then police sesssion-id header fields > containing this parameter (and let others go through unchecked), this > parameter can trigger logging in downsteam SIP entities and so on to > provide all functions of the debug draft. It might even be possible to > use Proxy-Require based on this new parameter to make sure that the > logging happens. > I am not sure that I want to re-write my draft this way, but it could be > a way to separate correlation-id in general from a specific use case > (troubleshooting). > > Best Regards, > Peter > > > > > > Message: 5 > > Date: Tue, 9 Feb 2010 16:51:03 +0100 > > From:<L.Liess@telekom.de> > > Subject: Re: [dispatch] > > I-DAction:draft-kaplan-dispatch-session-id-00.txt > > To:<Peter.Dawes@vodafone.com>,<dispatch@ietf.org> > > Cc: gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, > > Martin.Huelsemann@telekom.de > > Message-ID: > > <40FB0FFB97588246A1BEFB05759DC8A003EFE9AB@S4DE9JSAANI.ost.t-com.de> > > Content-Type: text/plain; charset="iso-8859-1" > > Hi Peter, > > One more question. > > >> For example, I >> > >> imagine that the debug-id draft could be re-written to use session-id >> > >> (if session-id is chosen as the single "correlation id" >> > >> header) to hold >> > >> the "correlation id" with an added header field parameter to indicate >> > >> the extra functionality for reducing the network burden of >> > >> troubleshooting. >> > I is not realy clear to me how you intend to use the new parameter > field. Could you give me more details? > > Thanks a lot, > > Laura > > >> -----Original Message----- >> > >> From: dispatch-bounces@ietf.org >> > >> [mailto:dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> ] >> > On Behalf Of Dawes, Peter, VF-Group > > >> Sent: Monday, February 08, 2010 4:58 PM >> > >> To: dispatch@ietf.org >> > >> Cc: Dawes, Peter, VF-Group; gonzalo.camarillo@ericsson.com; >> > >> HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold >> > >> Subject: Re: [dispatch] >> > >> I-DAction:draft-kaplan-dispatch-session-id-00.txt >> > >> > >> Hi Laura, >> > >> What you describe below about debug-id is the correct understanding. I >> > > >> am not convinced that using session-id for troubleshooting is >> > >> practical because it implies that everything has to be logged >> > >> everywhere in the network all the time so that you can, for example, >> > >> look at any signalling that happened two days ago. The debug-id is >> > >> inserted as required, and also policed at a couple of entities (first >> > >> proxy, >> > >> registrar) to take the burden of deciding whether or not to log away >> > >> from the rest of the network. The debug-id is also based on 3GPP and >> > >> OMA requirements, as I mentioned, but these requirements are, I >> > >> believe, necessary to minimize burden on the network. >> > >> > >> Starting to read through the threads that consider the idea from Paul >> > >> Kyzivat: >> > >> > >>> IMO use cases should be gathered and then bucketed into >>> > >> sets that can >> > >> > >>> be >>> > >> > >>> > >> > >>> satisfied by a single mechanism, without assuming initially >>> > >> how many >> > >> > >>> buckets there will be. >>> > >> > >> the beginning of a list of use cases seems to be 3rd-party CC, >> > >> correlating multiple parallel dialogs, forked requests, requests that >> > >> pass through B2BUAs. I guess that if an unambiguous test can be >> > >> expressed for whether a particular session belongs to a set of related >> > > >> sessions, then one header to hold the id that correlates them is >> > >> enough, even if populating it is difficult for some use cases. For >> > >> example, I imagine that the debug-id draft could be re-written to use >> > >> session-id (if session-id is chosen as the single "correlation id" >> > >> header) to hold >> > >> the "correlation id" with an added header field parameter to indicate >> > >> the extra functionality for reducing the network burden of >> > >> troubleshooting. This would satisfy the troubleshooting and 3GPP/OMA >> > >> requirements without limiting the meaning of the "correlation id" to >> > >> troubleshooting. >> > >> > >> Like you, I would like to find some way forward with the e2e >> > >> correlation topic (Spencer is right. BOF, CLF whatever...we have to >> > >> find some way to come forward with the e2e correlation.). Also, our >> > >> network guys consider session-id to be useful, but I would also like >> > >> to satisfy some OMA/3GPP requirements that it does not cover. >> > >> > >> Best Regards, >> > >> Peter >> > >> > >> > >> > >> > >> > >> > >> Message: 3 >> > >> > >> Date: Fri, 5 Feb 2010 17:21:39 +0100 >> > >> > >> From:<L.Liess@telekom.de> >> > >> > >> Subject: Re: [dispatch] >> > >> > >> I-DAction:draft-kaplan-dispatch-session-id-00.txt >> > >> > >> To:<Peter.Dawes@vodafone.com>,<dispatch@ietf.org>, >> > >> > >> <spencer@wonderhamster.org> >> > >> > >> Cc: Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, >> > >> > >> HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de >> > >> > >> Message-ID: >> > >> > >> <40FB0FFB97588246A1BEFB05759DC8A003EFE040@S4DE9JSAANI.ost.t-com.de> >> > >> > >> Content-Type: text/plain; charset="iso-8859-1" >> > >> > >> Hi Peter, >> > >> > >> My understanding is that session-id and debug-id cover different sets >> > >> of requirements. >> > >> > >> Session-id is in every message. If people want to find out what >> > >> happened two days before, they can look at the old logs and the >> > >> session-id is there in every message to help them to correlate e2e. >> > >> For the debug-id to be there you have to know in advance that and >> > >> which e2e traffic you would like to have correlated. The debug-id is >> > >> activated "on-demand" and has no performance impact when it is not >> > >> active, session-id is active all the time. The advantage of the >> > >> debug-id is that there is no performance impact when debugging is not >> > >> needed. Is my understanding correct? >> > >> > >> I like the debug-id stuff, it's really smart and we looked at it. But >> > >> our troubleshooting and security guys want the session-id, for the >> > >> reason above. I assume every service provider has its own needs and >> > >> requirements. >> > >> > >> Spencer is right. BOF, CLF whatever...we have to find some way to come >> > > >> forward with the e2e correlation. >> > >> > >> Thanks a lot >> > >> > >> Laura >> > >> > >> > >> > >> > >> > >>> -----Original Message----- >>> > >> > >>> From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com >>> > <mailto:Peter.Dawes@vodafone.com> > > >> <mailto:Peter.Dawes@vodafone.com<mailto:Peter.Dawes@vodafone.com> > ] >> > >> > >>> Sent: Friday, February 05, 2010 4:00 PM >>> > >> > >>> To: dispatch@ietf.org >>> > >> > >>> Cc: Liess, Laura; gonzalo.camarillo@ericsson.com; >>> > >> > >>> HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold >>> > >> > >>> Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt >>> > >> > >>> > >> > >>> Hello, >>> > >> > >>> Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 >>> > >> > >>> +0200) as >>> > >> > >>> "1) We have Hadriel's draft, 2) We also have the following draft, >>> > >> > >>> which eventually led to the disaggregated media work: >>> > >> > >>> http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog >>> > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog> > > >> <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog >> > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog> > > > >> > >>> -correlati >>> > >> > >>> on-01.txt 3) We also have the SIP-XMPP work, which may also need to >>> > >> > >>> correlate sessions somehow." >>> > >> > >>> > >> > >>> I would like to add >>> > >> > >>> http://tools.ietf.org/html/draft-dawes-sipping-debug-02 >>> > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02> > > >> <http://tools.ietf.org/html/draft-dawes-sipping-debug-02 >> > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02> > to this > > >> > >>> discussion of use cases for some form of correlation >>> > >> identifier. This >> > >> > >>> draft relates to debugging/troubleshooting to meet documented >>> > >> > >>> requirements from 3GPP and OMA, and proposes a kind of correlation >>> > >> > >>> identifier in a new header. >>> > >> > >>> > >> > >>> Regards, >>> > >> > >>> Peter >>> > >> > >>> > >> > >>> > >> > >>> Message: 2 >>> > >> > >>> Date: Fri, 22 Jan 2010 11:05:57 -0500 >>> > >> > >>> From: Paul Kyzivat<pkyzivat@cisco.com> >>> > >> > >>> Subject: Re: [dispatch] FW: >>> > >> > >>> I-DAction:draft-kaplan-dispatch-session-id-00.txt >>> > >> > >>> To: L.Liess@telekom.de >>> > >> > >>> Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, >>> > >> > >>> HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, >>> > >> > >>> Gerold.Pinker@telekom.de >>> > >> > >>> Message-ID:<4B59CCE5.2010202@cisco.com> >>> > >> > >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> L.Liess@telekom.de wrote: >>> > >> > >>>> Paul, >>>> > >> > >>>> > >> > >>>> Thank you for the examples. The scenarios can be really complex. I >>>> > >> > >>> hope we can get these correlation identifiers, whatever >>> > >> their names, >> > >> > >>> to work correctly in all cases.... >>> > >> > >>>> > >> > >>>> I am not sure I understood your message correctly. Do you say we >>>> > >> > >>> should have two different identifiers because we use them for two >>> > >> > >>> different things? >>> > >> > >>> > >> > >>> I think there may be more than two distinct usages that >>> > >> will require >> > >> > >>> different ones. >>> > >> > >>> > >> > >>> IMO use cases should be gathered and then bucketed into >>> > >> sets that can >> > >> > >>> be >>> > >> > >>> > >> > >>> satisfied by a single mechanism, without assuming initially >>> > >> how many >> > >> > >>> buckets there will be. >>> > >> > >>> > >> > >>> (But I'm still on record as not being convinced that a >>> > >> correlation id >> > >> > >>> is >>> > >> > >>> > >> > >>> needed *at all* for the case when multiple sip UAs are >>> > >> participating >> > >> > >>> on behalf of a single user in a call.) >>> > >> > >>> > >> > >>>> Thanks a lot >>>> > >> > >>>> Laura >>>> > >> > >>>> > >> > >>> > >> > >> > >> > >> _______________________________________________ >> > >> dispatch mailing list >> > >> dispatch@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/dispatch >> > <https://www.ietf.org/mailman/listinfo/dispatch> > > >> > > > ------------------------------ > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > <https://www.ietf.org/mailman/listinfo/dispatch> > > > > End of dispatch Digest, Vol 11, Issue 21 > > **************************************** > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ankriste@cisco.com Tue Feb 9 12:03:06 2010 Return-Path: <ankriste@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8411628C0FB for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ux3R+BJQY52 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:03:05 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7EF1728C0D0 for <dispatch@ietf.org>; Tue, 9 Feb 2010 12:03:05 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdOcUurRN+K/2dsb2JhbADCJ5gngkIHggsEjkc X-IronPort-AV: E=Sophos;i="4.49,438,1262563200"; d="scan'208";a="148322035" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2010 20:04:13 +0000 Received: from [128.107.147.3] (dhcp-128-107-147-3.cisco.com [128.107.147.3]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o19K4D7D021609 for <dispatch@ietf.org>; Tue, 9 Feb 2010 20:04:13 GMT Message-ID: <4B71BFBD.6040202@cisco.com> Date: Tue, 09 Feb 2010 12:04:13 -0800 From: Anders Kristensen <ankriste@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <4B7127E7.8050403@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B7185D8.1090807@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 20:03:06 -0000 IIUC the IMS use case (or one of them) is that users may configure call forwarding services and forget that they've done so. The CDIV feature then allows them to learn of calls being forwarded and take corrective action. This is not at all IMS specific - the same use case can be said to exist in non-IMS deployments. I suspect addressing this problem in a general way is no more work than to do it in an IMS specific way but would make for a better standard. What's more, if I'm right and this is inherently not an IMS specific problem then the solution is likely to be picked up and used in other contexts regardless of whatever stern wording is on the front page of the RFC. Thanks, Anders On 2/9/2010 8:53 AM, DRAGE, Keith (Keith) wrote: > I think that is a given and if that is the way to go, I'm sure we'll all make sure the words on the front cover go that way. > > But there seemed to be some prior responses trying to take potential use cases beyond that, and I wanted to make sure that if they existed, they were explicitly declared. > > > regards > > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, February 09, 2010 3:57 PM >> To: DRAGE, Keith (Keith) >> Cc: Gonzalo Camarillo; DISPATCH; Mary Barnes >> Subject: Re: [dispatch] Prorgessing >> draft-avasarala-dispatch-comm-div-notification-02 >> >> I don't have a problem with it being IMS-specific. >> I just want it to *say* that it is IMS-specific. >> >> Thanks, >> Paul >> >> DRAGE, Keith (Keith) wrote: >>> At the moment, I think those of us looking at this from the >> 3GPP way of doing things do not see a more general >> application of this. >>> >>> I do not have a problem with doing it more generally, but I >> guess the people who see a clear use case for that need to >> speak up and identify their use cases. >>> >>> Otherwise we end up designing a general event package that >> no one else ever uses. As opposed to the alternative of >> clearly stating the restricted use to a particular >> applicability, approving it, and moving on to something else >> with our restricted amount of resources. >>> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>> Sent: Tuesday, February 09, 2010 9:16 AM >>>> To: DISPATCH >>>> Cc: Mary Barnes >>>> Subject: [dispatch] Prorgessing >>>> draft-avasarala-dispatch-comm-div-notification-02 >>>> >>>> Hi, >>>> >>>> there have been a set of messages on the list providing >> comments on >>>> the draft below: >>>> >>>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n >>>> otification-02 >>>> >>>> As you know, the process for defining SIP event packages is >>>> documented here: >>>> >>>> http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se >>>> ction-4.1 >>>> >>>> Based on the feedback received, the authors need to decide whether >>>> they want to generalize their solution so that is is generally >>>> applicable to the public Internet or if they want to (further) >>>> clarify that this mechanism is intended to work only in >> IMS networks >>>> that provide a CDIV service. >>>> >>>> If the authors choose the latter approach, we (the DISPATCH >>>> chairs) will choose a "Designated Expert" who will check the draft >>>> against the 7 points described in the document above. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> DISPATCH co-chair >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Tue Feb 9 12:50:13 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25443A73F6 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05C7VTKPRi8H for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:50:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6D3DC3A71C3 for <dispatch@ietf.org>; Tue, 9 Feb 2010 12:50:12 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,438,1262563200"; d="scan'208";a="85030280" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2010 20:51:19 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o19KpJ1t027574; Tue, 9 Feb 2010 20:51:19 GMT Message-ID: <4B71CAC6.90802@cisco.com> Date: Tue, 09 Feb 2010 15:51:18 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Anders Kristensen <ankriste@cisco.com> References: <4B7127E7.8050403@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B7185D8.1090807@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B71BFBD.6040202@cisco.com> In-Reply-To: <4B71BFBD.6040202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 09 Feb 2010 20:50:13 -0000 Anders, It was also my assumption going in that this is potentially a problem area of general interest. But the existing solution (as best I understand it) is wed to a particular system architecture - not one that we would likely wish to see enshrined in a more general standard. To get beyond that we would need somebody who is interested in doing the work to get something more general. I'm not seeing anybody stand up to do that. (I know I don't have the time to do it.) Lacking that, I see no justification to block their getting their event package as long as it is suitably scoped. Thanks, Paul Anders Kristensen wrote: > IIUC the IMS use case (or one of them) is that users may configure call > forwarding services and forget that they've done so. The CDIV feature > then allows them to learn of calls being forwarded and take corrective > action. This is not at all IMS specific - the same use case can be said > to exist in non-IMS deployments. > > I suspect addressing this problem in a general way is no more work than > to do it in an IMS specific way but would make for a better standard. > What's more, if I'm right and this is inherently not an IMS specific > problem then the solution is likely to be picked up and used in other > contexts regardless of whatever stern wording is on the front page of > the RFC. > > Thanks, > Anders > > On 2/9/2010 8:53 AM, DRAGE, Keith (Keith) wrote: >> I think that is a given and if that is the way to go, I'm sure we'll >> all make sure the words on the front cover go that way. >> >> But there seemed to be some prior responses trying to take potential >> use cases beyond that, and I wanted to make sure that if they existed, >> they were explicitly declared. >> >> >> regards >> >> Keith >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, February 09, 2010 3:57 PM >>> To: DRAGE, Keith (Keith) >>> Cc: Gonzalo Camarillo; DISPATCH; Mary Barnes >>> Subject: Re: [dispatch] Prorgessing >>> draft-avasarala-dispatch-comm-div-notification-02 >>> >>> I don't have a problem with it being IMS-specific. >>> I just want it to *say* that it is IMS-specific. >>> >>> Thanks, >>> Paul >>> >>> DRAGE, Keith (Keith) wrote: >>>> At the moment, I think those of us looking at this from the >>> 3GPP way of doing things do not see a more general >>> application of this. >>>> >>>> I do not have a problem with doing it more generally, but I >>> guess the people who see a clear use case for that need to >>> speak up and identify their use cases. >>>> >>>> Otherwise we end up designing a general event package that >>> no one else ever uses. As opposed to the alternative of >>> clearly stating the restricted use to a particular >>> applicability, approving it, and moving on to something else >>> with our restricted amount of resources. >>>> >>>> regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>>> Sent: Tuesday, February 09, 2010 9:16 AM >>>>> To: DISPATCH >>>>> Cc: Mary Barnes >>>>> Subject: [dispatch] Prorgessing >>>>> draft-avasarala-dispatch-comm-div-notification-02 >>>>> >>>>> Hi, >>>>> >>>>> there have been a set of messages on the list providing >>> comments on >>>>> the draft below: >>>>> >>>>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n >>>>> otification-02 >>>>> >>>>> As you know, the process for defining SIP event packages is >>>>> documented here: >>>>> >>>>> http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se >>>>> ction-4.1 >>>>> >>>>> Based on the feedback received, the authors need to decide whether >>>>> they want to generalize their solution so that is is generally >>>>> applicable to the public Internet or if they want to (further) >>>>> clarify that this mechanism is intended to work only in >>> IMS networks >>>>> that provide a CDIV service. >>>>> >>>>> If the authors choose the latter approach, we (the DISPATCH >>>>> chairs) will choose a "Designated Expert" who will check the draft >>>>> against the 7 points described in the document above. >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> DISPATCH co-chair >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gonzalo.camarillo@ericsson.com Wed Feb 10 00:32:20 2010 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41EFA28C116 for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 00:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ26glx7OpVy for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 00:32:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8DF2428C0FA for <dispatch@ietf.org>; Wed, 10 Feb 2010 00:32:18 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-90-4b726f560d86 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 29.B2.02429.65F627B4; Wed, 10 Feb 2010 09:33:26 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 09:33:26 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 09:33:25 +0100 Message-ID: <4B726F55.8000804@ericsson.com> Date: Wed, 10 Feb 2010 10:33:25 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat <pkyzivat@cisco.com> References: <4B7127E7.8050403@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B7185D8.1090807@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B71BFBD.6040202@cisco.com> <4B71CAC6.90802@cisco.com> In-Reply-To: <4B71CAC6.90802@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2010 08:33:25.0831 (UTC) FILETIME=[B6A8C570:01CAAA2B] X-Brightmail-Tracker: AAAAAA== Cc: Anders Kristensen <ankriste@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 10 Feb 2010 08:32:20 -0000 Hi, as I stated in my previous email, Paul's description of the situation below is accurate. Cheers, Gonzalo Paul Kyzivat wrote: > Anders, > > It was also my assumption going in that this is potentially a problem > area of general interest. > > But the existing solution (as best I understand it) is wed to a > particular system architecture - not one that we would likely wish to > see enshrined in a more general standard. > > To get beyond that we would need somebody who is interested in doing the > work to get something more general. I'm not seeing anybody stand up to > do that. (I know I don't have the time to do it.) > > Lacking that, I see no justification to block their getting their event > package as long as it is suitably scoped. > > Thanks, > Paul > > Anders Kristensen wrote: >> IIUC the IMS use case (or one of them) is that users may configure call >> forwarding services and forget that they've done so. The CDIV feature >> then allows them to learn of calls being forwarded and take corrective >> action. This is not at all IMS specific - the same use case can be said >> to exist in non-IMS deployments. >> >> I suspect addressing this problem in a general way is no more work than >> to do it in an IMS specific way but would make for a better standard. >> What's more, if I'm right and this is inherently not an IMS specific >> problem then the solution is likely to be picked up and used in other >> contexts regardless of whatever stern wording is on the front page of >> the RFC. >> >> Thanks, >> Anders >> >> On 2/9/2010 8:53 AM, DRAGE, Keith (Keith) wrote: >>> I think that is a given and if that is the way to go, I'm sure we'll >>> all make sure the words on the front cover go that way. >>> >>> But there seemed to be some prior responses trying to take potential >>> use cases beyond that, and I wanted to make sure that if they existed, >>> they were explicitly declared. >>> >>> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, February 09, 2010 3:57 PM >>>> To: DRAGE, Keith (Keith) >>>> Cc: Gonzalo Camarillo; DISPATCH; Mary Barnes >>>> Subject: Re: [dispatch] Prorgessing >>>> draft-avasarala-dispatch-comm-div-notification-02 >>>> >>>> I don't have a problem with it being IMS-specific. >>>> I just want it to *say* that it is IMS-specific. >>>> >>>> Thanks, >>>> Paul >>>> >>>> DRAGE, Keith (Keith) wrote: >>>>> At the moment, I think those of us looking at this from the >>>> 3GPP way of doing things do not see a more general >>>> application of this. >>>>> I do not have a problem with doing it more generally, but I >>>> guess the people who see a clear use case for that need to >>>> speak up and identify their use cases. >>>>> Otherwise we end up designing a general event package that >>>> no one else ever uses. As opposed to the alternative of >>>> clearly stating the restricted use to a particular >>>> applicability, approving it, and moving on to something else >>>> with our restricted amount of resources. >>>>> regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>>>> Sent: Tuesday, February 09, 2010 9:16 AM >>>>>> To: DISPATCH >>>>>> Cc: Mary Barnes >>>>>> Subject: [dispatch] Prorgessing >>>>>> draft-avasarala-dispatch-comm-div-notification-02 >>>>>> >>>>>> Hi, >>>>>> >>>>>> there have been a set of messages on the list providing >>>> comments on >>>>>> the draft below: >>>>>> >>>>>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n >>>>>> otification-02 >>>>>> >>>>>> As you know, the process for defining SIP event packages is >>>>>> documented here: >>>>>> >>>>>> http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se >>>>>> ction-4.1 >>>>>> >>>>>> Based on the feedback received, the authors need to decide whether >>>>>> they want to generalize their solution so that is is generally >>>>>> applicable to the public Internet or if they want to (further) >>>>>> clarify that this mechanism is intended to work only in >>>> IMS networks >>>>>> that provide a CDIV service. >>>>>> >>>>>> If the authors choose the latter approach, we (the DISPATCH >>>>>> chairs) will choose a "Designated Expert" who will check the draft >>>>>> against the 7 points described in the document above. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Gonzalo >>>>>> DISPATCH co-chair >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From L.Liess@telekom.de Wed Feb 10 05:07:20 2010 Return-Path: <L.Liess@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A513A7550 for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 05:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwXq6Omtj-TM for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 05:07:18 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 6633A3A7386 for <dispatch@ietf.org>; Wed, 10 Feb 2010 05:07:16 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 10 Feb 2010 14:08:19 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 14:08:18 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 10 Feb 2010 14:08:17 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003F43E91@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <C6A11A02FF1FBF438477BB38132E474105C45818@EITO-MBX02.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt thread-index: AcqpoyF50ogewnVESnKkGMAsgdnlcQAmDtHQ References: <C6A11A02FF1FBF438477BB38132E474105C45818@EITO-MBX02.internal.vodafone.com> From: <L.Liess@telekom.de> To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org>, <salvatore.loreto@ericsson.com> X-OriginalArrivalTime: 10 Feb 2010 13:08:18.0700 (UTC) FILETIME=[1D2CDCC0:01CAAA52] Cc: gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 10 Feb 2010 13:07:20 -0000 Hi Peter, Thank you. This sounds great to me.=20 Sal is right that we have to define the requirements and use cases = first, but I think having a feeling of how the solution could look like = helps a lot.=20 Kind regards Laura =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dawes, Peter, VF-Group > Sent: Tuesday, February 09, 2010 5:16 PM > To: Liess, Laura; dispatch@ietf.org > Cc: gonzalo.camarillo@ericsson.com; HKaplan@acmepacket.com;=20 > H=FClsemann, Martin > Subject: Re: [dispatch]=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > Hi Laura, > As I understand it, the session-id header field is included in all > requests. I think it would be possible to define a header field > parameter for session-id, say "; debug", that is added to=20 > session-id by > a UA iff certain conditions are met. This is similar to including the > debug-id header field iff pre-supplied trigger conditions are=20 > matched in > the UA. The first proxy can then police sesssion-id header fields > containing this parameter (and let others go through unchecked), this > parameter can trigger logging in downsteam SIP entities and so on to > provide all functions of the debug draft. It might even be possible to > use Proxy-Require based on this new parameter to make sure that the > logging happens.=20 > I am not sure that I want to re-write my draft this way, but=20 > it could be > a way to separate correlation-id in general from a specific use case > (troubleshooting). >=20 > Best Regards, > Peter >=20 >=20 >=20 >=20 >=20 > Message: 5 >=20 > Date: Tue, 9 Feb 2010 16:51:03 +0100 >=20 > From: <L.Liess@telekom.de> >=20 > Subject: Re: [dispatch] >=20 > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org> >=20 > Cc: gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, >=20 > Martin.Huelsemann@telekom.de >=20 > Message-ID: >=20 > <40FB0FFB97588246A1BEFB05759DC8A003EFE9AB@S4DE9JSAANI.ost.t-com.de> >=20 > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Hi Peter,=20 >=20 > One more question.=20 >=20 > >For example, I >=20 > > imagine that the debug-id draft could be re-written to use=20 > session-id=20 >=20 > >(if session-id is chosen as the single "correlation id" >=20 > > header) to hold >=20 > > the "correlation id" with an added header field parameter=20 > to indicate=20 >=20 > >the extra functionality for reducing the network burden of=20 >=20 > >troubleshooting. >=20 > I is not realy clear to me how you intend to use the new parameter > field. Could you give me more details? >=20 > Thanks a lot, >=20 > Laura >=20 > > -----Original Message----- >=20 > > From: dispatch-bounces@ietf.org >=20 > > [mailto:dispatch-bounces@ietf.org=20 > <mailto:dispatch-bounces@ietf.org> ] > On Behalf Of Dawes, Peter, VF-Group >=20 > > Sent: Monday, February 08, 2010 4:58 PM >=20 > > To: dispatch@ietf.org >=20 > > Cc: Dawes, Peter, VF-Group; gonzalo.camarillo@ericsson.com;=20 >=20 > > HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold >=20 > > Subject: Re: [dispatch] >=20 > > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > >=20 >=20 > > Hi Laura, >=20 > > What you describe below about debug-id is the correct=20 > understanding. I >=20 >=20 > > am not convinced that using session-id for troubleshooting is=20 >=20 > > practical because it implies that everything has to be logged=20 >=20 > > everywhere in the network all the time so that you can, for=20 > example,=20 >=20 > > look at any signalling that happened two days ago. The debug-id is=20 >=20 > > inserted as required, and also policed at a couple of=20 > entities (first=20 >=20 > > proxy, >=20 > > registrar) to take the burden of deciding whether or not to=20 > log away=20 >=20 > > from the rest of the network. The debug-id is also based on=20 > 3GPP and=20 >=20 > > OMA requirements, as I mentioned, but these requirements are, I=20 >=20 > > believe, necessary to minimize burden on the network. >=20 > >=20 >=20 > > Starting to read through the threads that consider the idea=20 > from Paul >=20 > > Kyzivat: >=20 > >=20 >=20 > > > IMO use cases should be gathered and then bucketed into >=20 > > sets that can >=20 > >=20 >=20 > > > be >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > satisfied by a single mechanism, without assuming initially >=20 > > how many >=20 > >=20 >=20 > > > buckets there will be. >=20 > >=20 >=20 > > the beginning of a list of use cases seems to be 3rd-party CC,=20 >=20 > > correlating multiple parallel dialogs, forked requests,=20 > requests that=20 >=20 > > pass through B2BUAs. I guess that if an unambiguous test can be=20 >=20 > > expressed for whether a particular session belongs to a set=20 > of related >=20 >=20 > > sessions, then one header to hold the id that correlates them is=20 >=20 > > enough, even if populating it is difficult for some use cases. For=20 >=20 > > example, I imagine that the debug-id draft could be=20 > re-written to use=20 >=20 > > session-id (if session-id is chosen as the single "correlation id" >=20 > > header) to hold >=20 > > the "correlation id" with an added header field parameter=20 > to indicate=20 >=20 > > the extra functionality for reducing the network burden of=20 >=20 > > troubleshooting. This would satisfy the troubleshooting and=20 > 3GPP/OMA=20 >=20 > > requirements without limiting the meaning of the=20 > "correlation id" to=20 >=20 > > troubleshooting. >=20 > >=20 >=20 > > Like you, I would like to find some way forward with the e2e=20 >=20 > > correlation topic (Spencer is right. BOF, CLF whatever...we have to=20 >=20 > > find some way to come forward with the e2e correlation.). Also, our=20 >=20 > > network guys consider session-id to be useful, but I would=20 > also like=20 >=20 > > to satisfy some OMA/3GPP requirements that it does not cover. >=20 > >=20 >=20 > > Best Regards, >=20 > > Peter >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > Message: 3 >=20 > >=20 >=20 > > Date: Fri, 5 Feb 2010 17:21:39 +0100 >=20 > >=20 >=20 > > From: <L.Liess@telekom.de> >=20 > >=20 >=20 > > Subject: Re: [dispatch] >=20 > >=20 >=20 > > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > >=20 >=20 > > To: <Peter.Dawes@vodafone.com>, <dispatch@ietf.org>, >=20 > >=20 >=20 > > <spencer@wonderhamster.org> >=20 > >=20 >=20 > > Cc: Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, >=20 > >=20 >=20 > > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de >=20 > >=20 >=20 > > Message-ID: >=20 > >=20 >=20 > > <40FB0FFB97588246A1BEFB05759DC8A003EFE040@S4DE9JSAANI.ost.t-com.de> >=20 > >=20 >=20 > > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > >=20 >=20 > > Hi Peter, >=20 > >=20 >=20 > > My understanding is that session-id and debug-id cover=20 > different sets=20 >=20 > > of requirements. >=20 > >=20 >=20 > > Session-id is in every message. If people want to find out what=20 >=20 > > happened two days before, they can look at the old logs and the=20 >=20 > > session-id is there in every message to help them to correlate e2e.=20 >=20 > > For the debug-id to be there you have to know in advance that and=20 >=20 > > which e2e traffic you would like to have correlated. The=20 > debug-id is=20 >=20 > > activated "on-demand" and has no performance impact when it is not=20 >=20 > > active, session-id is active all the time. The advantage of the=20 >=20 > > debug-id is that there is no performance impact when=20 > debugging is not=20 >=20 > > needed. Is my understanding correct? >=20 > >=20 >=20 > > I like the debug-id stuff, it's really smart and we looked=20 > at it. But=20 >=20 > > our troubleshooting and security guys want the session-id, for the=20 >=20 > > reason above. I assume every service provider has its own needs and=20 >=20 > > requirements. >=20 > >=20 >=20 > > Spencer is right. BOF, CLF whatever...we have to find some=20 > way to come >=20 >=20 > > forward with the e2e correlation. >=20 > >=20 >=20 > > Thanks a lot >=20 > >=20 >=20 > > Laura >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > > -----Original Message----- >=20 > >=20 >=20 > > > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com > <mailto:Peter.Dawes@vodafone.com>=20 >=20 > > <mailto:Peter.Dawes@vodafone.com=20 > <mailto:Peter.Dawes@vodafone.com> > ] >=20 > >=20 >=20 > > > Sent: Friday, February 05, 2010 4:00 PM >=20 > >=20 >=20 > > > To: dispatch@ietf.org >=20 > >=20 >=20 > > > Cc: Liess, Laura; gonzalo.camarillo@ericsson.com; >=20 > >=20 >=20 > > > HKaplan@acmepacket.com; H?lsemann, Martin; Pinker, Gerold >=20 > >=20 >=20 > > > Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > Hello, >=20 > >=20 >=20 > > > Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03 >=20 > >=20 >=20 > > > +0200) as >=20 > >=20 >=20 > > > "1) We have Hadriel's draft, 2) We also have the following draft, >=20 > >=20 >=20 > > > which eventually led to the disaggregated media work: >=20 > >=20 >=20 > > > http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog>=20 >=20 > > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog > <http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog> > >=20 > >=20 >=20 > > > -correlati >=20 > >=20 >=20 > > > on-01.txt 3) We also have the SIP-XMPP work, which may=20 > also need to >=20 > >=20 >=20 > > > correlate sessions somehow." >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > I would like to add >=20 > >=20 >=20 > > > http://tools.ietf.org/html/draft-dawes-sipping-debug-02 > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02>=20 >=20 > > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02 > <http://tools.ietf.org/html/draft-dawes-sipping-debug-02> > to this >=20 > >=20 >=20 > > > discussion of use cases for some form of correlation >=20 > > identifier. This >=20 > >=20 >=20 > > > draft relates to debugging/troubleshooting to meet documented >=20 > >=20 >=20 > > > requirements from 3GPP and OMA, and proposes a kind of correlation >=20 > >=20 >=20 > > > identifier in a new header. >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > Regards, >=20 > >=20 >=20 > > > Peter >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > Message: 2 >=20 > >=20 >=20 > > > Date: Fri, 22 Jan 2010 11:05:57 -0500 >=20 > >=20 >=20 > > > From: Paul Kyzivat <pkyzivat@cisco.com> >=20 > >=20 >=20 > > > Subject: Re: [dispatch] FW: >=20 > >=20 >=20 > > > I-DAction:draft-kaplan-dispatch-session-id-00.txt >=20 > >=20 >=20 > > > To: L.Liess@telekom.de >=20 > >=20 >=20 > > > Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, >=20 > >=20 >=20 > > > HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, >=20 > >=20 >=20 > > > Gerold.Pinker@telekom.de >=20 > >=20 >=20 > > > Message-ID: <4B59CCE5.2010202@cisco.com> >=20 > >=20 >=20 > > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > L.Liess@telekom.de wrote: >=20 > >=20 >=20 > > > > Paul, >=20 > >=20 >=20 > > > >=20 >=20 > >=20 >=20 > > > > Thank you for the examples. The scenarios can be really=20 > complex. I >=20 > >=20 >=20 > > > hope we can get these correlation identifiers, whatever >=20 > > their names, >=20 > >=20 >=20 > > > to work correctly in all cases.... >=20 > >=20 >=20 > > > >=20 >=20 > >=20 >=20 > > > > I am not sure I understood your message correctly. Do you say we >=20 > >=20 >=20 > > > should have two different identifiers because we use them for two >=20 > >=20 >=20 > > > different things? >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > I think there may be more than two distinct usages that >=20 > > will require >=20 > >=20 >=20 > > > different ones. >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > IMO use cases should be gathered and then bucketed into >=20 > > sets that can >=20 > >=20 >=20 > > > be >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > satisfied by a single mechanism, without assuming initially >=20 > > how many >=20 > >=20 >=20 > > > buckets there will be. >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > (But I'm still on record as not being convinced that a >=20 > > correlation id >=20 > >=20 >=20 > > > is >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > needed *at all* for the case when multiple sip UAs are >=20 > > participating >=20 > >=20 >=20 > > > on behalf of a single user in a call.) >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > > Thanks a lot >=20 > >=20 >=20 > > > > Laura >=20 > >=20 >=20 > > > >=20 >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > _______________________________________________ >=20 > > dispatch mailing list >=20 > > dispatch@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/dispatch > <https://www.ietf.org/mailman/listinfo/dispatch>=20 >=20 > >=20 >=20 > =20 >=20 > ------------------------------ >=20 > _______________________________________________ >=20 > dispatch mailing list >=20 > dispatch@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/dispatch > <https://www.ietf.org/mailman/listinfo/dispatch>=20 >=20 > =20 >=20 > End of dispatch Digest, Vol 11, Issue 21 >=20 > **************************************** >=20 > =20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From fluffy@cisco.com Wed Feb 10 13:28:40 2010 Return-Path: <fluffy@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E0A28C147 for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 13:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4+W4YcxX5Tv for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 13:28:40 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F3BA228C0FC for <dispatch@ietf.org>; Wed, 10 Feb 2010 13:28:39 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUGACe0ckurR7H+/2dsb2JhbAAdmkl0plSKPY0hgmWBcAQ X-IronPort-AV: E=Sophos;i="4.49,446,1262563200"; d="scan'208";a="86423974" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2010 21:29:51 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1ALTp3J026832 for <dispatch@ietf.org>; Wed, 10 Feb 2010 21:29:51 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 10 Feb 2010 14:29:50 -0700 Message-Id: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> To: DISPATCH <dispatch@ietf.org> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 10 Feb 2010 21:28:40 -0000 In IESG review, it got pointed out this name conflicts with SRP (Securer = Remote Password) in the security context. Could folks propose some other = name for the WG be early next week.=20 Thanks, Cullen From stpeter@stpeter.im Wed Feb 10 13:31:02 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C574A3A77BC for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 13:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vgqbF3xfogo for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 13:31:01 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B5F783A77BA for <dispatch@ietf.org>; Wed, 10 Feb 2010 13:31:01 -0800 (PST) Received: from squire.local (dsl-251-115.dynamic-dsl.frii.net [216.17.251.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D3AB640126 for <dispatch@ietf.org>; Wed, 10 Feb 2010 14:32:12 -0700 (MST) Message-ID: <4B7325D3.2030107@stpeter.im> Date: Wed, 10 Feb 2010 14:32:03 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> In-Reply-To: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010500030109030703080101" Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 10 Feb 2010 21:31:02 -0000 This is a cryptographically signed message in MIME format. --------------ms010500030109030703080101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/10/10 2:29 PM, Cullen Jennings wrote: >=20 > In IESG review, it got pointed out this name conflicts with SRP > (Securer Remote Password) in the security context. Could folks > propose some other name for the WG be early next week. I'd suggest "Memorex" but there might be trademark issues. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010500030109030703080101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDIxMDIxMzIwM1owIwYJKoZIhvcNAQkEMRYEFGhgl/VwDB/kfHN5ULW2 pctMNALoMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAMXX4JpcjxnuqgLZF4Ic5kf7jKbDExE74zcmJc/IV 5UFsS20zoWmAoo78QecEKZUv9gUJg3TlKojxfhOJbz9caxkEPxuLyrphiL48wwWfv/S3CxQC NtDO0HpTUdjlJzmcaetHdhOQGvg/yiiO8HOZgzY3vVQd6QiX20PMDxocPV5mM8QJz+e0h6yO voUKSw4oLUip/ihjzQOQZqZwCL7ttruJ5PZVZhLgm5VgKJPvP1F3wbRCTu/Myrgl9mpdirFD CHiAquoXAd3llpimzj6kIMBUyjQA3txeHCCXsZPMNViMIFGFXbegoYRFSvw0OOhX1PNVIzZ/ wS6iohrAS8BtoAAAAAAAAA== --------------ms010500030109030703080101-- From emcho@sip-communicator.org Wed Feb 10 13:32:03 2010 Return-Path: <emcho@sip-communicator.org> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467703A77B7 for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 13:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr9YEaN2m4cQ for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 13:32:02 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id A99713A7607 for <dispatch@ietf.org>; Wed, 10 Feb 2010 13:32:01 -0800 (PST) Received: by ewy28 with SMTP id 28so556269ewy.28 for <dispatch@ietf.org>; Wed, 10 Feb 2010 13:33:09 -0800 (PST) Received: by 10.213.42.79 with SMTP id r15mr1944642ebe.94.1265837589164; Wed, 10 Feb 2010 13:33:09 -0800 (PST) Received: from ?192.168.0.54? (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 15sm1080690ewy.8.2010.02.10.13.33.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 13:33:08 -0800 (PST) Message-ID: <4B732613.9040505@sip-communicator.org> Date: Wed, 10 Feb 2010 22:33:07 +0100 From: Emil Ivov <emcho@sip-communicator.org> Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <B23B311878A0B4438F5F09F47E01AAE04DC322A03F@NOK-EUMSG-01.mgdnok.nokia.com> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <B23B311878A0B4438F5F09F47E01AAE04DC33957F8@NOK-EUMSG-01.mgdnok.nokia.com> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01AAE04DC3395C81@NOK-EUMSG-01.mgdnok.nokia.com> <4B2658FB.50506@sip-communicator.org> <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01AAE04DC342C3A8@NOK-EUMSG-01.mgdnok.nokia.com> <038c01ca7e4d$f7828c70$e687a550$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01@NOK-EUMSG-01.mgdnok.nokia.com> <03fd01ca7f18$8772c9b0$96585d10$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01AAE04E2B49A911@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <B23B311878A0B4438F5F09F47E01AAE04E2B49A911@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 10 Feb 2010 21:32:03 -0000 Hey all, Just wondering where this charter currently stands. Is there any decision as to what will be happening with it? Cheers, Emil Simo.Veikkolainen@nokia.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > Hello, >=20 > I had an offline email exchange with Roni during which he mentioned > that he would be fine with the charter text as it currently stands. >=20 > The other concern that was raised by Emil was on using shared > credentials for SIP and XMPP authentication. My conclusion seemed to > be that the current charter text would be ok, but we can still > document such a feature during the protocol specification phase if > that is deemed useful. >=20 > If my understanding is correct, and unless there are other comments > to the charter proposal, it is good to go. Please let us know asap if > there is still something you would like to comment. >=20 > Regards, Simo >=20 >> -----Original Message----- From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Roni Even Sent: >> 17 December, 2009 14:58 To: Veikkolainen Simo (Nokia-D/Helsinki); >> emcho@sip-communicator.org Cc: dispatch@ietf.org Subject: Re: >> [dispatch] Revised proposed charter for Combining SIP and XMPP >>=20 >> Simo, The other user has two endpoints, one is a video conferencing >> appliance and the other is a PC running XMPP client. The user will >> register his XMPP and SIP capability using the two endpoints in the >> infrastructure Roni >>=20 >>> -----Original Message----- From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>> Simo.Veikkolainen@nokia.com Sent: Thursday, December 17, 2009 >>> 2:34 PM To: Even.roni@huawei.com; emcho@sip-communicator.org Cc: >>> dispatch@ietf.org Subject: Re: [dispatch] Revised proposed >>> charter for Combining SIP and XMPP >>>=20 >>> Roni, >>>=20 >>>>> A "dual stack" SIP/XMPP client should be able to talk SIP to >>>>> a SIP- >>>> only >>>>> endpoint and XMPP to an XMPP-only endpoint. What is that you >>>>> need >> in >>>>> addition to this? >>>> The dual stack client need to know that these two clients are >>>> the >> same >>>> user. For example start a XMPP chat and add the SIP video call. >>>> This >>> is >>>> not advertised by the remote XMPP client but by the >>>> infrastructure. >>>>=20 >>>> From the other direction (two systems) it will involve starting >>>> chat from XMPP and adding SIP video to the call by the XMPP >>>> client for example by telling the other side or the SIP server >>>> to call the his >>> SIP >>>> client on the appliance. >>>>=20 >>> Let me see if I understood you correctly. It sounds you are >>> looking >> for >>> two use cases: >>>=20 >>> 1) to add SIP voice/video or XMPP chat from an integrated >>> endpoint >> even >>> though the other endpoint is SIP-only or XMPP-only >>>=20 >>> 2) to add SIP voice/video or XMPP chat from a XMPP-only or >>> SIP-only endpoint, respectively. >>>=20 >>> For 2), I don't see how that is possible without changes in the >>> client side. >>>=20 >>> For 1), you would need to be able, from a "dual stack" endpoint, >>> to tell the XMPP server to start an XMPP session, or the SIP >>> server to make a SIP call to the same user you already have a SIP >>> or XMPP >> session >>> with. While probably doable, this is not what we had in mind for >>> this work. >>>=20 >>> Simo _______________________________________________ dispatch >>> mailing list dispatch@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing >> list dispatch@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/dispatch >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From Leon.Portman@nice.com Wed Feb 10 14:20:38 2010 Return-Path: <Leon.Portman@nice.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A5F3A74E3 for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 14:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk4oxXFq9QEF for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 14:20:37 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 839D13A7497 for <dispatch@ietf.org>; Wed, 10 Feb 2010 14:20:36 -0800 (PST) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 11 Feb 2010 00:21:46 +0200 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 11 Feb 2010 00:21:46 +0200 From: Leon Portman <Leon.Portman@nice.com> To: "'fluffy@cisco.com'" <fluffy@cisco.com>, "'dispatch@ietf.org'" <dispatch@ietf.org> Date: Thu, 11 Feb 2010 00:21:45 +0200 Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqqmDnDFThEHzIlTpuPEfKuRyuHVwABzPNZ Message-ID: <07465C1D981ABC41A344374066AE1A2C37DAADDA46@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 10 Feb 2010 22:20:38 -0000 Possible names: RECON - recording control REX - recording extensions INTER - Interactions Recording MMREC - multimedia recording Regards Leon ----- Original Message ----- From: dispatch-bounces@ietf.org <dispatch-bounces@ietf.org> To: DISPATCH <dispatch@ietf.org> Sent: Wed Feb 10 23:29:50 2010=0A= Subject: [dispatch] Name for Session Recording WG In IESG review, it got pointed out this name conflicts with SRP (Securer Re= mote Password) in the security context. Could folks propose some other name= for the WG be early next week.=20 Thanks, Cullen _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Wed Feb 10 14:49:06 2010 Return-Path: <adam@nostrum.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39FFB28B56A for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 14:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV34GFQ9HK0y for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 14:49:05 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 314083A761A for <dispatch@ietf.org>; Wed, 10 Feb 2010 14:49:04 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1AMoDeM016368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 16:50:13 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B733825.6010707@nostrum.com> Date: Wed, 10 Feb 2010 16:50:13 -0600 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> In-Reply-To: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 10 Feb 2010 22:49:06 -0000 I would suggest "Network Enabled diVERsion of Multimedia On Recording Equipment," or "NEVERMORE." /a On 2/10/10 15:29, Feb 10, Cullen Jennings wrote: > In IESG review, it got pointed out this name conflicts with SRP (Securer Remote Password) in the security context. Could folks propose some other name for the WG be early next week. > > Thanks, Cullen > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From zhouzp@huawei.com Wed Feb 10 21:22:50 2010 Return-Path: <zhouzp@huawei.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E9B28C1A6 for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 21:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.603 X-Spam-Level: ** X-Spam-Status: No, score=2.603 tagged_above=-999 required=5 tests=[AWL=-2.948, BAYES_50=0.001, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmL9UaRa+WZ9 for <dispatch@core3.amsl.com>; Wed, 10 Feb 2010 21:22:49 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 63CA628C1A3 for <dispatch@ietf.org>; Wed, 10 Feb 2010 21:22:49 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXN00HANWBR74@szxga01-in.huawei.com> for dispatch@ietf.org; Thu, 11 Feb 2010 13:23:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXN00E71WBRJK@szxga01-in.huawei.com> for dispatch@ietf.org; Thu, 11 Feb 2010 13:23:51 +0800 (CST) Received: from z54906b ([10.168.86.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXN00462WBQYM@szxml06-in.huawei.com> for dispatch@ietf.org; Thu, 11 Feb 2010 13:23:51 +0800 (CST) Date: Thu, 11 Feb 2010 13:23:50 +0800 From: zhipeng zhou <zhouzp@huawei.com> To: dispatch@ietf.org Message-id: <00bf01caaada$652eaa70$1856a80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_stoR/fi+2LY1I/A3jci4kw)" Thread-index: Acqq2mS8b89EhpNiRcmxFEEgkpAJbw== Subject: [dispatch] Happy tiger year!!! X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 05:22:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_stoR/fi+2LY1I/A3jci4kw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable All best wishes to you in the chinese tiger year!!! Zhipeng =20 ----------------------------------------------------- Huawei Software Technologies Co.,Ltd. Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China Zipcode:210012 E-Mail: <mailto:zhouzp@huawei.com> zhouzp@huawei.com Phone:(+86) 25-82276771 Fax:(+86) 25-82276760 Mobile:(+86) 13404162849 ----------------------------------------------------- =20 *************************************************************************= *** *********************************** =A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE= =AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2= =CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB= =F2 =C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA= =CE=D0=CE=CA=BD=CA=B9=D3=C3 =A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5= =D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA= =BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3 = =C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1= =A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2= =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 *************************************************************************= *** *********************************** *************************************************************************= *** *********************************** This e-mail and its attachments contain confidential information = from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the = information contained herein in any way(including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited.=20 If you receive this e-mail in error, please notify the sender by = phone or email immediately and delete it! *************************************************************************= *** *********************************** =20 --Boundary_(ID_stoR/fi+2LY1I/A3jci4kw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312"> <META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D439402205-11022010><FONT face=3DArial>All best wishes = to you in=20 the chinese tiger year!!!</FONT></SPAN></DIV> <DIV><SPAN class=3D439402205-11022010><FONT = face=3DArial>Zhipeng</FONT></SPAN></DIV> <DIV> </DIV><?xml:namespace prefix =3D o ns =3D=20 "urn:schemas-microsoft-com:office:office" /><o:SmartTagType = name=3D"City"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"country-region"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"place"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype> <OBJECT id=3Dieooui = classid=3Dclsid:38481807-CA0E-42D2-BF39-B33AF135CC4D></OBJECT> <STYLE> st1\:*{behavior:url(#ieooui) } </STYLE> <STYLE> <!-- /* Font Definitions */ @font-face {font-family:=CB=CE=CC=E5; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-alt:SimSun; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:"\@=CB=CE=CC=E5"; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:Albertus; mso-font-alt:"Times New Roman"; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:auto; mso-font-signature:0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:=CB=CE=CC=E5; mso-bidi-font-family:=CB=CE=CC=E5;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline; text-underline:single;} p.section1, li.section1, div.section1 {mso-style-name:section1; mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; mso-pagination:widow-orphan; font-size:12.0pt; font-family:=CB=CE=CC=E5; mso-bidi-font-family:=CB=CE=CC=E5;} span.SpellE {mso-style-name:""; mso-spl-e:yes;} span.GramE {mso-style-name:""; mso-gram-e:yes;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt; mso-header-margin:42.55pt; mso-footer-margin:49.6pt; mso-paper-source:0;} div.Section1 {page:Section1;} --> </STYLE> <DIV class=3DSection1> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20 style=3D"mso-no-proof: yes"></SPAN><SPAN=20 lang=3DEN-US>-----------------------------------------------------</SPAN>= <SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; = mso-bidi-font-family: Arial"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: = char"><SPAN=20 lang=3DEN-US>Huawei Software Technologies Co.<SPAN=20 class=3DGramE>,Ltd</SPAN>.<o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: = char"><SPAN=20 lang=3DEN-US>Floor 2, Building A, NO.48</SPAN>=A3=AC<SPAN = class=3DSpellE><SPAN=20 lang=3DEN-US>Ning</SPAN></SPAN><SPAN lang=3DEN-US> Nan <SPAN = class=3DSpellE>AV.<SPAN=20 class=3DGramE>,<?xml:namespace prefix =3D st1 ns =3D=20 "urn:schemas-microsoft-com:office:smarttags" /><st1:City=20 w:st=3D"on">Nanjing</st1:City>, </SPAN>P.R.of</SPAN> <st1:country-region = w:st=3D"on"><st1:place=20 w:st=3D"on">China</st1:place></st1:country-region><BR>Zipcode:210012<BR>E= -Mail: <A=20 title=3Dmailto:zhangrenzhou@huawei.com = href=3D"mailto:zhouzp@huawei.com"><SPAN=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; = mso-bidi-font-family: Arial">zhouzp@huawei.com</SPAN></A><BR>Phone:(+86) = 25-82276771<BR>Fax:(+86) 25-82276760</SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: = Albertus"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: = char"><SPAN=20 class=3DGramE><SPAN lang=3DEN-US>Mobile:</SPAN></SPAN><SPAN = lang=3DEN-US>(+86)=20 13404162849<BR>-----------------------------------------------------</SPA= N><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: = Albertus"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20 lang=3DEN-US><o:p> </o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20 lang=3DEN-US>************************************************************= ***************************************************<BR></SPAN>=A1=A1=A1=A1= =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7= =E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE= =CA=BD=CA=B9=D3=C3<SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1=20 style=3D"MARGIN: 0cm 0cm = 0pt">=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7= =D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE= =D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3<SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US><SPAN=20 style=3D"mso-tab-count: 1">   =20 </SPAN></SPAN>=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC= =C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC= =FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1<SPAN=20 lang=3DEN-US><BR>********************************************************= *******************************************************</SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20 lang=3DEN-US><BR>********************************************************= *******************************************************<BR><SPAN=20 style=3D"mso-tab-count: 1">    </SPAN>This e-mail and its = attachments contain confidential information from HUAWEI, which is = intended only=20 for the</SPAN><SPAN lang=3DEN-US style=3D"FONT-SIZE: = 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US>person or entity=20 whose address is listed above. Any use of the information contained = herein in=20 any way(including,</SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US>but = not limited=20 to, total or partial disclosure, reproduction, or dissemination) by = persons=20 other than the intended</SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US>recipient(s) is=20 prohibited. </SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US><SPAN=20 style=3D"mso-tab-count: 1">    </SPAN>If you receive this = e-mail in=20 error, please notify the sender by phone or email immediately and delete = it!<BR>******************************************************************= *********************************************</SPAN></P></DIV> <DIV> </DIV></BODY></HTML> --Boundary_(ID_stoR/fi+2LY1I/A3jci4kw)-- From tobia.castaldi@unina.it Thu Feb 11 01:04:31 2010 Return-Path: <tobia.castaldi@unina.it> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4F63A74F4 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 01:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk1+lQSaXaQH for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 01:04:30 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 388B03A74C7 for <dispatch@ietf.org>; Thu, 11 Feb 2010 01:04:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o1B95BCZ027647; Thu, 11 Feb 2010 10:05:12 +0100 Received: from 143.225.229.176 ([143.225.229.176]) by webmail.unina.it (Horde MIME library) with HTTP; Thu, 11 Feb 2010 10:05:11 +0100 Message-ID: <20100211100511.ntvswphl440kgogg@webmail.unina.it> Date: Thu, 11 Feb 2010 10:05:11 +0100 From: tobia.castaldi@unina.it To: Cullen Jennings <fluffy@cisco.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> In-Reply-To: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it X-Virus-Status: Clean Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 09:04:31 -0000 MARE - Multimedia Assets REcording It's an italian word... it stands for "sea" Tobia Quoting Cullen Jennings <fluffy@cisco.com>: > > In IESG review, it got pointed out this name conflicts with SRP > (Securer Remote Password) in the security context. Could folks > propose some other name for the WG be early next week. > > Thanks, Cullen > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From scottlawrenc@avaya.com Thu Feb 11 04:35:49 2010 Return-Path: <scottlawrenc@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9E43A7341 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 04:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHMEXP57rrq9 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 04:35:49 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 03C233A7067 for <dispatch@ietf.org>; Thu, 11 Feb 2010 04:35:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,451,1262581200"; d="scan'208";a="3207747" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 11 Feb 2010 07:37:02 -0500 X-IronPort-AV: E=Sophos;i="4.49,451,1262581200"; d="scan'208";a="444671298" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Feb 2010 07:37:01 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1BCaft03741; Thu, 11 Feb 2010 12:36:41 GMT Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1BCacL06654; Thu, 11 Feb 2010 12:36:38 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 07:36:08 -0500 From: "Scott Lawrence" <scottlawrenc@avaya.com> To: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> Content-Type: text/plain Organization: Avaya Date: Thu, 11 Feb 2010 07:36:07 -0500 Message-Id: <1265891767.20274.315.camel@scott.home.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2010 12:36:08.0317 (UTC) FILETIME=[C8FD8AD0:01CAAB16] Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 12:35:50 -0000 On Wed, 2010-02-10 at 14:29 -0700, Cullen Jennings wrote: > In IESG review, it got pointed out this name conflicts with SRP > (Securer Remote Password) in the security context. Could folks propose > some other name for the WG be early next week. Unified Session Archival In Datastore (USAID) From christer.holmberg@ericsson.com Thu Feb 11 04:38:40 2010 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CD928C152 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 04:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxcK7Fn51tsj for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 04:38:39 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0031C28C158 for <dispatch@ietf.org>; Thu, 11 Feb 2010 04:38:38 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-cb-4b73fa9784b4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DD.3F.02429.79AF37B4; Thu, 11 Feb 2010 13:39:51 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.147]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 11 Feb 2010 13:39:48 +0100 From: Christer Holmberg <christer.holmberg@ericsson.com> To: Scott Lawrence <scottlawrenc@avaya.com>, Cullen Jennings <fluffy@cisco.com> Date: Thu, 11 Feb 2010 13:39:45 +0100 Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrFwPI+6gfbKpfRdCZDycy+d56bgAADOww Message-ID: <FF84A09F50A6DC48ACB6714F4666CC743F2534A3D2@ESESSCMS0354.eemea.ericsson.se> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <1265891767.20274.315.camel@scott.home.skrb.org> In-Reply-To: <1265891767.20274.315.camel@scott.home.skrb.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 12:38:40 -0000 Intermediate Media Storage (IMS)=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence > Sent: 11. helmikuuta 2010 14:36 > To: Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG >=20 > On Wed, 2010-02-10 at 14:29 -0700, Cullen Jennings wrote: > > In IESG review, it got pointed out this name conflicts with SRP=20 > > (Securer Remote Password) in the security context. Could=20 > folks propose=20 > > some other name for the WG be early next week. >=20 > Unified Session Archival In Datastore (USAID) >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From lorenzo@meetecho.com Thu Feb 11 04:43:27 2010 Return-Path: <lorenzo@meetecho.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D191F28C158 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 04:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G3CYURvGML2 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 04:43:27 -0800 (PST) Received: from smtp5.aruba.it (smtpd3.aruba.it [62.149.128.208]) by core3.amsl.com (Postfix) with SMTP id 6C1C628C104 for <dispatch@ietf.org>; Thu, 11 Feb 2010 04:43:26 -0800 (PST) Received: (qmail 29459 invoked by uid 89); 11 Feb 2010 12:44:35 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.172) by smtp5.ad.aruba.it with SMTP; 11 Feb 2010 12:44:35 -0000 Date: Thu, 11 Feb 2010 13:43:26 +0100 From: Lorenzo Miniero <lorenzo@meetecho.com> To: Adam Roach <adam@nostrum.com> Message-Id: <20100211134326.72878615.lorenzo@meetecho.com> In-Reply-To: <4B733825.6010707@nostrum.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <4B733825.6010707@nostrum.com> Organization: Meetecho X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 12:43:27 -0000 I like this name, and the fact there's a metal band with the same name is totally irrelevant! ;) L. On Wed, 10 Feb 2010 16:50:13 -0600 Adam Roach <adam@nostrum.com> wrote: > I would suggest "Network Enabled diVERsion of Multimedia On Recording > Equipment," or "NEVERMORE." > > /a > > On 2/10/10 15:29, Feb 10, Cullen Jennings wrote: > > In IESG review, it got pointed out this name conflicts with SRP (Securer Remote Password) in the security context. Could folks propose some other name for the WG be early next week. > > > > Thanks, Cullen > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Lorenzo Miniero Meetecho s.r.l. http://www.meetecho.com/ From Markus.Isomaki@nokia.com Thu Feb 11 05:06:23 2010 Return-Path: <Markus.Isomaki@nokia.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB2C28C1C5 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 05:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgIxONohkPRq for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 05:06:21 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 2F4EA3A76D7 for <dispatch@ietf.org>; Thu, 11 Feb 2010 05:06:20 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o1BD6mJ5031229; Thu, 11 Feb 2010 15:07:30 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 15:07:26 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 15:07:21 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 11 Feb 2010 14:07:20 +0100 From: <Markus.Isomaki@nokia.com> To: <emcho@sip-communicator.org>, <Simo.Veikkolainen@nokia.com> Date: Thu, 11 Feb 2010 14:07:18 +0100 Thread-Topic: [dispatch] Revised proposed charter for Combining SIP and XMPP Thread-Index: AcqqmLHFc65eGRpyQayJRLUyFOJargAer5NA Message-ID: <B3F72E5548B10A4A8E6F4795430F84182DEE50A7F7@NOK-EUMSG-02.mgdnok.nokia.com> References: <B23B311878A0B4438F5F09F47E01AAE04DC322A03F@NOK-EUMSG-01.mgdnok.nokia.com> <1260472418.25475.1915.camel@scott> <8647CF2D344C40F19ABD162093605F46@china.huawei.com> <4B214EA7.1090405@sip-communicator.org> <787991D583944628AC6F8AB34A67EF4F@china.huawei.com> <4B215477.7000003@sip-communicator.org> <B23B311878A0B4438F5F09F47E01AAE04DC33957F8@NOK-EUMSG-01.mgdnok.nokia.com> <4B26233D.60104@sip-communicator.org> <4B26386C.5040704@cisco.com> <01fa01ca7cc3$73e8e430$5bbaac90$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01AAE04DC3395C81@NOK-EUMSG-01.mgdnok.nokia.com> <4B2658FB.50506@sip-communicator.org> <027001ca7d11$5577c8b0$00675a10$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01AAE04DC342C3A8@NOK-EUMSG-01.mgdnok.nokia.com> <038c01ca7e4d$f7828c70$e687a550$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01@NOK-EUMSG-01.mgdnok.nokia.com> <03fd01ca7f18$8772c9b0$96585d10$%roni@huawei.com> <B23B311878A0B4438F5F09F47E01AAE04E2B49A911@NOK-EUMSG-01.mgdnok.nokia.com> <4B732613.9040505@sip-communicator.org> In-Reply-To: <4B732613.9040505@sip-communicator.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2010 13:07:21.0020 (UTC) FILETIME=[253557C0:01CAAB1B] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter for Combining SIP and XMPP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 13:06:23 -0000 Hi Emil, We have gotten the charter proposal as far as the RAI ADs, but we haven't g= otten an approval yet. Simo and me are anyway working on a draft (based on our earlier draft) that= would crystallize the use cases and requirements, and would fit as the fir= st deliverable according to the charter. Once we get that out, I propose to= focus the discussion on that to make sure we agree on that part of the wor= k.=20 The technical solution work can definitely progress in parallel, but right = now at least Simo and me don't have much to add to what we have already sub= mitted and what was discussed in Hiroshima and on the list. It would be use= ful to put together a presentation of the different options (the ones outli= ned in our current draft and those proposed by others) together before Anah= eim also to see how easy it will be to find consensus on those. Would someo= ne volunteer to take that task? (If not, Simo and me can take a stab on tha= t too, but I remember a few hands were raised at the BOF :-). If we manage to get a slot at Anaheim I suppose these would be the things o= n the agenda as well: 1. Use cases and requirements --> are we happy to adopt a draft as a WG ite= m to work towards the first deliverable 2. Go through the different technical approaches --> can we find consensus = and also can we find an editor for the draft or drafts defining the extensi= ons we want to standardize Regarding the combined client provisioning/configuration issue that you, Em= il, brought up: I was thinking that it might be wise to actually write a sh= ort draft (a BCP) about the best ways how to arrange the autoconfig of a co= mbined SIP/XMPP client. On SIP side we finally a pretty decent approach wit= h the recent SIP Forum UA-config work (Scott Lawrence, John Elwell et al) a= nd there are ways for XMPP as well, so we could take those as the baseline.= Perhaps we could write something about the case that a single service prov= ider offers both SIP and XMPP accounts and what synergies might exist for s= uch a case. Do you Emil think that would be a useful thing to have? Markus >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Emil Ivov >Sent: 10 February, 2010 23:33 >To: Veikkolainen Simo (Nokia-D/Helsinki) >Cc: dispatch@ietf.org >Subject: Re: [dispatch] Revised proposed charter for Combining=20 >SIP and XMPP > >Hey all, > >Just wondering where this charter currently stands. Is there=20 >any decision as to what will be happening with it? > >Cheers, >Emil > >Simo.Veikkolainen@nokia.com =CE=C1=D0=C9=D3=C1: >> Hello, >>=20 >> I had an offline email exchange with Roni during which he mentioned=20 >> that he would be fine with the charter text as it currently stands. >>=20 >> The other concern that was raised by Emil was on using shared=20 >> credentials for SIP and XMPP authentication. My conclusion seemed to=20 >> be that the current charter text would be ok, but we can still=20 >> document such a feature during the protocol specification phase if=20 >> that is deemed useful. >>=20 >> If my understanding is correct, and unless there are other=20 >comments to=20 >> the charter proposal, it is good to go. Please let us know asap if=20 >> there is still something you would like to comment. >>=20 >> Regards, Simo >>=20 >>> -----Original Message----- From: dispatch-bounces@ietf.org=20 >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Roni Even Sent: >>> 17 December, 2009 14:58 To: Veikkolainen Simo (Nokia-D/Helsinki);=20 >>> emcho@sip-communicator.org Cc: dispatch@ietf.org Subject: Re: >>> [dispatch] Revised proposed charter for Combining SIP and XMPP >>>=20 >>> Simo, The other user has two endpoints, one is a video conferencing=20 >>> appliance and the other is a PC running XMPP client. The user will=20 >>> register his XMPP and SIP capability using the two endpoints in the=20 >>> infrastructure Roni >>>=20 >>>> -----Original Message----- From: dispatch-bounces@ietf.org=20 >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 >>>> Simo.Veikkolainen@nokia.com Sent: Thursday, December 17, 2009 >>>> 2:34 PM To: Even.roni@huawei.com; emcho@sip-communicator.org Cc: >>>> dispatch@ietf.org Subject: Re: [dispatch] Revised proposed charter=20 >>>> for Combining SIP and XMPP >>>>=20 >>>> Roni, >>>>=20 >>>>>> A "dual stack" SIP/XMPP client should be able to talk SIP to a=20 >>>>>> SIP- >>>>> only >>>>>> endpoint and XMPP to an XMPP-only endpoint. What is that you need >>> in >>>>>> addition to this? >>>>> The dual stack client need to know that these two clients are the >>> same >>>>> user. For example start a XMPP chat and add the SIP video call. >>>>> This >>>> is >>>>> not advertised by the remote XMPP client but by the=20 >infrastructure. >>>>>=20 >>>>> From the other direction (two systems) it will involve starting=20 >>>>> chat from XMPP and adding SIP video to the call by the=20 >XMPP client=20 >>>>> for example by telling the other side or the SIP server=20 >to call the=20 >>>>> his >>>> SIP >>>>> client on the appliance. >>>>>=20 >>>> Let me see if I understood you correctly. It sounds you are looking >>> for >>>> two use cases: >>>>=20 >>>> 1) to add SIP voice/video or XMPP chat from an integrated endpoint >>> even >>>> though the other endpoint is SIP-only or XMPP-only >>>>=20 >>>> 2) to add SIP voice/video or XMPP chat from a XMPP-only or=20 >SIP-only=20 >>>> endpoint, respectively. >>>>=20 >>>> For 2), I don't see how that is possible without changes in the=20 >>>> client side. >>>>=20 >>>> For 1), you would need to be able, from a "dual stack"=20 >endpoint, to=20 >>>> tell the XMPP server to start an XMPP session, or the SIP=20 >server to=20 >>>> make a SIP call to the same user you already have a SIP or XMPP >>> session >>>> with. While probably doable, this is not what we had in mind for=20 >>>> this work. >>>>=20 >>>> Simo _______________________________________________ dispatch=20 >>>> mailing list dispatch@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ dispatch=20 >mailing list=20 >>> dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch >>=20 > >--=20 >Emil Ivov, Ph.D. 67000 Strasbourg, >Project Lead France >SIP Communicator >emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 >http://sip-communicator.org FAX: +33.1.77.62.47.31 > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch >= From steve.logalbo@cybertech-na.com Thu Feb 11 05:59:34 2010 Return-Path: <steve.logalbo@cybertech-na.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69843A74EB for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 05:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFju68ytocUc for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 05:59:32 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id AF0113A74C3 for <dispatch@ietf.org>; Thu, 11 Feb 2010 05:59:31 -0800 (PST) Received: from source ([96.57.220.202]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS3QNjZZqKjRv8FYoJ+nz/r55H61Zg64c@postini.com; Thu, 11 Feb 2010 06:00:46 PST Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 08:56:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <30DCAC26D8996F47881979D00DF30B556F1C4E@avoxsrv001.avoxsolutions.local> In-Reply-To: <FF84A09F50A6DC48ACB6714F4666CC743F2534A3D2@ESESSCMS0354.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrFwPI+6gfbKpfRdCZDycy+d56bgAADOwwAAKrIyA= References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><1265891767.20274.315.camel@scott.home.skrb.org> <FF84A09F50A6DC48ACB6714F4666CC743F2534A3D2@ESESSCMS0354.eemea.ericsson.se> From: "Steven LoGalbo" <steve.logalbo@cybertech-na.com> To: "Christer Holmberg" <christer.holmberg@ericsson.com>, "Scott Lawrence" <scottlawrenc@avaya.com>, "Cullen Jennings" <fluffy@cisco.com> Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 13:59:34 -0000 SRIP - Session Recording Initiation Protocol -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, February 11, 2010 7:40 AM To: Scott Lawrence; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG Intermediate Media Storage (IMS)=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence > Sent: 11. helmikuuta 2010 14:36 > To: Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG >=20 > On Wed, 2010-02-10 at 14:29 -0700, Cullen Jennings wrote: > > In IESG review, it got pointed out this name conflicts with SRP=20 > > (Securer Remote Password) in the security context. Could=20 > folks propose=20 > > some other name for the WG be early next week. >=20 > Unified Session Archival In Datastore (USAID) >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From andrew.hutton@siemens-enterprise.com Thu Feb 11 06:06:15 2010 Return-Path: <andrew.hutton@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7089D3A7379 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvQ11Otdkw5J for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:06:14 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 54C143A71D7 for <dispatch@ietf.org>; Thu, 11 Feb 2010 06:06:14 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-859914; Thu, 11 Feb 2010 15:06:36 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 6A1341EB82AB; Thu, 11 Feb 2010 15:06:36 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 11 Feb 2010 15:06:36 +0100 From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> To: Steven LoGalbo <steve.logalbo@cybertech-na.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Scott Lawrence <scottlawrenc@avaya.com>, Cullen Jennings <fluffy@cisco.com> Date: Thu, 11 Feb 2010 15:07:00 +0100 Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrFwPI+6gfbKpfRdCZDycy+d56bgAADOwwAAKrIyAAAFl0IA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E306EEB592B6@MCHP058A.global-ad.net> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><1265891767.20274.315.camel@scott.home.skrb.org> <FF84A09F50A6DC48ACB6714F4666CC743F2534A3D2@ESESSCMS0354.eemea.ericsson.se> <30DCAC26D8996F47881979D00DF30B556F1C4E@avoxsrv001.avoxsolutions.local> In-Reply-To: <30DCAC26D8996F47881979D00DF30B556F1C4E@avoxsrv001.avoxsolutions.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 14:06:15 -0000 I quite like SRIP but I don't think we should call it a protocol. I suggest "Media Recording using the Session Initiation Protocol" or "MRSIP= ". Regards Andy =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Steven LoGalbo Sent: 11 February 2010 13:57 To: Christer Holmberg; Scott Lawrence; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG SRIP - Session Recording Initiation Protocol -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, February 11, 2010 7:40 AM To: Scott Lawrence; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG Intermediate Media Storage (IMS)=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence > Sent: 11. helmikuuta 2010 14:36 > To: Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG >=20 > On Wed, 2010-02-10 at 14:29 -0700, Cullen Jennings wrote: > > In IESG review, it got pointed out this name conflicts with SRP=20 > > (Securer Remote Password) in the security context. Could=20 > folks propose=20 > > some other name for the WG be early next week. >=20 > Unified Session Archival In Datastore (USAID) >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From steve.logalbo@cybertech-na.com Thu Feb 11 06:23:12 2010 Return-Path: <steve.logalbo@cybertech-na.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E691028C1D6 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX2+oOwvOap8 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:23:12 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id A981228C1D2 for <dispatch@ietf.org>; Thu, 11 Feb 2010 06:23:11 -0800 (PST) Received: from source ([96.57.220.202]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKS3QTGWlU2Uq6mIwgLn1MiwZQXFYghbvW@postini.com; Thu, 11 Feb 2010 06:24:26 PST Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 09:20:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <30DCAC26D8996F47881979D00DF30B556F1C53@avoxsrv001.avoxsolutions.local> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E306EEB592B6@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrFwPI+6gfbKpfRdCZDycy+d56bgAADOwwAAKrIyAAAFl0IAAAenVA References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><1265891767.20274.315.camel@scott.home.skrb.org><FF84A09F50A6DC48ACB6714F4666CC743F2534A3D2@ESESSCMS0354.eemea.ericsson.se> <30DCAC26D8996F47881979D00DF30B556F1C4E@avoxsrv001.avoxsolutions.local> <101C6067BEC68246B0C3F6843BCCC1E306EEB592B6@MCHP058A.global-ad.net> From: "Steven LoGalbo" <steve.logalbo@cybertech-na.com> To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, "Christer Holmberg" <christer.holmberg@ericsson.com>, "Scott Lawrence" <scottlawrenc@avaya.com>, "Cullen Jennings" <fluffy@cisco.com> Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 14:23:13 -0000 SRI - Session Recording Interface? IPSR - IP Session Recording? Regards, Steve LoGalbo steve.logalbo@cybertech-na.com 914-269-4099 -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: Thursday, February 11, 2010 9:07 AM To: Steven LoGalbo; Christer Holmberg; Scott Lawrence; Cullen Jennings Cc: DISPATCH Subject: RE: [dispatch] Name for Session Recording WG I quite like SRIP but I don't think we should call it a protocol. I suggest "Media Recording using the Session Initiation Protocol" or "MRSIP". Regards Andy =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Steven LoGalbo Sent: 11 February 2010 13:57 To: Christer Holmberg; Scott Lawrence; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG SRIP - Session Recording Initiation Protocol -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, February 11, 2010 7:40 AM To: Scott Lawrence; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG Intermediate Media Storage (IMS)=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence > Sent: 11. helmikuuta 2010 14:36 > To: Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG >=20 > On Wed, 2010-02-10 at 14:29 -0700, Cullen Jennings wrote: > > In IESG review, it got pointed out this name conflicts with SRP=20 > > (Securer Remote Password) in the security context. Could=20 > folks propose=20 > > some other name for the WG be early next week. >=20 > Unified Session Archival In Datastore (USAID) >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From vkg@alcatel-lucent.com Thu Feb 11 06:41:34 2010 Return-Path: <vkg@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FA13A7704 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zly6aanLwHi for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:41:33 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 18A453A73CC for <dispatch@ietf.org>; Thu, 11 Feb 2010 06:41:32 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o1BEgBbd004859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 08:42:14 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o1BEgATf010181; Thu, 11 Feb 2010 08:42:10 -0600 (CST) Message-ID: <4B741742.4090906@alcatel-lucent.com> Date: Thu, 11 Feb 2010 08:42:10 -0600 From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com> Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <20100211100511.ntvswphl440kgogg@webmail.unina.it> In-Reply-To: <20100211100511.ntvswphl440kgogg@webmail.unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 14:41:34 -0000 tobia.castaldi@unina.it wrote: Cullen Jennings <fluffy@cisco.com> wrote: > > In IESG review, it got pointed out this name conflicts with SRP > (Securer Remote Password) in the security context. Could folks > propose some other name for the WG be early next week. Someone suggested "memorex", which was good. But if "memorex" is infringing on a possible trademark, how about yaad - Yet Another Acoustic Diverter Plus, "yaad" is a Hindi word for "memory". Ciao, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From Leon.Portman@nice.com Thu Feb 11 06:54:48 2010 Return-Path: <Leon.Portman@nice.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9353A76EB for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVjU08LlAxhi for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:54:47 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id E74E93A755A for <dispatch@ietf.org>; Thu, 11 Feb 2010 06:54:46 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 11 Feb 2010 16:55:59 +0200 From: Leon Portman <Leon.Portman@nice.com> To: Cullen Jennings <fluffy@cisco.com> Date: Thu, 11 Feb 2010 16:55:59 +0200 Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrKIWnMPyeO3GvTW6wutffvZHJ2gAAcVlQ Message-ID: <07465C1D981ABC41A344374066AE1A2C37DAC84527@TLVMBX01.nice.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <20100211100511.ntvswphl440kgogg@webmail.unina.it> <4B741742.4090906@alcatel-lucent.com> In-Reply-To: <4B741742.4090906@alcatel-lucent.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 14:54:48 -0000 Another option: RUM - Recording of Unified Media Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Vijay K. Gurbani Sent: Thursday, February 11, 2010 4:42 PM To: Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG tobia.castaldi@unina.it wrote: Cullen Jennings <fluffy@cisco.com> wrote: > > In IESG review, it got pointed out this name conflicts with SRP =20 > (Securer Remote Password) in the security context. Could folks =20 > propose some other name for the WG be early next week. Someone suggested "memorex", which was good. But if "memorex" is infringing on a possible trademark, how about yaad - Yet Another Acoustic Diverter Plus, "yaad" is a Hindi word for "memory". Ciao, - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From lorenzo@meetecho.com Thu Feb 11 06:54:52 2010 Return-Path: <lorenzo@meetecho.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391A328C1C0 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQjksy2Uwy8t for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 06:54:51 -0800 (PST) Received: from smtp5.aruba.it (smtpd3.aruba.it [62.149.128.208]) by core3.amsl.com (Postfix) with SMTP id B7F9328C1BE for <dispatch@ietf.org>; Thu, 11 Feb 2010 06:54:50 -0800 (PST) Received: (qmail 31478 invoked by uid 89); 11 Feb 2010 14:56:01 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.172) by smtp5.ad.aruba.it with SMTP; 11 Feb 2010 14:56:01 -0000 Date: Thu, 11 Feb 2010 15:54:51 +0100 From: Lorenzo Miniero <lorenzo@meetecho.com> To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com> Message-Id: <20100211155451.89a65bba.lorenzo@meetecho.com> In-Reply-To: <4B741742.4090906@alcatel-lucent.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <20100211100511.ntvswphl440kgogg@webmail.unina.it> <4B741742.4090906@alcatel-lucent.com> Organization: Meetecho X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 14:54:52 -0000 SINARP (Sinarp Is Not A Recording Protocol) L. On Thu, 11 Feb 2010 08:42:10 -0600 "Vijay K. Gurbani" <vkg@alcatel-lucent.com> wrote: > tobia.castaldi@unina.it wrote: > Cullen Jennings <fluffy@cisco.com> wrote: > > > > In IESG review, it got pointed out this name conflicts with SRP > > (Securer Remote Password) in the security context. Could folks > > propose some other name for the WG be early next week. > > Someone suggested "memorex", which was good. But if "memorex" > is infringing on a possible trademark, how about > > yaad - Yet Another Acoustic Diverter > > Plus, "yaad" is a Hindi word for "memory". > > Ciao, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Lorenzo Miniero Meetecho s.r.l. http://www.meetecho.com/ From steve.logalbo@cybertech-na.com Thu Feb 11 07:01:25 2010 Return-Path: <steve.logalbo@cybertech-na.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A583A755A for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1II4dx6EImJ3 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:01:24 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 714EC3A73A5 for <dispatch@ietf.org>; Thu, 11 Feb 2010 07:01:24 -0800 (PST) Received: from source ([96.57.220.202]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS3QcDnvPz0zRj2LB4EPxoTPIGXF9SqY6@postini.com; Thu, 11 Feb 2010 07:02:39 PST Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 09:58:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <30DCAC26D8996F47881979D00DF30B556F1C69@avoxsrv001.avoxsolutions.local> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37DAC84527@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrKIWnMPyeO3GvTW6wutffvZHJ2gAAcVlQAAAO20A= References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><20100211100511.ntvswphl440kgogg@webmail.unina.it><4B741742.4090906@alcatel-lucent.com> <07465C1D981ABC41A344374066AE1A2C37DAC84527@TLVMBX01.nice.com> From: "Steven LoGalbo" <steve.logalbo@cybertech-na.com> To: "Leon Portman" <Leon.Portman@nice.com>, "Cullen Jennings" <fluffy@cisco.com> Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 15:01:25 -0000 I like where you are going. How about UCR / UMR- Unified Communication Recording / Unified Media Recording Regards, Steve LoGalbo steve.logalbo@cybertech-na.com 914-269-4099 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Leon Portman Sent: Thursday, February 11, 2010 9:56 AM To: Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG Another option: RUM - Recording of Unified Media Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: Thursday, February 11, 2010 4:42 PM To: Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG tobia.castaldi@unina.it wrote: Cullen Jennings <fluffy@cisco.com> wrote: > > In IESG review, it got pointed out this name conflicts with SRP =20 > (Securer Remote Password) in the security context. Could folks =20 > propose some other name for the WG be early next week. Someone suggested "memorex", which was good. But if "memorex" is infringing on a possible trademark, how about yaad - Yet Another Acoustic Diverter Plus, "yaad" is a Hindi word for "memory". Ciao, - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From rajnish.jain@ipc.com Thu Feb 11 07:05:09 2010 Return-Path: <rajnish.jain@ipc.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6C43A7317 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAqbMq+N3vFm for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:05:07 -0800 (PST) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by core3.amsl.com (Postfix) with ESMTP id 5221D3A6BFC for <dispatch@ietf.org>; Thu, 11 Feb 2010 07:05:07 -0800 (PST) Received: from unknown [65.244.37.51] (EHLO p01c12o141.mxlogic.net) by p01c12o141.mxlogic.net(mxl_mta-6.5.0-0) with ESMTP id eec147b4.ca1e0b90.7758.00-456.15609.p01c12o141.mxlogic.net (envelope-from <rajnish.jain@ipc.com>); Thu, 11 Feb 2010 08:06:22 -0700 (MST) X-MXL-Hash: 4b741cee733f421b-60e58a97953b77bc4e829fd80aa34cd467264075 Received: from unknown [65.244.37.51] (EHLO smtp.ipc.com) by p01c12o141.mxlogic.net(mxl_mta-6.5.0-0) over TLS secured channel with ESMTP id 2ec147b4.0.7680.00-001.15438.p01c12o141.mxlogic.net (envelope-from <rajnish.jain@ipc.com>); Thu, 11 Feb 2010 08:06:11 -0700 (MST) X-MXL-Hash: 4b741ce348078d2f-33fd95f792de329a1d18cccb09ed0f8276d17ec8 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.247]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Thu, 11 Feb 2010 10:06:08 -0500 From: "Jain, Rajnish" <Rajnish.Jain@ipc.com> To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>, Cullen Jennings <fluffy@cisco.com> Date: Thu, 11 Feb 2010 10:06:08 -0500 Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrKHzxzuhCY9clR4aCkPV5EKN26AAAzqYg Message-ID: <A549831415082442872141F4C99FE71301EDE029CA@STSNYCMS1.corp.root.ipc.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <20100211100511.ntvswphl440kgogg@webmail.unina.it> <4B741742.4090906@alcatel-lucent.com> In-Reply-To: <4B741742.4090906@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.000.1038-17186.004 x-tm-as-result: No--53.007400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: <rajnish.jain@ipc.com> X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=Z7DLnp2nHscA:10 a=z+2a4RCZxltofrpCDsS06w==:17 ] X-AnalysisOut: [a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=N54-gffFAAAA:8 a=C3I3Z] X-AnalysisOut: [F1iAAAA:8 a=rd_hZMwNXrk22cojUFoA:9 a=dN5xE2ZXPxXsCRuOptoA:] X-AnalysisOut: [7 a=ymgC32FKRmmu-gnHOwoQYO5xWgQA:4 a=lZB815dzVvQA:10 a=JfD] X-AnalysisOut: [0Fch1gWkA:10 a=3FZX-ydVlcEA:10 a=sK9FX98U6w4A:10 a=nAPXUAf] X-AnalysisOut: [sBmEA:10 a=rqG4ekC26VvGd3YA:21 a=MTrsdWacp3D4OxbQ:21] Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 15:05:09 -0000 What happened to the goal of naming RAI WGs after alcohols? :-) Margarita - MediA RecordinG And Replay In The internet Architecture > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf > Of Vijay K. Gurbani > Sent: Thursday, February 11, 2010 9:42 AM > To: Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG > > tobia.castaldi@unina.it wrote: > Cullen Jennings <fluffy@cisco.com> wrote: > > > > In IESG review, it got pointed out this name conflicts with SRP > > (Securer Remote Password) in the security context. Could folks > > propose some other name for the WG be early next week. > > Someone suggested "memorex", which was good. But if "memorex" > is infringing on a possible trademark, how about > > yaad - Yet Another Acoustic Diverter > > Plus, "yaad" is a Hindi word for "memory". > > Ciao, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From steve.logalbo@cybertech-na.com Thu Feb 11 07:24:23 2010 Return-Path: <steve.logalbo@cybertech-na.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B9A3A67F0 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izx4YPpNaHHO for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:24:22 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id EA0823A70A0 for <dispatch@ietf.org>; Thu, 11 Feb 2010 07:24:21 -0800 (PST) Received: from source ([96.57.220.202]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS3QhcE1t+8JHrMj3ln+KNfTQ5LfQzk2v@postini.com; Thu, 11 Feb 2010 07:25:37 PST Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 10:21:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <30DCAC26D8996F47881979D00DF30B556F1C75@avoxsrv001.avoxsolutions.local> In-Reply-To: <A549831415082442872141F4C99FE71301EDE029CA@STSNYCMS1.corp.root.ipc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrKHzxzuhCY9clR4aCkPV5EKN26AAAzqYgAACF3fA= References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><20100211100511.ntvswphl440kgogg@webmail.unina.it><4B741742.4090906@alcatel-lucent.com> <A549831415082442872141F4C99FE71301EDE029CA@STSNYCMS1.corp.root.ipc.com> From: "Steven LoGalbo" <steve.logalbo@cybertech-na.com> To: "Jain, Rajnish" <Rajnish.Jain@ipc.com>, "Vijay K. Gurbani" <vkg@alcatel-lucent.com>, "Cullen Jennings" <fluffy@cisco.com> Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 15:24:23 -0000 DRUNK - Dynamic Recording of UNified Kommunications... Regards, Steve LoGalbo steve.logalbo@cybertech-na.com 914-269-4099 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Jain, Rajnish Sent: Thursday, February 11, 2010 10:06 AM To: Vijay K. Gurbani; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG What happened to the goal of naming RAI WGs after alcohols? :-) Margarita - MediA RecordinG And Replay In The internet Architecture > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Vijay K. Gurbani > Sent: Thursday, February 11, 2010 9:42 AM > To: Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG > > tobia.castaldi@unina.it wrote: > Cullen Jennings <fluffy@cisco.com> wrote: > > > > In IESG review, it got pointed out this name conflicts with SRP > > (Securer Remote Password) in the security context. Could folks > > propose some other name for the WG be early next week. > > Someone suggested "memorex", which was good. But if "memorex" > is infringing on a possible trademark, how about > > yaad - Yet Another Acoustic Diverter > > Plus, "yaad" is a Hindi word for "memory". > > Ciao, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Leon.Portman@nice.com Thu Feb 11 07:31:09 2010 Return-Path: <Leon.Portman@nice.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BAA43A6F88 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV+Hh-DPlUwC for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 07:31:08 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 8BFC43A6ED9 for <dispatch@ietf.org>; Thu, 11 Feb 2010 07:31:07 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 11 Feb 2010 17:32:19 +0200 From: Leon Portman <Leon.Portman@nice.com> To: Steven LoGalbo <steve.logalbo@cybertech-na.com>, "Jain, Rajnish" <Rajnish.Jain@ipc.com>, "Vijay K. Gurbani" <vkg@alcatel-lucent.com>, Cullen Jennings <fluffy@cisco.com> Date: Thu, 11 Feb 2010 17:32:17 +0200 Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrKHzxzuhCY9clR4aCkPV5EKN26AAAzqYgAACF3fAAAGSxoA== Message-ID: <07465C1D981ABC41A344374066AE1A2C37DAC84546@TLVMBX01.nice.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><20100211100511.ntvswphl440kgogg@webmail.unina.it><4B741742.4090906@alcatel-lucent.com> <A549831415082442872141F4C99FE71301EDE029CA@STSNYCMS1.corp.root.ipc.com> <30DCAC26D8996F47881979D00DF30B556F1C75@avoxsrv001.avoxsolutions.local> In-Reply-To: <30DCAC26D8996F47881979D00DF30B556F1C75@avoxsrv001.avoxsolutions.local> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 15:31:09 -0000 Good one Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Steven LoGalbo Sent: Thursday, February 11, 2010 5:22 PM To: Jain, Rajnish; Vijay K. Gurbani; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG DRUNK - Dynamic Recording of UNified Kommunications... Regards, Steve LoGalbo steve.logalbo@cybertech-na.com 914-269-4099 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Jain, Rajnish Sent: Thursday, February 11, 2010 10:06 AM To: Vijay K. Gurbani; Cullen Jennings Cc: DISPATCH Subject: Re: [dispatch] Name for Session Recording WG What happened to the goal of naming RAI WGs after alcohols? :-) Margarita - MediA RecordinG And Replay In The internet Architecture > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Vijay K. Gurbani > Sent: Thursday, February 11, 2010 9:42 AM > To: Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG > > tobia.castaldi@unina.it wrote: > Cullen Jennings <fluffy@cisco.com> wrote: > > > > In IESG review, it got pointed out this name conflicts with SRP > > (Securer Remote Password) in the security context. Could folks > > propose some other name for the WG be early next week. > > Someone suggested "memorex", which was good. But if "memorex" > is infringing on a possible trademark, how about > > yaad - Yet Another Acoustic Diverter > > Plus, "yaad" is a Hindi word for "memory". > > Ciao, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From spromano@unina.it Thu Feb 11 09:03:26 2010 Return-Path: <spromano@unina.it> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD5F28C124 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 09:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaYrzNdkdPhK for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 09:03:26 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id A82F828C174 for <dispatch@ietf.org>; Thu, 11 Feb 2010 09:03:25 -0800 (PST) Received: from [192.168.1.238] (host77-83-dynamic.3-79-r.retail.telecomitalia.it [79.3.83.77]) (authenticated bits=0) by smtp1.unina.it (8.14.0/8.14.0) with ESMTP id o1BH3Z58025011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Feb 2010 18:03:36 +0100 References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><1265891767.20274.315.camel@scott.home.skrb.org> <FF84A09F50A6DC48ACB6714F4666CC743F2534A3D2@ESESSCMS0354.eemea.ericsson.se> <30DCAC26D8996F47881979D00DF30B556F1C4E@avoxsrv001.avoxsolutions.local> <101C6067BEC68246B0C3F6843BCCC1E306EEB592B6@MCHP058A.global-ad.net> Message-Id: <4392A174-8236-45F7-A267-F7ADD6923D13@unina.it> From: Simon Pietro Romano <spromano@unina.it> To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E306EEB592B6@MCHP058A.global-ad.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Thu, 11 Feb 2010 18:03:56 +0100 X-Virus-Scanned: ClamAV 0.94/10380/Thu Feb 11 16:45:56 2010 on smtp1.unina.it X-Virus-Status: Clean Cc: DISPATCH <dispatch@ietf.org>, Scott Lawrence <scottlawrenc@avaya.com> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 17:03:26 -0000 RESCUE -- REcording Sessions among inter-Communicating User Equipment Simon Il giorno 11/feb/2010, alle ore 15.07, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com > ha scritto: > > I quite like SRIP but I don't think we should call it a protocol. > > I suggest "Media Recording using the Session Initiation Protocol" or > "MRSIP". > > Regards > Andy > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On Behalf Of Steven LoGalbo > Sent: 11 February 2010 13:57 > To: Christer Holmberg; Scott Lawrence; Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG > > SRIP - Session Recording Initiation Protocol > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Thursday, February 11, 2010 7:40 AM > To: Scott Lawrence; Cullen Jennings > Cc: DISPATCH > Subject: Re: [dispatch] Name for Session Recording WG > > > Intermediate Media Storage (IMS) > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence >> Sent: 11. helmikuuta 2010 14:36 >> To: Cullen Jennings >> Cc: DISPATCH >> Subject: Re: [dispatch] Name for Session Recording WG >> >> On Wed, 2010-02-10 at 14:29 -0700, Cullen Jennings wrote: >>> In IESG review, it got pointed out this name conflicts with SRP >>> (Securer Remote Password) in the security context. Could >> folks propose >>> some other name for the WG be early next week. >> >> Unified Session Archival In Datastore (USAID) >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Thu Feb 11 11:17:38 2010 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7A028C221 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 11:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPETQs4-Zgo0 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 11:17:37 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EB8603A720C for <dispatch@ietf.org>; Thu, 11 Feb 2010 11:17:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,453,1262581200"; d="scan'208";a="176113331" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Feb 2010 14:18:50 -0500 X-IronPort-AV: E=Sophos;i="4.49,453,1262581200"; d="scan'208";a="444870675" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Feb 2010 14:18:49 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1BJISt29333; Thu, 11 Feb 2010 19:18:28 GMT Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o1BJIPC15588; Thu, 11 Feb 2010 19:18:26 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 14:18:25 -0500 From: "Dale Worley" <dworley@avaya.com> To: Lorenzo Miniero <lorenzo@meetecho.com> In-Reply-To: <20100211134326.72878615.lorenzo@meetecho.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <4B733825.6010707@nostrum.com> <20100211134326.72878615.lorenzo@meetecho.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 11 Feb 2010 14:18:24 -0500 Message-Id: <1265915904.3763.16.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2010 19:18:25.0565 (UTC) FILETIME=[FBE94CD0:01CAAB4E] Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 19:17:38 -0000 On Thu, 2010-02-11 at 13:43 +0100, Lorenzo Miniero wrote: > I like this name, and the fact there's a metal band with the same name > is totally irrelevant! ;) Artist: The Bobs Song: Naming The Band ------------------------------------------------------------------------------ (c) 1989 Richard Greene, Gunnar Madsen and Joe Finetti, Best of Breed Music (ASCAP) All Rights Reserved. Used by Permission. ------------------------------------------------------------------------------ My parents were wrong, they named me "tree" It's probably the cruelest thing they ever did to me I thought a long time about changing my name But I found a better way to deal with my shame My buddies and me formed a band We're gonna be famous, you understand We're lookin' for a drummer Or someone with a van Our hair is getting longer But the most important thing is namin' the band Namin' the band ... From jmpolk@cisco.com Thu Feb 11 11:34:10 2010 Return-Path: <jmpolk@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3F828C117 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 11:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTl+AGNyRa2P for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 11:34:10 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0250B3A720C for <dispatch@ietf.org>; Thu, 11 Feb 2010 11:34:10 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,454,1262563200"; d="scan'208";a="87054009" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2010 19:35:25 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o1BJZO7s020118; Thu, 11 Feb 2010 19:35:25 GMT Message-Id: <201002111935.o1BJZO7s020118@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Feb 2010 13:35:24 -0600 To: Cullen Jennings <fluffy@cisco.com>, DISPATCH <dispatch@ietf.org> From: "James M. Polk" <jmpolk@cisco.com> In-Reply-To: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 19:34:11 -0000 At 03:29 PM 2/10/2010, Cullen Jennings wrote: >In IESG review, it got pointed out this name conflicts with SRP >(Securer Remote Password) in the security context. Could folks >propose some other name for the WG be early next week. what about yomomma - Yet anOther Memory archive fOr MultiMediA James >Thanks, Cullen > > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From vkg@alcatel-lucent.com Thu Feb 11 11:53:44 2010 Return-Path: <vkg@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4043A720C for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 11:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVRnao5Z1E9N for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 11:53:43 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 13E933A7087 for <dispatch@ietf.org>; Thu, 11 Feb 2010 11:53:42 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o1BJsYps002043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 13:54:34 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o1BJsYSo014343; Thu, 11 Feb 2010 13:54:34 -0600 (CST) Message-ID: <4B746079.90701@alcatel-lucent.com> Date: Thu, 11 Feb 2010 13:54:33 -0600 From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com> Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <201002111935.o1BJZO7s020118@sj-core-4.cisco.com> In-Reply-To: <201002111935.o1BJZO7s020118@sj-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 19:53:44 -0000 Cullen: Now that the world has proof-positive of the unbounded intellect of DISPATCHers in conjuring up creative acronyms at short notice, here is a list of entrants so far. Your executive decision now is to pick one of these or come up with a new one of your own choosing. The guilty party of each acronym is clearly identified for recrimination (or renumeration) at some later time. MARE - Multimedia Assets REcording (Tobia Castaldi) Note: Italian word for "sea" USAID - Unified Session Archival In Datastore (Scott Lawrence) IMS - Intermediate Media Storage (Christer Holmberg) NEVERMORE - Network Enabled diVERsion of Multimedia On Recording Equipment (Adam Roach) RECON - recording control (Leon Portman) REX - recording extensions (Leon Portman) INTER - Interactions Recording (Leon Portman) MMREC - multimedia recording (Leon Portman) RUM - Recording of Unified Media (Leon Portman) Note: Following the tradition of naming after alcohols. SRIP - Session Recording Initiation Protocol (Steve LoGalbo) SRI - Session Recording Interface? (Steve LoGalbo) IPSR - IP Session Recording? (Steve LoGalbo) UCR / UMR - Unified Communication Recording / Unified Media Recording (Steve LoGalbo) DRUNK - Dynamic Recording of UNified Kommunications (Steve LoGalbo) Note: Following the tradition of naming after alcohols. MRSIP - Media Recording using the Session Initiation Protocol (Andrew Hutton) YAAD - Yet Another Acoustic Diverter (Vijay K. Gurbani) Note: Hindi word for "memory". SINARP - Sinarp Is Not A Recording Protocol (Lorenzo Miniero) MARGARITA - MediA RecordinG And Replay In The internet Architecture (Rajnish Jain) Note: Following the tradition of naming after alcohols. YOMOMMA - Yet anOther Memory archive fOr MultiMediA (James Polk) - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From jmpolk@cisco.com Thu Feb 11 15:52:02 2010 Return-Path: <jmpolk@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90353A75E7 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 15:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-K96xQiC2JG for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 15:52:01 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ACFE73A7289 for <dispatch@ietf.org>; Thu, 11 Feb 2010 15:52:01 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,455,1262563200"; d="scan'208";a="481905748" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 11 Feb 2010 23:53:18 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1BNrHpT012174; Thu, 11 Feb 2010 23:53:17 GMT Message-Id: <201002112353.o1BNrHpT012174@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Feb 2010 17:53:16 -0600 To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>, Cullen Jennings <fluffy@cisco.com> From: "James M. Polk" <jmpolk@cisco.com> In-Reply-To: <4B746079.90701@alcatel-lucent.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <201002111935.o1BJZO7s020118@sj-core-4.cisco.com> <4B746079.90701@alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 23:52:02 -0000 At 01:54 PM 2/11/2010, Vijay K. Gurbani wrote: >Cullen: Now that the world has proof-positive of the >unbounded intellect of DISPATCHers in conjuring >up creative acronyms at short notice, here is a list of >entrants so far. Your executive decision now is to >pick one of these or come up with a new one of your >own choosing. > >The guilty party of each acronym is clearly identified >for recrimination (or renumeration) at some later time. > >MARE - Multimedia Assets REcording (Tobia Castaldi) > Note: Italian word for "sea" >USAID - Unified Session Archival In Datastore (Scott Lawrence) >IMS - Intermediate Media Storage (Christer Holmberg) >NEVERMORE - Network Enabled diVERsion of Multimedia On > Recording Equipment (Adam Roach) >RECON - recording control (Leon Portman) >REX - recording extensions (Leon Portman) >INTER - Interactions Recording (Leon Portman) >MMREC - multimedia recording (Leon Portman) >RUM - Recording of Unified Media (Leon Portman) > Note: Following the tradition of naming after alcohols. >SRIP - Session Recording Initiation Protocol (Steve LoGalbo) >SRI - Session Recording Interface? (Steve LoGalbo) >IPSR - IP Session Recording? (Steve LoGalbo) >UCR / UMR - Unified Communication Recording / Unified Media Recording > (Steve LoGalbo) >DRUNK - Dynamic Recording of UNified Kommunications (Steve LoGalbo) > Note: Following the tradition of naming after alcohols. >MRSIP - Media Recording using the Session Initiation Protocol > (Andrew Hutton) >YAAD - Yet Another Acoustic Diverter (Vijay K. Gurbani) > Note: Hindi word for "memory". >SINARP - Sinarp Is Not A Recording Protocol (Lorenzo Miniero) >MARGARITA - MediA RecordinG And Replay In The internet Architecture > (Rajnish Jain) > Note: Following the tradition of naming after alcohols. >YOMOMMA - Yet anOther Memory archive fOr MultiMediA (James Polk) this spelling also works... YOMAMMA - Yet anOther Memory Archive for MultiMediA (James Polk) I'm trying to come up with an explosion for HAMMERED, which would be really cool IMO >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) >Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >Web: http://ect.bell-labs.com/who/vkg/ >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Thu Feb 11 16:20:24 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05913A726B for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 16:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSLZbc64FTga for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 16:20:23 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AB0E23A6E05 for <dispatch@ietf.org>; Thu, 11 Feb 2010 16:20:23 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o1C0Lbe0028895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Feb 2010 18:21:38 -0600 Message-Id: <D070698A-22CE-4796-8ED1-E60228D0DDB4@softarmor.com> From: Dean Willis <dean.willis@softarmor.com> To: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Feb 2010 18:21:32 -0600 References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 12 Feb 2010 00:20:25 -0000 On Feb 10, 2010, at 3:29 PM, Cullen Jennings wrote: > > In IESG review, it got pointed out this name conflicts with SRP > (Securer Remote Password) in the security context. Could folks > propose some other name for the WG be early next week. > I like "SIPREC". It's kindof like "shipwreck", which is a good semantic match. -- Dean From fluffy@cisco.com Thu Feb 11 18:17:20 2010 Return-Path: <fluffy@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8683A6C7F for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 18:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-DYtdapTIqf for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 18:17:19 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 46FE43A6842 for <dispatch@ietf.org>; Thu, 11 Feb 2010 18:17:19 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK5IdEurR7Hu/2dsb2JhbACbAXSoEpduhFcEgxM X-IronPort-AV: E=Sophos;i="4.49,456,1262563200"; d="scan'208";a="150215927" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2010 02:18:35 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1C2IYxv024259; Fri, 12 Feb 2010 02:18:34 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <4B746079.90701@alcatel-lucent.com> Date: Thu, 11 Feb 2010 19:18:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C0BC95C-1C59-4EAB-B609-28EA7DF4EAC4@cisco.com> References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <201002111935.o1BJZO7s020118@sj-core-4.cisco.com> <4B746079.90701@alcatel-lucent.com> To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com> X-Mailer: Apple Mail (2.1077) Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 12 Feb 2010 02:17:20 -0000 Wow - I laughed when I read this. We really need a "best of the IETF" = mailing list. I have no clue what to do. Perhaps I can fob it off to = whoever NomCom chooses to replace me. I'll figure something out from = these. Thanks,=20 Cullen PS. I'll have to add to the list RAVEN - Recording Audio and Video Everywhere in the Network (Cullen) On Feb 11, 2010, at 12:54 PM, Vijay K. Gurbani wrote: > Cullen: Now that the world has proof-positive of the > unbounded intellect of DISPATCHers in conjuring > up creative acronyms at short notice, here is a list of > entrants so far. Your executive decision now is to > pick one of these or come up with a new one of your > own choosing. >=20 > The guilty party of each acronym is clearly identified > for recrimination (or renumeration) at some later time. >=20 > MARE - Multimedia Assets REcording (Tobia Castaldi) > Note: Italian word for "sea" > USAID - Unified Session Archival In Datastore (Scott Lawrence) > IMS - Intermediate Media Storage (Christer Holmberg) > NEVERMORE - Network Enabled diVERsion of Multimedia On > Recording Equipment (Adam Roach) > RECON - recording control (Leon Portman) > REX - recording extensions (Leon Portman) > INTER - Interactions Recording (Leon Portman) > MMREC - multimedia recording (Leon Portman) > RUM - Recording of Unified Media (Leon Portman) > Note: Following the tradition of naming after alcohols. > SRIP - Session Recording Initiation Protocol (Steve LoGalbo) > SRI - Session Recording Interface? (Steve LoGalbo) > IPSR - IP Session Recording? (Steve LoGalbo) > UCR / UMR - Unified Communication Recording / Unified Media Recording > (Steve LoGalbo) > DRUNK - Dynamic Recording of UNified Kommunications (Steve = LoGalbo) > Note: Following the tradition of naming after alcohols. > MRSIP - Media Recording using the Session Initiation Protocol > (Andrew Hutton) > YAAD - Yet Another Acoustic Diverter (Vijay K. Gurbani) > Note: Hindi word for "memory". > SINARP - Sinarp Is Not A Recording Protocol (Lorenzo Miniero) > MARGARITA - MediA RecordinG And Replay In The internet Architecture > (Rajnish Jain) > Note: Following the tradition of naming after alcohols. > YOMOMMA - Yet anOther Memory archive fOr MultiMediA (James Polk) >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dean.willis@softarmor.com Thu Feb 11 20:20:45 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B201828C156 for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 20:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys+JVTVeunWz for <dispatch@core3.amsl.com>; Thu, 11 Feb 2010 20:20:44 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 44B3D28C168 for <dispatch@ietf.org>; Thu, 11 Feb 2010 20:20:44 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o1C4LC79030038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Feb 2010 22:21:13 -0600 Message-Id: <D9FE5AC6-5FB9-442B-AE4E-44E77C94B4BA@softarmor.com> From: Dean Willis <dean.willis@softarmor.com> To: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <7C0BC95C-1C59-4EAB-B609-28EA7DF4EAC4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Feb 2010 22:21:07 -0600 References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com> <201002111935.o1BJZO7s020118@sj-core-4.cisco.com> <4B746079.90701@alcatel-lucent.com> <7C0BC95C-1C59-4EAB-B609-28EA7DF4EAC4@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 12 Feb 2010 04:20:45 -0000 On Feb 11, 2010, at 8:18 PM, Cullen Jennings wrote: > > Wow - I laughed when I read this. We really need a "best of the > IETF" mailing list. I have no clue what to do. Perhaps I can fob it > off to whoever NomCom chooses to replace me. I'll figure something > out from these. Thanks, > > Cullen > > PS. I'll have to add to the list > > RAVEN - Recording Audio and Video Everywhere in the Network (Cullen) > On further reflection, I have to support NEVERMORE, as a logical extension from RAVEN. From Poe: http://en.wikisource.org/wiki/The_Raven_(Poe) -- Dean From gonzalo.camarillo@ericsson.com Sat Feb 13 23:26:39 2010 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1280428C0E8 for <dispatch@core3.amsl.com>; Sat, 13 Feb 2010 23:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.072 X-Spam-Level: X-Spam-Status: No, score=-103.072 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IgASffGDDyD for <dispatch@core3.amsl.com>; Sat, 13 Feb 2010 23:26:38 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D7D1E28C108 for <dispatch@ietf.org>; Sat, 13 Feb 2010 23:26:37 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-94-4b77a60189a0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 9D.8F.02429.106A77B4; Sun, 14 Feb 2010 08:28:01 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Feb 2010 08:27:27 +0100 Received: from [131.160.126.165] ([131.160.126.165]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Feb 2010 08:27:26 +0100 Message-ID: <4B77A5DE.1010508@ericsson.com> Date: Sun, 14 Feb 2010 09:27:26 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH <dispatch@ietf.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050707060100020103080002" X-OriginalArrivalTime: 14 Feb 2010 07:27:26.0686 (UTC) FILETIME=[287A2FE0:01CAAD47] X-Brightmail-Tracker: AAAAAA== Cc: Mary Barnes <mbarnes@nortelnetworks.com> Subject: [dispatch] [Fwd: SIP OPTIONS rework proposal] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 14 Feb 2010 07:26:39 -0000 This is a multi-part message in MIME format. --------------050707060100020103080002 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, speaking as SIPCORE chair this time, the SIPCORE WG has received an agenda request to discuss this topic in Anaheim. Given that OPTIONS requests are specified in RFC 3261, it sounds reasonable for SIPCORE to have an initial look at what to do with this. So, if you have comments about this topic, you may want to discuss them on the SIPCORE list. Thanks, Gonzalo -------- Original Message -------- Subject: [dispatch] SIP OPTIONS rework proposal Date: Thu, 21 Jan 2010 15:31:36 +0100 From: Salvatore Loreto <salvatore.loreto@ericsson.com> To: dispatch@ietf.org <dispatch@ietf.org> Hi there, there as been a short discussion in SIP Core ml about the fact that the OPTIONS method to discovery capabilities is pretty broken. As discovery capabilities is a meaningful mechanism to provide enhanced services, it would be important, at least in my opinion, to do some serious rework on it! Below an initial description of the problem as derived from the exchange of mails with Paul. Comments are very welcome! Regards Sal ---------- OPTIONS as discovery capabilities mechanism ============================= The SIP method OPTIONS allows you to query the capabilities of another UA or a proxy server. The method provides a way to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party. The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. However SIP OPTIONS also inherits the "traceroute" behaviour from HTTP/1.1, where a server receiving an OPTIONS request with a Max-Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. So the original intent and design of OPTIONS seems to be that whoever responds to an OPTIONS method does it for itself. However in the case the request is addressed to an AoR, and there is a proxy responsible for that AoR (that will typically route requests via contact routing), it is not clear the right behaviour of the proxy. e.g. Alice sends a SIP OPTIONS request to discover the Bob capabilities; if Bob has registered two or more UAs, then the proxy responsible for the Bob AoR forks the OPTIONS request letting it arrive to all the registered UAs. A possible behavior for the proxy responsible for the Bob AoR may be to send back to Alice only the first response it receives. However this is just a possible behaviour, others are also possible or at least not prohibited! A nice thing to be able to learn, through a discovery capabilities mechanism, would be the full set of capabilities associated to the different UAs an user has registered and not just the capabilities of the UA that answers more quickly. The question is whether OPTIONS is the way to achieve it, or it would make more sense to leave OPTIONS alone and create something new. Moreover the assumption that the capabilities of a UA are stable over time and are context free is also pretty broken. UA capabilities can change for a lot of different reasons: a user switch off/on one of his registered UAs; or context changed than when the query has been received. For instance, if Bob's device is handling a call when it receives the query, does the response reflect what it can do concurrently with the call, or what it will be able to do once the call had ended? So the description of the context and of the reasons that can let capabilities to chance over time could provide useful pieces of information. --------------050707060100020103080002 Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ATT00001.txt" _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------050707060100020103080002-- From dromasca@avaya.com Sun Feb 14 07:29:03 2010 Return-Path: <dromasca@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8A93A703D for <dispatch@core3.amsl.com>; Sun, 14 Feb 2010 07:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wvGZ9yGhr+1 for <dispatch@core3.amsl.com>; Sun, 14 Feb 2010 07:29:03 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 8FC4D3A76DC for <dispatch@ietf.org>; Sun, 14 Feb 2010 07:29:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,472,1262581200"; d="scan'208";a="176390861" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Feb 2010 10:30:26 -0500 X-IronPort-AV: E=Sophos;i="4.49,472,1262581200"; d="scan'208";a="445641165" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Feb 2010 10:30:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Feb 2010 16:30:10 +0100 Message-ID: <EDC652A26FB23C4EB6384A4584434A0401F48EB3@307622ANEX5.global.avaya.com> In-Reply-To: <4B746079.90701@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Name for Session Recording WG Thread-Index: AcqrVBr7tXl/jAIfS8Kfr8dOHax3IQCNlsGw References: <C79F38A0-7397-4ED3-B014-5C2C0ECC9797@cisco.com><201002111935.o1BJZO7s020118@sj-core-4.cisco.com> <4B746079.90701@alcatel-lucent.com> From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>, "Cullen Jennings" <fluffy@cisco.com> Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Name for Session Recording WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 14 Feb 2010 15:29:04 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > YAAD - Yet Another Acoustic Diverter (Vijay K. Gurbani) > Note: Hindi word for "memory". .... and Hebrew for target / destination :-) From pkyzivat@cisco.com Sun Feb 14 12:58:12 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068CB3A7A66; Sun, 14 Feb 2010 12:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoBxt2IBKlIL; Sun, 14 Feb 2010 12:58:06 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9D06728C0CF; Sun, 14 Feb 2010 12:58:05 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGvyd0tAZnwN/2dsb2JhbACbHXSkJpZSgkYPggYEgxSLQQ X-IronPort-AV: E=Sophos;i="4.49,472,1262563200"; d="scan'208";a="86103538" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Feb 2010 20:59:32 +0000 Received: from [10.86.251.81] (bxb-vpn3-849.cisco.com [10.86.251.81]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1EKxW2r020153; Sun, 14 Feb 2010 20:59:32 GMT Message-ID: <4B786433.1060000@cisco.com> Date: Sun, 14 Feb 2010 15:59:31 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: IESG <iesg@ietf.org> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com> <4B72BE4A.6030508@ericsson.com> In-Reply-To: <4B72BE4A.6030508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mary Barnes <mbarnes@nortelnetworks.com>, "dispatch@ietf.org" <dispatch@ietf.org> Subject: [dispatch] Preliminary version of Expert review of draft-avasarala-dispatch-comm-div-notification-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 14 Feb 2010 20:58:12 -0000 I was requested to do an expert review of draft-avasarala-dispatch-comm-div-notification-03.txt Below I have reproduced the requirements from http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#section-4.1 and the referenced requirements from RFC 3265, and interleaved my comments to them. I did identify a number of issues - more than I expected to. Most arose from carefully checking compliance to 3265. I've tagged things that should specifically be fixed with ISSUE and NIT. Thanks, Paul > 1. A Designated Expert (as defined in RFC5226) must review the > proposal for applicability to SIP and conformance with these > guidelines. The Designated Expert will send email to the IESG on > this determination. The expert reviewer can cite one or more of > the guidelines that have not been followed in his/her opinion. I'm doing that below. > 2. The proposed extension MUST NOT define an event template-package. It does not. > 3. The function of the proposed package MUST NOT overlap with > current or planned chartered packages. I am aware of no chartered work on this subject. The draft itself has been debated at length on the dispatch wg mailing list, but with a relatively small number of people actively involved. Some, including me, have stated that a service resembling the one proposed might be of general utility. But there have been no volunteers to do the work of generalizing this. So I conclude that there are currently no plans for chartered work on such a package. > 4. The event package MUST NOT redefine or contradict the normative > behavior of SIP events [RFC3265], SIP [RFC3261], or related > standards track extensions. (See Section 4) I did not identify any issues in this regard. > 5. The proposed package MUST NOT undermine SIP security in any > sense. The Internet Draft proposing the new package MUST address > security issues in detail as if it were a Standards Track > document. Security issues need to be discussed for arbitrary > usage scenarios (including the general Internet case). The document identifies the specific security issues presented by this package. It specifies that authentication and authorization must be done, but leaves the means for authorization out of scope. While a bit thin, this may be sufficient for the area of applicability. > 6. The proposed package MUST be clearly documented in an > (Individual) Informational RFC, and registered with IANA. The document under review will satisfy this requirement. > The package MUST document all the package considerations required > in Section 5 of SIP events [RFC3265]. (I believe this guideline has an incorrect reference, and should reference section *4* of 3265. I'm treating it that way.) > 4.1. Appropriateness of Usage In my opinion this is an entirely appropriate use of sip and event packages. > 4.2. Event Template-packages N/A - template package not defined. > 4.3. Amount of State to be Conveyed > 4.3.1. Complete State Information > 4.3.2. State Deltas ISSUE: The document details the notification body, and some inferences can be drawn about the state from the syntax of the notification body. But this is tenuous. There should be an explicit specification of the state maintained, and how it is mapped onto the notification body. > 4.4. Event Package Responsibilities > 4.4.1. Event Package Name OK. > 4.4.2. Event Package Parameters ISSUE: There is a section for this, but it repeats the description of the event package name rather than specifying the (lack of) event parameters. This seems to be a simple oversight/typo, but needs to be corrected. > 4.4.3. SUBSCRIBE Bodies The document specifies that a body MAY be present. It then documents the semantics when such body is of type "application/comm-div-info+xml". ISSUE: The subscribe body is intended to be used as a filter on which events/state are reported. The subscribe body contains data to be used in the filtering process, but the decision process for filtering is not specified. For instance, both a User-name and a User-URI may be provided. It is implied, rather than stated, that the User-name field is matched against the user portion of some URI, whereas the User-URI field is matched against a complete URI. Also, there are a variety of field types, and no indication how matches of multiple fields are combined. (I.e. AND or OR.) Its possible that all of that is defined by the CDIV service in some IMS document. If so, rather than a generic reference, there should be explicit references to that to define where this sort of semantic is defined. ISSUE: The document is a bit confusing because the same MIME-type and XML syntax are used for the subscribe body and the notify body. Yet there are specific portions of this syntax specific to subscriber bodies and notify bodies. For instance it isn't clear if the filter information given in a subscribe body is to be replayed in the notification body. Nor is there any specification of what should happen if notifier information is present in the subscribe body. ISSUE?: Semantics not specified if a body of some other type is present. This provides an unspecified extensibility hook that could be employed without any revision to the documented behavior of the package. I'm uncertain if this is appropriate or not. > 4.4.4. Subscription Duration > > It is RECOMMENDED that event packages give a suggested range of times > considered reasonable for the duration of a subscription. Such > packages MUST also define a default "Expires" value to be used if > none is specified. No suggested or default value is given, nor is any reason given for not suggesting a value. Text puts this to the discretion of the subscriber. ISSUE: The document needs to be revised to provide a default value. ISSUE: It also needs to either: - provide a suggested value, or - give a rationale for why a suggested value is not given > 4.4.5. NOTIFY Bodies Syntax is well specified. Semantics is barely specified. NIT: diversion-time-info does not specify a time zone, nor does it state that it is in some specific zone such as UTC. This makes it difficult for the subscriber to interpret. Perhaps not important if the notification is delivered when the diversion occurs. But if an initial subscribe can report a diversion that occurred in the past it could be a problem. (Perhaps this is a typo - earlier specifications of time include the zone. But the example shows usage without a zone.) DISCLAIMER: I'm not qualified to verify the correctness of the XML schema definition or the XML example. > 4.4.6. Notifier processing of SUBSCRIBE requests Nominal but perhaps sufficient. > 4.4.7. Notifier generation of NOTIFY requests > > This section of an event package describes the process by which the > notifier generates and sends a NOTIFY request. This includes > detailed information about what events cause a NOTIFY to be sent, This is covered. > how to compute the state information in the NOTIFY, ISSUE: The sending of events is not tied directly to the state of the resource. ISSUE: Questionable. Document says that the NOTIFY *MAY* contain a body. But doesn't specify when it does and when it doesn't. > how to generate > neutral or fake state information to hide authorization delays and > decisions from users, and whether state information is complete or > deltas for notifications; see section 4.3. Such a section is > required. ISSUE: The distinction between complete and delta state information is not addressed, and is ambiguous. Its unclear whether a history of prior diversions is retained and delivered, or if the state consists solely of a diversion as it is happening, that then immediately disappears from state after the notification. > 4.4.8. Subscriber processing of NOTIFY requests ISSUE: This section is very thin - it specifies nothing. Perhaps there are no requirements in this regard. If the state were better specified, then this section would probably specify how the state is reconstructed based on the notifications. > 4.4.9. Handling of forked requests OK, not permitted. > 4.4.10. Rate of notifications OK - specified. > 4.4.11. State Agents OK - not required or expected. > 4.4.12. Examples ISSUE: The only provided example is a sample of a notification body. Flow diagrams and message detail, as called out in 3265, would be very useful. NIT: Section 8.2 is entitled "Sample Notification Body", but it contains subsections entitled "Instance of communication diversion subscription document" and "Instance of communication diversion notification document". While the latter would be a notification body, the former would presumably be a subscription body. I'll observe that the examples suggest that comm-div-subs-info from the subscribe body is *not* replayed in the notify body. But there is no normative information about that. > 4.4.13. Use of URIs to Retrieve State OK - not used. > 7. If determined by the Designated Expert or the chairs or ADs of > the DISPATCH WG, an applicability statement in the Informational > RFC MUST clearly document the useful scope of the proposal, and > explain its limitations and why it is not suitable for the > general use of SIP in the Internet. The Applicability Statement in the document adequately documents the scope. ISSUE?: It doesn't explain the limitations, or why the package hasn't been designed for more general use. From fluffy@cisco.com Thu Feb 18 12:55:35 2010 Return-Path: <fluffy@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027053A7FE9 for <dispatch@core3.amsl.com>; Thu, 18 Feb 2010 12:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.461 X-Spam-Level: X-Spam-Status: No, score=-110.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyKz-UpGICzm for <dispatch@core3.amsl.com>; Thu, 18 Feb 2010 12:55:34 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 490E03A7D8D for <dispatch@ietf.org>; Thu, 18 Feb 2010 12:55:34 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOM4fUurR7Hu/2dsb2JhbACbCHSlSpgDhGcEgxU X-IronPort-AV: E=Sophos;i="4.49,499,1262563200"; d="scan'208";a="485141329" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 18 Feb 2010 20:57:18 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1IKvHRV025063 for <dispatch@ietf.org>; Thu, 18 Feb 2010 20:57:18 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Thu, 18 Feb 2010 13:57:17 -0700 Message-Id: <4BD4EEAD-1A52-4C50-9851-C323D24D91C4@cisco.com> To: DISPATCH <dispatch@ietf.org> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [dispatch] FYI on sip recording WG chartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 20:55:35 -0000 This charter got approved to go out for IETF LC so that should happen = some time next week. Cullen Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From keith.drage@alcatel-lucent.com Fri Feb 19 04:12:22 2010 Return-Path: <keith.drage@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CA028C254 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 04:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-1.376, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzAoesPYCuA0 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 04:12:19 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 72F2928C246 for <dispatch@ietf.org>; Fri, 19 Feb 2010 04:12:15 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1JCDxC8029609 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dispatch@ietf.org>; Fri, 19 Feb 2010 13:13:59 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 19 Feb 2010 13:13:59 +0100 From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To: DISPATCH <dispatch@ietf.org> Date: Fri, 19 Feb 2010 13:13:58 +0100 Thread-Topic: Comment on draft-liess-dispatch-alert-info-urns-00 Thread-Index: AcqxXDaNCfTHOVS7R+Cnyhx8ab2pSQ== Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20B014C31@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 12:12:22 -0000 I was looking for the information on how this changed the Alert-Info header= field usage from RFC 3261 and did not find it. RFC 3261 defines the usage of this header field only for INVITE requests. While this draft gives examples, and therefore implies it is valid for some= responses, it is not clear whether that extension now extends beyond INVIT= E, is all INVITE responses, or is limited to 180 responses. Could we have s= ome more normative type statements in this regard. Oh, and I'd actually like to know what the answer is! regards Keith From L.Liess@telekom.de Fri Feb 19 05:55:00 2010 Return-Path: <L.Liess@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17AA3A7CBC for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 05:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECFCXgUTP-Zi for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 05:55:00 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 6FDC83A7C92 for <dispatch@ietf.org>; Fri, 19 Feb 2010 05:54:59 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 19 Feb 2010 14:56:40 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 14:56:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Feb 2010 14:56:39 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003FCB1E8@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20B014C31@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 thread-index: AcqxXDaNCfTHOVS7R+Cnyhx8ab2pSQACUMvw References: <EDC0A1AE77C57744B664A310A0B23AE20B014C31@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: <L.Liess@telekom.de> To: <keith.drage@alcatel-lucent.com>, <dispatch@ietf.org> X-OriginalArrivalTime: 19 Feb 2010 13:56:40.0516 (UTC) FILETIME=[5C829840:01CAB16B] Subject: Re: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 13:55:00 -0000 Hi Keith,=20 We are just working on a new version of the draft. There are some inconsistencies in the 00 version.=20 The draft just should define additional identifiers which can be sent in the Alert-Info header. It does not change the header usage.=20 I hope things will be more clear in the new version. E.g. all "busy"- stuff was deleted. We also distinguish between ring tones and ringback tones and state that ring tones can be sent only in INVITE , while ringback tones can be sent only in 180-ringing.=20 Kind regards Laura =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Friday, February 19, 2010 1:14 PM > To: DISPATCH > Subject: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 >=20 > I was looking for the information on how this changed the=20 > Alert-Info header field usage from RFC 3261 and did not find it. >=20 > RFC 3261 defines the usage of this header field only for=20 > INVITE requests. >=20 > While this draft gives examples, and therefore implies it is=20 > valid for some responses, it is not clear whether that=20 > extension now extends beyond INVITE, is all INVITE responses,=20 > or is limited to 180 responses. Could we have some more=20 > normative type statements in this regard. >=20 > Oh, and I'd actually like to know what the answer is! >=20 > regards >=20 > Keith >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From keith.drage@alcatel-lucent.com Fri Feb 19 06:05:13 2010 Return-Path: <keith.drage@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE5A28C24C for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 06:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.453 X-Spam-Level: X-Spam-Status: No, score=-5.453 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO6q3ZPKdx-E for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 06:05:11 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7A75328C1F7 for <dispatch@ietf.org>; Fri, 19 Feb 2010 06:05:11 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1JE6lP9027716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Feb 2010 15:06:56 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 19 Feb 2010 15:06:55 +0100 From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To: "L.Liess@telekom.de" <L.Liess@telekom.de>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Fri, 19 Feb 2010 15:06:55 +0100 Thread-Topic: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 Thread-Index: AcqxXDaNCfTHOVS7R+Cnyhx8ab2pSQACUMvwAAGtHEA= Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20B014C82@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <EDC0A1AE77C57744B664A310A0B23AE20B014C31@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <40FB0FFB97588246A1BEFB05759DC8A003FCB1E8@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003FCB1E8@S4DE9JSAANI.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 14:05:13 -0000 So the header usage in RFC 3261 is INVITE requests and 180 responses to INV= ITE requests only. That remains the case? Perhaps a single informative stat= ement regarding the header field usage is unchanged from RFC 3261 might be = appropriate, unless that is already covered elsewhere (I have not done a li= ne by line scan). regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of L.Liess@telekom.de > Sent: Friday, February 19, 2010 1:57 PM > To: DRAGE, Keith (Keith); dispatch@ietf.org > Subject: Re: [dispatch] Comment on=20 > draft-liess-dispatch-alert-info-urns-00 >=20 > Hi Keith,=20 >=20 > We are just working on a new version of the draft. There are=20 > some inconsistencies in the 00 version.=20 > The draft just should define additional identifiers which can=20 > be sent in the Alert-Info header. It does not change the=20 > header usage.=20 >=20 > I hope things will be more clear in the new version. E.g. all=20 > "busy"- stuff was deleted. We also distinguish between ring=20 > tones and ringback tones and state that ring tones can be=20 > sent only in INVITE , while ringback tones can be sent only=20 > in 180-ringing.=20 >=20 > Kind regards > Laura =20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > > Sent: Friday, February 19, 2010 1:14 PM > > To: DISPATCH > > Subject: [dispatch] Comment on=20 > draft-liess-dispatch-alert-info-urns-00 > >=20 > > I was looking for the information on how this changed the=20 > Alert-Info=20 > > header field usage from RFC 3261 and did not find it. > >=20 > > RFC 3261 defines the usage of this header field only for INVITE=20 > > requests. > >=20 > > While this draft gives examples, and therefore implies it=20 > is valid for=20 > > some responses, it is not clear whether that extension now extends=20 > > beyond INVITE, is all INVITE responses, or is limited to 180=20 > > responses. Could we have some more normative type=20 > statements in this=20 > > regard. > >=20 > > Oh, and I'd actually like to know what the answer is! > >=20 > > regards > >=20 > > Keith > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From L.Liess@telekom.de Fri Feb 19 06:29:44 2010 Return-Path: <L.Liess@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AA03A7CDD for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 06:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTeEotOm5rBe for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 06:29:43 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id C3DED3A683C for <dispatch@ietf.org>; Fri, 19 Feb 2010 06:29:41 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 19 Feb 2010 15:30:21 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 15:30:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Feb 2010 15:30:20 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003FCB21E@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20B014C82@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 thread-index: AcqxXDaNCfTHOVS7R+Cnyhx8ab2pSQACUMvwAAGtHEAAAFjQcA== References: <EDC0A1AE77C57744B664A310A0B23AE20B014C31@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <40FB0FFB97588246A1BEFB05759DC8A003FCB1E8@S4DE9JSAANI.ost.t-com.de> <EDC0A1AE77C57744B664A310A0B23AE20B014C82@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: <L.Liess@telekom.de> To: <keith.drage@alcatel-lucent.com>, <dispatch@ietf.org> X-OriginalArrivalTime: 19 Feb 2010 14:30:21.0584 (UTC) FILETIME=[11291900:01CAB170] Subject: Re: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 14:29:44 -0000 Keith,=20 I think an informative statement regarding the header field usage is unchanged from RFC 3261 is a good idea. I will look for a place for it.=20 I am a little confused by the text " to INVITE requests only." in your first sentence. What did you mean with it?=20 Kind regards Laura =20 =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 > Sent: Friday, February 19, 2010 3:07 PM > To: Liess, Laura; dispatch@ietf.org > Subject: RE: [dispatch] Comment on=20 > draft-liess-dispatch-alert-info-urns-00 >=20 > So the header usage in RFC 3261 is INVITE requests and 180=20 > responses to INVITE requests only. That remains the case?=20 > Perhaps a single informative statement regarding the header=20 > field usage is unchanged from RFC 3261 might be appropriate,=20 > unless that is already covered elsewhere (I have not done a=20 > line by line scan). >=20 > regards >=20 > Keith >=20 >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On Behalf Of L.Liess@telekom.de > > Sent: Friday, February 19, 2010 1:57 PM > > To: DRAGE, Keith (Keith); dispatch@ietf.org > > Subject: Re: [dispatch] Comment on=20 > > draft-liess-dispatch-alert-info-urns-00 > >=20 > > Hi Keith,=20 > >=20 > > We are just working on a new version of the draft. There are=20 > > some inconsistencies in the 00 version.=20 > > The draft just should define additional identifiers which can=20 > > be sent in the Alert-Info header. It does not change the=20 > > header usage.=20 > >=20 > > I hope things will be more clear in the new version. E.g. all=20 > > "busy"- stuff was deleted. We also distinguish between ring=20 > > tones and ringback tones and state that ring tones can be=20 > > sent only in INVITE , while ringback tones can be sent only=20 > > in 180-ringing.=20 > >=20 > > Kind regards > > Laura =20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE,=20 > Keith (Keith) > > > Sent: Friday, February 19, 2010 1:14 PM > > > To: DISPATCH > > > Subject: [dispatch] Comment on=20 > > draft-liess-dispatch-alert-info-urns-00 > > >=20 > > > I was looking for the information on how this changed the=20 > > Alert-Info=20 > > > header field usage from RFC 3261 and did not find it. > > >=20 > > > RFC 3261 defines the usage of this header field only for INVITE=20 > > > requests. > > >=20 > > > While this draft gives examples, and therefore implies it=20 > > is valid for=20 > > > some responses, it is not clear whether that extension=20 > now extends=20 > > > beyond INVITE, is all INVITE responses, or is limited to 180=20 > > > responses. Could we have some more normative type=20 > > statements in this=20 > > > regard. > > >=20 > > > Oh, and I'd actually like to know what the answer is! > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 From keith.drage@alcatel-lucent.com Fri Feb 19 07:03:40 2010 Return-Path: <keith.drage@alcatel-lucent.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468EC3A7F80 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 07:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.541 X-Spam-Level: X-Spam-Status: No, score=-5.541 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6N-SQw-z8VA for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 07:03:39 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 01A463A8112 for <dispatch@ietf.org>; Fri, 19 Feb 2010 07:03:38 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1JF5Odq013274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Feb 2010 16:05:24 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 19 Feb 2010 16:05:24 +0100 From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To: "L.Liess@telekom.de" <L.Liess@telekom.de>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Fri, 19 Feb 2010 16:05:17 +0100 Thread-Topic: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 Thread-Index: AcqxXDaNCfTHOVS7R+Cnyhx8ab2pSQACUMvwAAGtHEAAAFjQcAABzSww Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20B014CAB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <EDC0A1AE77C57744B664A310A0B23AE20B014C31@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <40FB0FFB97588246A1BEFB05759DC8A003FCB1E8@S4DE9JSAANI.ost.t-com.de> <EDC0A1AE77C57744B664A310A0B23AE20B014C82@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <40FB0FFB97588246A1BEFB05759DC8A003FCB21E@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003FCB21E@S4DE9JSAANI.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 15:03:40 -0000 Maybe I was being too precise but the words "180 responses to INVITE reques= ts" needs to be read as a whole, i.e. it is a 160 response generated as a r= esult of receiving an INVITE request. Keith =20 > -----Original Message----- > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > Sent: Friday, February 19, 2010 2:30 PM > To: DRAGE, Keith (Keith); dispatch@ietf.org > Subject: RE: [dispatch] Comment on=20 > draft-liess-dispatch-alert-info-urns-00 >=20 >=20 > Keith,=20 >=20 > I think an informative statement regarding the header field=20 > usage is unchanged from RFC 3261 is a good idea. I will look=20 > for a place for it.=20 >=20 > I am a little confused by the text " to INVITE requests=20 > only." in your first sentence. What did you mean with it?=20 >=20 > Kind regards > Laura >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: Friday, February 19, 2010 3:07 PM > > To: Liess, Laura; dispatch@ietf.org > > Subject: RE: [dispatch] Comment on > > draft-liess-dispatch-alert-info-urns-00 > >=20 > > So the header usage in RFC 3261 is INVITE requests and 180=20 > responses=20 > > to INVITE requests only. That remains the case? > > Perhaps a single informative statement regarding the header field=20 > > usage is unchanged from RFC 3261 might be appropriate,=20 > unless that is=20 > > already covered elsewhere (I have not done a line by line scan). > >=20 > > regards > >=20 > > Keith > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of L.Liess@telekom.de > > > Sent: Friday, February 19, 2010 1:57 PM > > > To: DRAGE, Keith (Keith); dispatch@ietf.org > > > Subject: Re: [dispatch] Comment on > > > draft-liess-dispatch-alert-info-urns-00 > > >=20 > > > Hi Keith, > > >=20 > > > We are just working on a new version of the draft. There are some=20 > > > inconsistencies in the 00 version. > > > The draft just should define additional identifiers which can be=20 > > > sent in the Alert-Info header. It does not change the=20 > header usage. > > >=20 > > > I hope things will be more clear in the new version. E.g. all > > > "busy"- stuff was deleted. We also distinguish between ring tones=20 > > > and ringback tones and state that ring tones can be sent only in=20 > > > INVITE , while ringback tones can be sent only in 180-ringing. > > >=20 > > > Kind regards > > > Laura > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, > > Keith (Keith) > > > > Sent: Friday, February 19, 2010 1:14 PM > > > > To: DISPATCH > > > > Subject: [dispatch] Comment on > > > draft-liess-dispatch-alert-info-urns-00 > > > >=20 > > > > I was looking for the information on how this changed the > > > Alert-Info > > > > header field usage from RFC 3261 and did not find it. > > > >=20 > > > > RFC 3261 defines the usage of this header field only for INVITE=20 > > > > requests. > > > >=20 > > > > While this draft gives examples, and therefore implies it > > > is valid for > > > > some responses, it is not clear whether that extension > > now extends > > > > beyond INVITE, is all INVITE responses, or is limited to 180=20 > > > > responses. Could we have some more normative type > > > statements in this > > > > regard. > > > >=20 > > > > Oh, and I'd actually like to know what the answer is! > > > >=20 > > > > regards > > > >=20 > > > > Keith > > > >=20 > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > >=20 > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > >=20 > = From L.Liess@telekom.de Fri Feb 19 07:15:11 2010 Return-Path: <L.Liess@telekom.de> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E06B28C274 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 07:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.306 X-Spam-Level: X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7etKvVX2NeRd for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 07:15:07 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 893413A7DD5 for <dispatch@ietf.org>; Fri, 19 Feb 2010 07:15:04 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 19 Feb 2010 16:16:39 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 16:16:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Feb 2010 16:16:34 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003FCB25C@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20B014CAB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 thread-index: AcqxXDaNCfTHOVS7R+Cnyhx8ab2pSQACUMvwAAGtHEAAAFjQcAABzSwwAABpiTA= References: <EDC0A1AE77C57744B664A310A0B23AE20B014C31@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <40FB0FFB97588246A1BEFB05759DC8A003FCB1E8@S4DE9JSAANI.ost.t-com.de> <EDC0A1AE77C57744B664A310A0B23AE20B014C82@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <40FB0FFB97588246A1BEFB05759DC8A003FCB21E@S4DE9JSAANI.ost.t-com.de> <EDC0A1AE77C57744B664A310A0B23AE20B014CAB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: <L.Liess@telekom.de> To: <keith.drage@alcatel-lucent.com>, <dispatch@ietf.org> X-OriginalArrivalTime: 19 Feb 2010 15:16:35.0439 (UTC) FILETIME=[8681C7F0:01CAB176] Subject: Re: [dispatch] Comment on draft-liess-dispatch-alert-info-urns-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 15:15:11 -0000 Fine, thanks. Laura > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 > Sent: Friday, February 19, 2010 4:05 PM > To: Liess, Laura; dispatch@ietf.org > Subject: RE: [dispatch] Comment on=20 > draft-liess-dispatch-alert-info-urns-00 >=20 > Maybe I was being too precise but the words "180 responses to=20 > INVITE requests" needs to be read as a whole, i.e. it is a=20 > 160 response generated as a result of receiving an INVITE request. >=20 > Keith > =20 >=20 > > -----Original Message----- > > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > > Sent: Friday, February 19, 2010 2:30 PM > > To: DRAGE, Keith (Keith); dispatch@ietf.org > > Subject: RE: [dispatch] Comment on=20 > > draft-liess-dispatch-alert-info-urns-00 > >=20 > >=20 > > Keith,=20 > >=20 > > I think an informative statement regarding the header field=20 > > usage is unchanged from RFC 3261 is a good idea. I will look=20 > > for a place for it.=20 > >=20 > > I am a little confused by the text " to INVITE requests=20 > > only." in your first sentence. What did you mean with it?=20 > >=20 > > Kind regards > > Laura > >=20 > > =20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > > Sent: Friday, February 19, 2010 3:07 PM > > > To: Liess, Laura; dispatch@ietf.org > > > Subject: RE: [dispatch] Comment on > > > draft-liess-dispatch-alert-info-urns-00 > > >=20 > > > So the header usage in RFC 3261 is INVITE requests and 180=20 > > responses=20 > > > to INVITE requests only. That remains the case? > > > Perhaps a single informative statement regarding the header field=20 > > > usage is unchanged from RFC 3261 might be appropriate,=20 > > unless that is=20 > > > already covered elsewhere (I have not done a line by line scan). > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 > L.Liess@telekom.de > > > > Sent: Friday, February 19, 2010 1:57 PM > > > > To: DRAGE, Keith (Keith); dispatch@ietf.org > > > > Subject: Re: [dispatch] Comment on > > > > draft-liess-dispatch-alert-info-urns-00 > > > >=20 > > > > Hi Keith, > > > >=20 > > > > We are just working on a new version of the draft.=20 > There are some=20 > > > > inconsistencies in the 00 version. > > > > The draft just should define additional identifiers=20 > which can be=20 > > > > sent in the Alert-Info header. It does not change the=20 > > header usage. > > > >=20 > > > > I hope things will be more clear in the new version. E.g. all > > > > "busy"- stuff was deleted. We also distinguish between=20 > ring tones=20 > > > > and ringback tones and state that ring tones can be=20 > sent only in=20 > > > > INVITE , while ringback tones can be sent only in 180-ringing. > > > >=20 > > > > Kind regards > > > > Laura > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: dispatch-bounces@ietf.org > > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, > > > Keith (Keith) > > > > > Sent: Friday, February 19, 2010 1:14 PM > > > > > To: DISPATCH > > > > > Subject: [dispatch] Comment on > > > > draft-liess-dispatch-alert-info-urns-00 > > > > >=20 > > > > > I was looking for the information on how this changed the > > > > Alert-Info > > > > > header field usage from RFC 3261 and did not find it. > > > > >=20 > > > > > RFC 3261 defines the usage of this header field only=20 > for INVITE=20 > > > > > requests. > > > > >=20 > > > > > While this draft gives examples, and therefore implies it > > > > is valid for > > > > > some responses, it is not clear whether that extension > > > now extends > > > > > beyond INVITE, is all INVITE responses, or is limited to 180=20 > > > > > responses. Could we have some more normative type > > > > statements in this > > > > > regard. > > > > >=20 > > > > > Oh, and I'd actually like to know what the answer is! > > > > >=20 > > > > > regards > > > > >=20 > > > > > Keith > > > > >=20 > > > > > _______________________________________________ > > > > > dispatch mailing list > > > > > dispatch@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > >=20 > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > >=20 > > >=20 > >=20 >=20 From gmoczar@gmail.com Fri Feb 19 09:55:08 2010 Return-Path: <gmoczar@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0EC28C0F6 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 09:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v0m--hoiuMw for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 09:55:07 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 7E67C3A7ADF for <dispatch@ietf.org>; Fri, 19 Feb 2010 09:55:06 -0800 (PST) Received: by fxm5 with SMTP id 5so371958fxm.29 for <dispatch@ietf.org>; Fri, 19 Feb 2010 09:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=2RO9Xoq9Zi/VZAH38AFbN5dR0pNyoeVS3Ueg2CBlAkc=; b=WuOUwAZY8ksuQmPmw9qGHTmU4Q9WpJwqDYupQBhQ1YxgaDj5tm4seSeVfOI3IPk+AK 2bQLf6IGzlKKZI+sM5qTfikAJpquAbqPpeNqMpVw0QmwIyFDTQKATb3/i0If7KN5RFlg 7LPh1SE/5/VqB41YbzH3a66z4CTelRWeRR1jE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MZNOlVxJYDZCYtuFIdPuqvoyiPkt98Ha4/X7+5aPe1qSGtvJVtDwXptH9sSplqN/LY cgBSDujTmF8peXP/Fy3Zfh9PzHodfd3+W8je9KGEldN08ilEHy2tK9kYCmW2cc8hOmqc p+YagHRcsHTqTfkJtey5q9sQUDLsvvxYQDvSY= MIME-Version: 1.0 Received: by 10.87.61.5 with SMTP id o5mr8167491fgk.79.1266602207141; Fri, 19 Feb 2010 09:56:47 -0800 (PST) Date: Fri, 19 Feb 2010 18:56:47 +0100 Message-ID: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> From: Gabor Moczar <gmoczar@gmail.com> To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=001636458ca4a0e18f047ff7cead Subject: [dispatch] Comments on Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 17:57:40 -0000 --001636458ca4a0e18f047ff7cead Content-Type: text/plain; charset=ISO-8859-1 Dear Working Group Members, I am new to this list and Leon Portman from Nice suggested to send my comments on the Session Recording Protocol to here directly. I have 8+ years experience with IP based call recording solutions as a solution architect and product manager. Let me know your opinion about my comments. 1. Meta data SRP should provide a standard mechanism, which allows sending meta data in addition to the media to the RS. An extendible set of fields could describe the recorded call in a detailed way including calling party number, name, agent id, etc. Currently most implementations require implementing an additional interface using standard or proprietary CTI to obtain such kind of information. These implementations quite unique across the various platforms and considered to add additional complexity, OAM overhead and failure point to the overall solution. 2. Handling multiple media streams SRP should allow RS to select, which media stream should be recorded or not for a given session. As unified communication emerge, more and more customers using voice, video, instant messaging, etc. in their communication with their partners and clients. Customers may would like to decide, which media or which direction of the media should be recorded during the session. For compliance, probably only the voice part of a video conversation is sufficient too. 3. Security and encryption The draft very well describes the sensitivity of the topic from security point of view, however the term "encryption" is missing from the requirements part. I see that "eavesdropping protection" is used, but what is the purpose of not using the most obvious solution for "eavesdropping protection". I would also add: SRP should also allow the recording of encrypted calls. 4. Redundancy SRP should provide a mechanism to allow RCs to send the media to multiple RSs at one time. Probably endpoints with limited resources or networks with restricted bandwidth will not able to provide this feature, but in mission critical environments this could be a very nice way to provide redundancy. The failover mechanism described in the draft (and used by some of the vendors) is not protected from single point of failure. 5. Negotiating media handling capabilities SRP should allow RC and RS to negotiate audio/video codec capabilities (similar to SIP/SDP) and the RC should send media in the agreed codec. In most cases the codec will be exactly the same as the one used in the recorded session. However, high definition audio and video codecs are getting used in more and more sessions, for recording, the requirement in most cases allow to record the sessions in a lower resolution format. Either the RC, either the RS should provide transcoding capabilities. I know several video endpoints, which are able to send the video in 2 formats at one time (HD and CIF) and I can also imagine devices with on-board transcoding capabilities in the future (e.g. transcoding AAC-LD to G.729 for the RS) and some of the current implementations also allow the transcoding of the recording streams using network resources. 6. Others There are some points, which are mentioned in the use cases section, but no requirement is provided to support the given feature: - Silent monitoring and real-time applications: the entire mechanism should allow the users to implement a real-time monitoring functionality, which means that the media has to be transmitted with considerably low delay, in a real-time fashion to the RS. - Handling complex calls: SRP should provide a mechanism to allow the RS to link together certain call segments in a complex call scenario (e.g. providing a global call identifier as a part of the meta data). Best regards, Gabor --001636458ca4a0e18f047ff7cead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Dear Working Group Members,</div><div><br></div><div>I am new to this = list and Leon Portman from Nice suggested to send my comments on the Sessio= n Recording Protocol to here directly.</div><div>I have 8+ years experience= with IP based call recording solutions as a solution architect and product= manager.</div> <div>Let me know your opinion about my comments.</div><div><br></div><div>1= . Meta data=A0</div><div>SRP should provide a standard mechanism, which all= ows sending meta data in addition to the media to the RS. An extendible set= of fields could describe the recorded call in a detailed way including cal= ling party number, name, agent id, etc.=A0</div> <div>Currently most implementations require implementing an additional inte= rface using standard or proprietary CTI to obtain such kind of information.= These implementations quite unique across the various platforms and consid= ered to add additional complexity, OAM overhead and failure point to the ov= erall solution.=A0</div> <div><br></div><div>2. Handling multiple media streams=A0</div><div>SRP sho= uld allow RS to select, which media stream should be recorded or not for a = given session.=A0</div><div>As unified communication emerge, more and more = customers using voice, video, instant messaging, etc. in their communicatio= n with their partners and clients. Customers may would like to decide, whic= h media or which direction of the media should be recorded during the sessi= on. For compliance, probably only the voice part of a video conversation is= sufficient too.=A0</div> <div><br></div><div>3. Security and encryption=A0</div><div>The draft very = well describes the sensitivity of the topic from security point of view, ho= wever the term "encryption" is missing from the requirements part= . I see that "eavesdropping protection" is used, but what is the = purpose of not using the most obvious solution for "eavesdropping prot= ection".=A0</div> <div>I would also add: SRP should also allow the recording of encrypted cal= ls.=A0</div><div><br></div><div>4. Redundancy=A0</div><div>SRP should provi= de a mechanism to allow RCs to send the media to multiple RSs at one time.= =A0</div> <div>Probably endpoints with limited resources or networks with restricted = bandwidth will not able to provide this feature, but in mission critical en= vironments this could be a very nice way to provide redundancy. The failove= r mechanism described in the draft (and used by some of the vendors) is not= protected from single point of failure.=A0</div> <div><br></div><div>5. Negotiating media handling capabilities=A0</div><div= >SRP should allow RC and RS to negotiate audio/video codec capabilities (si= milar to SIP/SDP) and the RC should send media in the agreed codec.=A0</div= > <div>In most cases the codec will be exactly the same as the one used in th= e recorded session. However, high definition audio and video codecs are get= ting used in more and more sessions, for recording, the requirement in most= cases allow to record the sessions in a lower resolution format. Either th= e RC, either the RS should provide transcoding capabilities. I know several= video endpoints, which are able to send the video in 2 formats at one time= (HD and CIF) and I can also imagine devices with on-board transcoding capa= bilities in the future (e.g. transcoding AAC-LD to G.729 for the RS) and so= me of the current implementations also allow the transcoding of the recordi= ng streams using network resources.=A0</div> <div><br></div><div>6. Others=A0</div><div>There are some points, which are= mentioned in the use cases section, but no requirement is provided to supp= ort the given feature:=A0</div><div>- Silent monitoring and real-time appli= cations: the entire mechanism should allow the users to implement a real-ti= me monitoring functionality, which means that the media has to be transmitt= ed with considerably low delay, in a real-time fashion to the RS.=A0</div> <div>- Handling complex calls: SRP should provide a mechanism to allow the = RS to link together certain call segments in a complex call scenario (e.g. = providing a global call identifier as a part of the meta data).=A0</div><di= v> <br></div><div>Best regards,</div><div>Gabor</div> --001636458ca4a0e18f047ff7cead-- From pkyzivat@cisco.com Fri Feb 19 12:13:31 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05DB28C11D for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2Jf8h+WyIEv for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:13:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6B84828C11F for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:13:30 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIuAfktAZnwN/2dsb2JhbACbCW0GpW2XaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87420750" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2010 20:15:17 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKFHoc009853 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:15:17 GMT Message-ID: <4B7EF160.7040402@cisco.com> Date: Fri, 19 Feb 2010 15:15:28 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com> <4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> In-Reply-To: <4B786433.1060000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Preliminary version of Expert review of draft-avasarala-dispatch-comm-div-notification-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:13:31 -0000 I've been having an offline discussion of this with Ranjit and Adam. But it deserves public discussion. So after getting permission from the others I am going to forward those messages to the list. (There will be several.) The main issue is about the state model for this event package, or lack thereof. If you have thoughts on this, please speak up. Thanks, Paul From pkyzivat@cisco.com Fri Feb 19 12:15:16 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA6528C121 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE3txWXHtSmr for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:15:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F11EC28C11F for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:15:12 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMeAfktAZnwN/2dsb2JhbACbCW0GpWiXaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87552356" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 20:17:00 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKH0XA010256 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:17:00 GMT Message-ID: <4B7EF1C6.4000307@cisco.com> Date: Fri, 19 Feb 2010 15:17:10 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:15:16 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Wed, 17 Feb 2010 21:34:48 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> To: Avasarala Ranjit-A20990 <ranjit@motorola.com> CC: Adam Roach <adam@nostrum.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> Ranjit, [ taking IESG off the dist list for now, and adding Adam as the sub/not author. Perhaps we should take this back to the dispatch list. ] I haven't had time to read through the revised document yet, but I skimmed through your comments. There is one that I think we need to talk about because it potentially has significant impact. (I've picked the first place it came up, but its also mentioned in other parts of my issues and your responses.) Adam: Is this enough for you to understand the issue? Avasarala Ranjit-A20990 wrote: >> ISSUE: The document details the notification body, and some inferences > >> can be drawn about the state from the syntax of the notification body. >> But this is tenuous. There should be an explicit specification of the >> state maintained, and how it is mapped onto the notification body. > > <Ranjit-Feb16> The notifications for communication diversions are sent > as and when they occur depending on the filter criteria set by the > subscribers. So there is no need of maintaining any state information > for the package. That doesn't fit my understanding of how event packages are defined. IIUC, the semantics of event packages are described relative to some sort of "state", not against another incoming event. (Whether this is literally true in the implementation or not.) So minimally, when a diversion happens, some particular information is culled from it, and becomes the new state. Then that causes notifications to the existing subscriptions. After that it either sticks around, or else the state transitions back to "none". But if it transitions back to "none" then that would trigger another round of notifications - which you clearly don't want. So it makes sense that it sticks around, in which case, when a new subscription comes in it will get a notification about that last diversion. (Unless there can be some sort of "implicit" filter that suppresses notification when the state becomes "none".) Adam - is that valid??? Thanks, Paul From pkyzivat@cisco.com Fri Feb 19 12:15:30 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5BB28C16C for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2hxE-NKGILW for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:15:26 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 84A703A7B23 for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:15:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMeAfktAZnwM/2dsb2JhbACbCW0GpWiXaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87552371" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 20:17:10 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKHAPC019810 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:17:10 GMT Message-ID: <4B7EF1D1.5060403@cisco.com> Date: Fri, 19 Feb 2010 15:17:21 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: RE: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:15:30 -0000 -------- Original Message -------- Subject: RE: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Fri, 19 Feb 2010 01:08:59 +0800 From: Avasarala Ranjit-A20990 <ranjit@motorola.com> To: Paul Kyzivat <pkyzivat@cisco.com> CC: Adam Roach <adam@nostrum.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> Hi Paul, Adam Since communication diversion notification information is not related to any state of the actual communication, I feel there is no need to maintain state for this. Also the Communication diversion notification message gets triggered after the communication diversion has occurred. The main intent of CDIVN is to notify the subscriber of a communication diversion that occurred on their behalf in the network. This notification is not part of any communication dialog or part of the communication state machine and is completely independent of the actual communication (or call). Comments? Thanks Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, February 18, 2010 8:05 AM To: Avasarala Ranjit-A20990 Cc: Adam Roach; John-Luc Bakker Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Ranjit, [ taking IESG off the dist list for now, and adding Adam as the sub/not author. Perhaps we should take this back to the dispatch list. ] I haven't had time to read through the revised document yet, but I skimmed through your comments. There is one that I think we need to talk about because it potentially has significant impact. (I've picked the first place it came up, but its also mentioned in other parts of my issues and your responses.) Adam: Is this enough for you to understand the issue? Avasarala Ranjit-A20990 wrote: >> ISSUE: The document details the notification body, and some >> inferences > >> can be drawn about the state from the syntax of the notification body. >> But this is tenuous. There should be an explicit specification of the >> state maintained, and how it is mapped onto the notification body. > > <Ranjit-Feb16> The notifications for communication diversions are sent > as and when they occur depending on the filter criteria set by the > subscribers. So there is no need of maintaining any state information > for the package. That doesn't fit my understanding of how event packages are defined. IIUC, the semantics of event packages are described relative to some sort of "state", not against another incoming event. (Whether this is literally true in the implementation or not.) So minimally, when a diversion happens, some particular information is culled from it, and becomes the new state. Then that causes notifications to the existing subscriptions. After that it either sticks around, or else the state transitions back to "none". But if it transitions back to "none" then that would trigger another round of notifications - which you clearly don't want. So it makes sense that it sticks around, in which case, when a new subscription comes in it will get a notification about that last diversion. (Unless there can be some sort of "implicit" filter that suppresses notification when the state becomes "none".) Adam - is that valid??? Thanks, Paul From pkyzivat@cisco.com Fri Feb 19 12:15:35 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1489E28C165 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sJVcP-Po0Wf for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:15:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8B96D28C15B for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:15:32 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMeAfktAZnwM/2dsb2JhbACbCW0GpWiXaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87552389" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 20:17:19 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKHJoM019851 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:17:19 GMT Message-ID: <4B7EF1DA.60002@cisco.com> Date: Fri, 19 Feb 2010 15:17:30 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:15:35 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Thu, 18 Feb 2010 14:00:29 -0600 From: Adam Roach <adam@nostrum.com> To: Avasarala Ranjit-A20990 <ranjit@motorola.com> CC: Paul Kyzivat <pkyzivat@cisco.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> Paul is correct. The real thrust of RFC 3265 is monitoring the state of something. State becomes interesting at transitions (hence the focus on events), but the events are inherently talking about the state of something. In your case, I agree that it won't be call state. It appears to be related to some combination of call diversion preferences and proxy (?) processing state? I agree with Paul that the overall model is ill defined (even after reading 24.604), so I can't provide any concrete suggestions here. The best I can do is recommend you examine the existing corpus of event packages and come to an understanding about how they work: conference package IETF SIPPING Working Group [RFC4575] consent-pending-additions package Gonzalo Camarillo [RFC5362] dialog package IETF SIPPING Working Group [RFC4235] kpml package Eric Burger [RFC4730] message-summary package Rohan Mahy [RFC3842] poc-settings package Miguel A. Garcia-Martin [RFC4354] presence package Jonathan Rosenberg [RFC3856] reg package Jonathan Rosenberg [RFC3680] refer package Robert Sparks [RFC3515] spirits-INDPs package Vijay K. Gurbani [RFC3910] spirits-user-prof package Vijay K. Gurbani [RFC3910] winfo template-package Jonathan Rosenberg [RFC3857] xcap-diff package IETF Real-time Applications [RFC-ietf-sip-xcapevent-08.txt] and Infrastructure Area You'll note that every one of these event packages actually talks about the *state* of something, and describes sending notifications when that *state* changes. And, with the exception of the dialog event package (and arguably the spirits-INDPs event package), you'll note that none of these states are actual call state -- they're the state of the resource as it pertains to the aspect that the event package monitors. For your proposed div-notification event package, you need to define what this state is and how it changes. If you can't do that, then an RFC3265 event package probably isn't the right tool for the job you have in mind. /a On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote: > Hi Paul, Adam > > Since communication diversion notification information is not related to > any state of the actual communication, I feel there is no need to > maintain state for this. Also the Communication diversion notification > message gets triggered after the communication diversion has occurred. > > The main intent of CDIVN is to notify the subscriber of a communication > diversion that occurred on their behalf in the network. This > notification is not part of any communication dialog or part of the > communication state machine and is completely independent of the actual > communication (or call). > > Comments? > > Thanks > > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, February 18, 2010 8:05 AM > To: Avasarala Ranjit-A20990 > Cc: Adam Roach; John-Luc Bakker > Subject: Re: [dispatch] Preliminary version of Expert review > ofdraft-avasarala-dispatch-comm-div-notification-03 > > Ranjit, > > [ taking IESG off the dist list for now, and adding Adam as the sub/not > author. Perhaps we should take this back to the dispatch list. ] > > I haven't had time to read through the revised document yet, but I > skimmed through your comments. There is one that I think we need to talk > about because it potentially has significant impact. (I've picked the > first place it came up, but its also mentioned in other parts of my > issues and your responses.) > > Adam: Is this enough for you to understand the issue? > > Avasarala Ranjit-A20990 wrote: > > >>> ISSUE: The document details the notification body, and some >>> inferences >>> >> >>> can be drawn about the state from the syntax of the notification >>> > body. > >>> But this is tenuous. There should be an explicit specification of the >>> > >>> state maintained, and how it is mapped onto the notification body. >>> >> <Ranjit-Feb16> The notifications for communication diversions are sent >> > >> as and when they occur depending on the filter criteria set by the >> subscribers. So there is no need of maintaining any state information >> for the package. >> > That doesn't fit my understanding of how event packages are defined. > > IIUC, the semantics of event packages are described relative to some > sort of "state", not against another incoming event. (Whether this is > literally true in the implementation or not.) > > So minimally, when a diversion happens, some particular information is > culled from it, and becomes the new state. Then that causes > notifications to the existing subscriptions. > > After that it either sticks around, or else the state transitions back > to "none". But if it transitions back to "none" then that would trigger > another round of notifications - which you clearly don't want. > > So it makes sense that it sticks around, in which case, when a new > subscription comes in it will get a notification about that last > diversion. (Unless there can be some sort of "implicit" filter that > suppresses notification when the state becomes "none".) > > Adam - is that valid??? > > Thanks, > Paul > From pkyzivat@cisco.com Fri Feb 19 12:16:00 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667AE28C121 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bVrIJNkgXr3 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:15:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 38F6928C16E for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:15:45 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIuAfktAZnwM/2dsb2JhbACbCW0GpW2XaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87420947" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2010 20:17:32 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKHWQS019908 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:17:32 GMT Message-ID: <4B7EF1E7.7040405@cisco.com> Date: Fri, 19 Feb 2010 15:17:43 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:16:01 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Thu, 18 Feb 2010 16:30:20 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> To: Adam Roach <adam@nostrum.com> CC: Avasarala Ranjit-A20990 <ranjit@motorola.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> <4B7D9C5D.6090308@nostrum.com> Thanks Adam. Ranjit - I was thinking that minimally your state could be described as: 1) the incoming sip message to the diverting system 2) the resultant outgoing sip message from the diverting system Before the first diversion the state would be nil. After the first diversion, and the resulting notifications, there is a question whether you retain that state. Its conceptually simpler if you do. But if you want your server to be "stateless" in this regard, then maybe you have to think about it immediately transitioning back to nil state, before another diversion can occur. As I noted in my prior message, that amounts to another state change, and hence calls for another set of notifications, unless they are suppressed by a filter of some sort. Another issue is what happens with "simultaneous" diversions? Are you expecting them to be serialized, resulting in distinct back-to-back notifications? Or in that case do you want a single notification with both diversions? If you want that, then the "state" needs to simultaneously include both. Thanks, Paul Adam Roach wrote: > Paul is correct. The real thrust of RFC 3265 is monitoring the state of > something. State becomes interesting at transitions (hence the focus on > events), but the events are inherently talking about the state of something. > > In your case, I agree that it won't be call state. It appears to be > related to some combination of call diversion preferences and proxy (?) > processing state? I agree with Paul that the overall model is ill > defined (even after reading 24.604), so I can't provide any concrete > suggestions here. The best I can do is recommend you examine the > existing corpus of event packages and come to an understanding about how > they work: > > conference package IETF SIPPING Working Group [RFC4575] > consent-pending-additions package Gonzalo Camarillo [RFC5362] > dialog package IETF SIPPING Working Group [RFC4235] > kpml package Eric Burger [RFC4730] > message-summary package Rohan Mahy [RFC3842] > poc-settings package Miguel A. Garcia-Martin [RFC4354] > presence package Jonathan Rosenberg [RFC3856] > reg package Jonathan Rosenberg [RFC3680] > refer package Robert Sparks [RFC3515] > spirits-INDPs package Vijay K. Gurbani [RFC3910] > spirits-user-prof package Vijay K. Gurbani [RFC3910] > winfo template-package Jonathan Rosenberg [RFC3857] > xcap-diff package IETF Real-time Applications [RFC-ietf-sip-xcapevent-08.txt] > and Infrastructure Area > > You'll note that every one of these event packages actually talks about > the *state* of something, and describes sending notifications when that > *state* changes. And, with the exception of the dialog event package > (and arguably the spirits-INDPs event package), you'll note that none > of these states are actual call state -- they're the state of the > resource as it pertains to the aspect that the event package monitors. > > For your proposed div-notification event package, you need to define > what this state is and how it changes. If you can't do that, then an > RFC3265 event package probably isn't the right tool for the job you have > in mind. > > /a > > On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote: >> Hi Paul, Adam >> >> Since communication diversion notification information is not related to >> any state of the actual communication, I feel there is no need to >> maintain state for this. Also the Communication diversion notification >> message gets triggered after the communication diversion has occurred. >> >> The main intent of CDIVN is to notify the subscriber of a communication >> diversion that occurred on their behalf in the network. This >> notification is not part of any communication dialog or part of the >> communication state machine and is completely independent of the actual >> communication (or call). >> >> Comments? >> >> Thanks >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, February 18, 2010 8:05 AM >> To: Avasarala Ranjit-A20990 >> Cc: Adam Roach; John-Luc Bakker >> Subject: Re: [dispatch] Preliminary version of Expert review >> ofdraft-avasarala-dispatch-comm-div-notification-03 >> >> Ranjit, >> >> [ taking IESG off the dist list for now, and adding Adam as the sub/not >> author. Perhaps we should take this back to the dispatch list. ] >> >> I haven't had time to read through the revised document yet, but I >> skimmed through your comments. There is one that I think we need to talk >> about because it potentially has significant impact. (I've picked the >> first place it came up, but its also mentioned in other parts of my >> issues and your responses.) >> >> Adam: Is this enough for you to understand the issue? >> >> Avasarala Ranjit-A20990 wrote: >> >> >>>> ISSUE: The document details the notification body, and some >>>> inferences >>>> >>> >>>> can be drawn about the state from the syntax of the notification >>>> >> body. >> >>>> But this is tenuous. There should be an explicit specification of the >>>> >> >>>> state maintained, and how it is mapped onto the notification body. >>>> >>> <Ranjit-Feb16> The notifications for communication diversions are sent >>> >> >>> as and when they occur depending on the filter criteria set by the >>> subscribers. So there is no need of maintaining any state information >>> for the package. >>> >> That doesn't fit my understanding of how event packages are defined. >> >> IIUC, the semantics of event packages are described relative to some >> sort of "state", not against another incoming event. (Whether this is >> literally true in the implementation or not.) >> >> So minimally, when a diversion happens, some particular information is >> culled from it, and becomes the new state. Then that causes >> notifications to the existing subscriptions. >> >> After that it either sticks around, or else the state transitions back >> to "none". But if it transitions back to "none" then that would trigger >> another round of notifications - which you clearly don't want. >> >> So it makes sense that it sticks around, in which case, when a new >> subscription comes in it will get a notification about that last >> diversion. (Unless there can be some sort of "implicit" filter that >> suppresses notification when the state becomes "none".) >> >> Adam - is that valid??? >> >> Thanks, >> Paul >> > From pkyzivat@cisco.com Fri Feb 19 12:16:38 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FF828C121 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwG4GmQlb-sO for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:16:37 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CC33D28C11F for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:16:36 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMeAfktAZnwM/2dsb2JhbACbCW0GpWiXaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87552445" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 20:18:23 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKINxo020058 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:18:23 GMT Message-ID: <4B7EF21A.3000405@cisco.com> Date: Fri, 19 Feb 2010 15:18:34 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:16:38 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Thu, 18 Feb 2010 15:37:44 -0600 From: Adam Roach <adam@nostrum.com> To: Paul Kyzivat <pkyzivat@cisco.com> CC: Avasarala Ranjit-A20990 <ranjit@motorola.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> <4B7D9C5D.6090308@nostrum.com> <4B7DB16C.2050601@cisco.com> Another way to examine this problem might be to consider the state as being composed of the list of diverted callers. You can age entries out, and reset the list when diversion is shut off. Doing this makes it much clearer what should happen for the near-simultaneous case. Note that this is conceptually similar to what the winfo event package template does with its "waiting" state. /a On 2/18/10 15:30, Feb 18, Paul Kyzivat wrote: > Thanks Adam. > > Ranjit - I was thinking that minimally your state could be described as: > > 1) the incoming sip message to the diverting system > 2) the resultant outgoing sip message from the diverting system > > Before the first diversion the state would be nil. > > After the first diversion, and the resulting notifications, there is a > question whether you retain that state. Its conceptually simpler if > you do. But if you want your server to be "stateless" in this regard, > then maybe you have to think about it immediately transitioning back > to nil state, before another diversion can occur. > > As I noted in my prior message, that amounts to another state change, > and hence calls for another set of notifications, unless they are > suppressed by a filter of some sort. > > Another issue is what happens with "simultaneous" diversions? Are you > expecting them to be serialized, resulting in distinct back-to-back > notifications? Or in that case do you want a single notification with > both diversions? If you want that, then the "state" needs to > simultaneously include both. > > Thanks, > Paul > > Adam Roach wrote: >> Paul is correct. The real thrust of RFC 3265 is monitoring the state >> of something. State becomes interesting at transitions (hence the >> focus on events), but the events are inherently talking about the >> state of something. >> >> In your case, I agree that it won't be call state. It appears to be >> related to some combination of call diversion preferences and proxy >> (?) processing state? I agree with Paul that the overall model is ill >> defined (even after reading 24.604), so I can't provide any concrete >> suggestions here. The best I can do is recommend you examine the >> existing corpus of event packages and come to an understanding about >> how they work: >> >> conference package IETF SIPPING Working >> Group [RFC4575] consent-pending-additions package >> Gonzalo Camarillo [RFC5362] >> dialog package IETF SIPPING Working >> Group [RFC4235] kpml package Eric >> Burger [RFC4730] >> message-summary package Rohan >> Mahy [RFC3842] >> poc-settings package Miguel A. >> Garcia-Martin [RFC4354] >> presence package Jonathan >> Rosenberg [RFC3856] >> reg package Jonathan >> Rosenberg [RFC3680] >> refer package Robert >> Sparks [RFC3515] >> spirits-INDPs package Vijay K. >> Gurbani [RFC3910] >> spirits-user-prof package Vijay K. >> Gurbani [RFC3910] >> winfo template-package Jonathan >> Rosenberg [RFC3857] >> xcap-diff package IETF Real-time >> Applications [RFC-ietf-sip-xcapevent-08.txt] >> and Infrastructure Area >> >> You'll note that every one of these event packages actually talks >> about the *state* of something, and describes sending notifications >> when that *state* changes. And, with the exception of the dialog >> event package (and arguably the spirits-INDPs event package), you'll >> note that none of these states are actual call state -- they're the >> state of the resource as it pertains to the aspect that the event >> package monitors. >> >> For your proposed div-notification event package, you need to define >> what this state is and how it changes. If you can't do that, then an >> RFC3265 event package probably isn't the right tool for the job you >> have in mind. >> >> /a >> >> On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote: >>> Hi Paul, Adam >>> >>> Since communication diversion notification information is not >>> related to >>> any state of the actual communication, I feel there is no need to >>> maintain state for this. Also the Communication diversion notification >>> message gets triggered after the communication diversion has occurred. >>> >>> The main intent of CDIVN is to notify the subscriber of a communication >>> diversion that occurred on their behalf in the network. This >>> notification is not part of any communication dialog or part of the >>> communication state machine and is completely independent of the actual >>> communication (or call). >>> >>> Comments? >>> >>> Thanks >>> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, >>> February 18, 2010 8:05 AM >>> To: Avasarala Ranjit-A20990 >>> Cc: Adam Roach; John-Luc Bakker >>> Subject: Re: [dispatch] Preliminary version of Expert review >>> ofdraft-avasarala-dispatch-comm-div-notification-03 >>> >>> Ranjit, >>> >>> [ taking IESG off the dist list for now, and adding Adam as the sub/not >>> author. Perhaps we should take this back to the dispatch list. ] >>> >>> I haven't had time to read through the revised document yet, but I >>> skimmed through your comments. There is one that I think we need to >>> talk >>> about because it potentially has significant impact. (I've picked the >>> first place it came up, but its also mentioned in other parts of my >>> issues and your responses.) >>> >>> Adam: Is this enough for you to understand the issue? >>> >>> Avasarala Ranjit-A20990 wrote: >>> >>>>> ISSUE: The document details the notification body, and some >>>>> inferences >>>>> can be drawn about the state from the syntax of the notification >>> body. >>>>> But this is tenuous. There should be an explicit specification of the >>>>> state maintained, and how it is mapped onto the notification body. >>>> <Ranjit-Feb16> The notifications for communication diversions are sent >>>> as and when they occur depending on the filter criteria set by the >>>> subscribers. So there is no need of maintaining any state >>>> information for the package. >>> That doesn't fit my understanding of how event packages are defined. >>> >>> IIUC, the semantics of event packages are described relative to some >>> sort of "state", not against another incoming event. (Whether this is >>> literally true in the implementation or not.) >>> >>> So minimally, when a diversion happens, some particular information is >>> culled from it, and becomes the new state. Then that causes >>> notifications to the existing subscriptions. >>> >>> After that it either sticks around, or else the state transitions back >>> to "none". But if it transitions back to "none" then that would trigger >>> another round of notifications - which you clearly don't want. >>> >>> So it makes sense that it sticks around, in which case, when a new >>> subscription comes in it will get a notification about that last >>> diversion. (Unless there can be some sort of "implicit" filter that >>> suppresses notification when the state becomes "none".) >>> >>> Adam - is that valid??? >>> >>> Thanks, >>> Paul >> From pkyzivat@cisco.com Fri Feb 19 12:16:57 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA3928C15B for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzBwPm5IAX4A for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:16:56 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D6AC93A7A97 for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:16:55 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIuAfktAZnwN/2dsb2JhbACbCW0GpW2XaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87421002" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2010 20:18:43 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKIgop010611 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:18:42 GMT Message-ID: <4B7EF22D.3010500@cisco.com> Date: Fri, 19 Feb 2010 15:18:53 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:16:57 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Thu, 18 Feb 2010 16:58:51 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> To: Adam Roach <adam@nostrum.com> CC: Avasarala Ranjit-A20990 <ranjit@motorola.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> <4B7D9C5D.6090308@nostrum.com> <4B7DB16C.2050601@cisco.com> <4B7DB328.1020306@nostrum.com> Adam Roach wrote: > Another way to examine this problem might be to consider the state as > being composed of the list of diverted callers. You can age entries out, > and reset the list when diversion is shut off. Doing this makes it much > clearer what should happen for the near-simultaneous case. > > Note that this is conceptually similar to what the winfo event package > template does with its "waiting" state. I'm just inferring from what Ranjit has said that they envision a server that doesn't keep *any* state about diverted calls. I'm trying to see if this can be so and still conform to the 3265 view of the world. Do you think its a valid approach to have state instantaneously appear and disappear, and for a filter to block the delivery of the transitions back to nil state? Thanks, Paul > /a > > On 2/18/10 15:30, Feb 18, Paul Kyzivat wrote: >> Thanks Adam. >> >> Ranjit - I was thinking that minimally your state could be described as: >> >> 1) the incoming sip message to the diverting system >> 2) the resultant outgoing sip message from the diverting system >> >> Before the first diversion the state would be nil. >> >> After the first diversion, and the resulting notifications, there is a >> question whether you retain that state. Its conceptually simpler if >> you do. But if you want your server to be "stateless" in this regard, >> then maybe you have to think about it immediately transitioning back >> to nil state, before another diversion can occur. >> >> As I noted in my prior message, that amounts to another state change, >> and hence calls for another set of notifications, unless they are >> suppressed by a filter of some sort. >> >> Another issue is what happens with "simultaneous" diversions? Are you >> expecting them to be serialized, resulting in distinct back-to-back >> notifications? Or in that case do you want a single notification with >> both diversions? If you want that, then the "state" needs to >> simultaneously include both. >> >> Thanks, >> Paul >> >> Adam Roach wrote: >>> Paul is correct. The real thrust of RFC 3265 is monitoring the state >>> of something. State becomes interesting at transitions (hence the >>> focus on events), but the events are inherently talking about the >>> state of something. >>> >>> In your case, I agree that it won't be call state. It appears to be >>> related to some combination of call diversion preferences and proxy >>> (?) processing state? I agree with Paul that the overall model is ill >>> defined (even after reading 24.604), so I can't provide any concrete >>> suggestions here. The best I can do is recommend you examine the >>> existing corpus of event packages and come to an understanding about >>> how they work: >>> >>> conference package IETF SIPPING Working >>> Group [RFC4575] consent-pending-additions package >>> Gonzalo Camarillo [RFC5362] >>> dialog package IETF SIPPING Working >>> Group [RFC4235] kpml package Eric >>> Burger [RFC4730] >>> message-summary package Rohan >>> Mahy [RFC3842] >>> poc-settings package Miguel A. >>> Garcia-Martin [RFC4354] >>> presence package Jonathan >>> Rosenberg [RFC3856] >>> reg package Jonathan >>> Rosenberg [RFC3680] >>> refer package Robert >>> Sparks [RFC3515] >>> spirits-INDPs package Vijay K. >>> Gurbani [RFC3910] >>> spirits-user-prof package Vijay K. >>> Gurbani [RFC3910] >>> winfo template-package Jonathan >>> Rosenberg [RFC3857] >>> xcap-diff package IETF Real-time >>> Applications [RFC-ietf-sip-xcapevent-08.txt] >>> and Infrastructure Area >>> >>> You'll note that every one of these event packages actually talks >>> about the *state* of something, and describes sending notifications >>> when that *state* changes. And, with the exception of the dialog >>> event package (and arguably the spirits-INDPs event package), you'll >>> note that none of these states are actual call state -- they're the >>> state of the resource as it pertains to the aspect that the event >>> package monitors. >>> >>> For your proposed div-notification event package, you need to define >>> what this state is and how it changes. If you can't do that, then an >>> RFC3265 event package probably isn't the right tool for the job you >>> have in mind. >>> >>> /a >>> >>> On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote: >>>> Hi Paul, Adam >>>> >>>> Since communication diversion notification information is not >>>> related to >>>> any state of the actual communication, I feel there is no need to >>>> maintain state for this. Also the Communication diversion notification >>>> message gets triggered after the communication diversion has occurred. >>>> >>>> The main intent of CDIVN is to notify the subscriber of a communication >>>> diversion that occurred on their behalf in the network. This >>>> notification is not part of any communication dialog or part of the >>>> communication state machine and is completely independent of the actual >>>> communication (or call). >>>> >>>> Comments? >>>> >>>> Thanks >>>> >>>> Regards >>>> Ranjit >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, >>>> February 18, 2010 8:05 AM >>>> To: Avasarala Ranjit-A20990 >>>> Cc: Adam Roach; John-Luc Bakker >>>> Subject: Re: [dispatch] Preliminary version of Expert review >>>> ofdraft-avasarala-dispatch-comm-div-notification-03 >>>> >>>> Ranjit, >>>> >>>> [ taking IESG off the dist list for now, and adding Adam as the sub/not >>>> author. Perhaps we should take this back to the dispatch list. ] >>>> >>>> I haven't had time to read through the revised document yet, but I >>>> skimmed through your comments. There is one that I think we need to >>>> talk >>>> about because it potentially has significant impact. (I've picked the >>>> first place it came up, but its also mentioned in other parts of my >>>> issues and your responses.) >>>> >>>> Adam: Is this enough for you to understand the issue? >>>> >>>> Avasarala Ranjit-A20990 wrote: >>>> >>>>>> ISSUE: The document details the notification body, and some >>>>>> inferences >>>>>> can be drawn about the state from the syntax of the notification >>>> body. >>>>>> But this is tenuous. There should be an explicit specification of the >>>>>> state maintained, and how it is mapped onto the notification body. >>>>> <Ranjit-Feb16> The notifications for communication diversions are sent >>>>> as and when they occur depending on the filter criteria set by the >>>>> subscribers. So there is no need of maintaining any state >>>>> information for the package. >>>> That doesn't fit my understanding of how event packages are defined. >>>> >>>> IIUC, the semantics of event packages are described relative to some >>>> sort of "state", not against another incoming event. (Whether this is >>>> literally true in the implementation or not.) >>>> >>>> So minimally, when a diversion happens, some particular information is >>>> culled from it, and becomes the new state. Then that causes >>>> notifications to the existing subscriptions. >>>> >>>> After that it either sticks around, or else the state transitions back >>>> to "none". But if it transitions back to "none" then that would trigger >>>> another round of notifications - which you clearly don't want. >>>> >>>> So it makes sense that it sticks around, in which case, when a new >>>> subscription comes in it will get a notification about that last >>>> diversion. (Unless there can be some sort of "implicit" filter that >>>> suppresses notification when the state becomes "none".) >>>> >>>> Adam - is that valid??? >>>> >>>> Thanks, >>>> Paul >>> > > From pkyzivat@cisco.com Fri Feb 19 12:17:07 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F6D28C18F for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78JTO0oGQNTB for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:17:06 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3408A28C11F for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:17:06 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMeAfktAZnwM/2dsb2JhbACbCW0GpWiXaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87552471" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 20:18:53 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKIrWm020167 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:18:53 GMT Message-ID: <4B7EF238.8050301@cisco.com> Date: Fri, 19 Feb 2010 15:19:04 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:17:07 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Thu, 18 Feb 2010 16:10:07 -0600 From: Adam Roach <adam@nostrum.com> To: Paul Kyzivat <pkyzivat@cisco.com> CC: Avasarala Ranjit-A20990 <ranjit@motorola.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> <4B7D9C5D.6090308@nostrum.com> <4B7DB16C.2050601@cisco.com> <4B7DB328.1020306@nostrum.com> <4B7DB81B.4030201@cisco.com> On 2/18/10 15:58, Feb 18, Paul Kyzivat wrote: > > > Adam Roach wrote: >> Another way to examine this problem might be to consider the state as >> being composed of the list of diverted callers. You can age entries >> out, and reset the list when diversion is shut off. Doing this makes >> it much clearer what should happen for the near-simultaneous case. >> >> Note that this is conceptually similar to what the winfo event >> package template does with its "waiting" state. > > I'm just inferring from what Ranjit has said that they envision a > server that doesn't keep *any* state about diverted calls. I'm trying > to see if this can be so and still conform to the 3265 view of the world. > > Do you think its a valid approach to have state instantaneously appear > and disappear, and for a filter to block the delivery of the > transitions back to nil state? I think that's a bit tortured, as state models go. In particular, we've defined (and are defining) mechanisms that allow various modifications to the way SUBSCRIBE and NOTIFY work, and they assume more persistence than what you've described. For example, consider how your proposed state model would interact with subnot-etags or the ongoing throttling work. It doesn't make any sense, does it? Because we're assuming real state behind the event package, not instantaneous events that result in no persistent state. Really, none of this should be surprising to anyone; it's spelled out pretty clearly in the definition of an event package as given in RFC 3265: Event Package: An event package is an additional specification which defines a _set of state information_ to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by this document required to convey such state information. If you don't want to track _state_, then this is the wrong tool. If you want to use this tool, you need to define a state model. /a From pkyzivat@cisco.com Fri Feb 19 12:17:21 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE76E28C11F for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHLgz8Qvpf8c for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:17:21 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9425E3A798D for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:17:21 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIuAfktAZnwM/2dsb2JhbACbCW0GpW2XaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87421017" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2010 20:19:09 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKJ8u0020226 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:19:08 GMT Message-ID: <4B7EF247.9020402@cisco.com> Date: Fri, 19 Feb 2010 15:19:19 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:17:22 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Thu, 18 Feb 2010 16:10:07 -0600 From: Adam Roach <adam@nostrum.com> To: Paul Kyzivat <pkyzivat@cisco.com> CC: Avasarala Ranjit-A20990 <ranjit@motorola.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> <4B7D9C5D.6090308@nostrum.com> <4B7DB16C.2050601@cisco.com> <4B7DB328.1020306@nostrum.com> <4B7DB81B.4030201@cisco.com> On 2/18/10 15:58, Feb 18, Paul Kyzivat wrote: > > > Adam Roach wrote: >> Another way to examine this problem might be to consider the state as >> being composed of the list of diverted callers. You can age entries >> out, and reset the list when diversion is shut off. Doing this makes >> it much clearer what should happen for the near-simultaneous case. >> >> Note that this is conceptually similar to what the winfo event >> package template does with its "waiting" state. > > I'm just inferring from what Ranjit has said that they envision a > server that doesn't keep *any* state about diverted calls. I'm trying > to see if this can be so and still conform to the 3265 view of the world. > > Do you think its a valid approach to have state instantaneously appear > and disappear, and for a filter to block the delivery of the > transitions back to nil state? I think that's a bit tortured, as state models go. In particular, we've defined (and are defining) mechanisms that allow various modifications to the way SUBSCRIBE and NOTIFY work, and they assume more persistence than what you've described. For example, consider how your proposed state model would interact with subnot-etags or the ongoing throttling work. It doesn't make any sense, does it? Because we're assuming real state behind the event package, not instantaneous events that result in no persistent state. Really, none of this should be surprising to anyone; it's spelled out pretty clearly in the definition of an event package as given in RFC 3265: Event Package: An event package is an additional specification which defines a _set of state information_ to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by this document required to convey such state information. If you don't want to track _state_, then this is the wrong tool. If you want to use this tool, you need to define a state model. /a From pkyzivat@cisco.com Fri Feb 19 12:17:54 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F0328C129 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xDVA3yUA1da for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:17:52 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4784528C16C for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:17:52 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIuAfktAZnwN/2dsb2JhbACbCW0GpW2XaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87421058" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2010 20:19:39 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKJd7O010818 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:19:39 GMT Message-ID: <4B7EF266.9040801@cisco.com> Date: Fri, 19 Feb 2010 15:19:50 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: RE: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:17:54 -0000 -------- Original Message -------- Subject: RE: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Fri, 19 Feb 2010 17:59:05 +0800 From: Avasarala Ranjit-A20990 <ranjit@motorola.com> To: Paul Kyzivat <pkyzivat@cisco.com>, Adam Roach <adam@nostrum.com> CC: John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> <4B7D9C5D.6090308@nostrum.com> <4B7DB16C.2050601@cisco.com> Hi Paul In case of IMS, the diverting system would be the Application Server (AS) that is hosting the CDIVN service. Now if we need the concept of state, then we need to monitor the state of the AS or the CDIVN service. So true as you say, we prefer the notification server to be "Stateless" and hence it would start with "idle" state before sending a notification information and will transition to "send" state and immediately back to "idle" state waiting for another diversion to occur. Now when another diversion occurs, if the notification server needs to send a notification (depending on filter criteria), then it will transition to "send" state to send the notification, else it will remain in "idle" state. True simultaneous diversions will be serialized and the server needs to switch back and forth between states to send multiple notifications i.e idle->send->idle. Is this ok? Thanks Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, February 19, 2010 3:00 AM To: Adam Roach Cc: Avasarala Ranjit-A20990; John-Luc Bakker Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Thanks Adam. Ranjit - I was thinking that minimally your state could be described as: 1) the incoming sip message to the diverting system 2) the resultant outgoing sip message from the diverting system Before the first diversion the state would be nil. After the first diversion, and the resulting notifications, there is a question whether you retain that state. Its conceptually simpler if you do. But if you want your server to be "stateless" in this regard, then maybe you have to think about it immediately transitioning back to nil state, before another diversion can occur. As I noted in my prior message, that amounts to another state change, and hence calls for another set of notifications, unless they are suppressed by a filter of some sort. Another issue is what happens with "simultaneous" diversions? Are you expecting them to be serialized, resulting in distinct back-to-back notifications? Or in that case do you want a single notification with both diversions? If you want that, then the "state" needs to simultaneously include both. Thanks, Paul Adam Roach wrote: > Paul is correct. The real thrust of RFC 3265 is monitoring the state > of something. State becomes interesting at transitions (hence the > focus on events), but the events are inherently talking about the state of something. > > In your case, I agree that it won't be call state. It appears to be > related to some combination of call diversion preferences and proxy > (?) processing state? I agree with Paul that the overall model is ill > defined (even after reading 24.604), so I can't provide any concrete > suggestions here. The best I can do is recommend you examine the > existing corpus of event packages and come to an understanding about > how they work: > > conference package IETF SIPPING Working Group [RFC4575] > consent-pending-additions package Gonzalo Camarillo [RFC5362] > dialog package IETF SIPPING Working Group [RFC4235] > kpml package Eric Burger [RFC4730] > message-summary package Rohan Mahy [RFC3842] > poc-settings package Miguel A. Garcia-Martin [RFC4354] > presence package Jonathan Rosenberg [RFC3856] > reg package Jonathan Rosenberg [RFC3680] > refer package Robert Sparks [RFC3515] > spirits-INDPs package Vijay K. Gurbani [RFC3910] > spirits-user-prof package Vijay K. Gurbani [RFC3910] > winfo template-package Jonathan Rosenberg [RFC3857] > xcap-diff package IETF Real-time Applications [RFC-ietf-sip-xcapevent-08.txt] > and Infrastructure Area > > You'll note that every one of these event packages actually talks > about the *state* of something, and describes sending notifications > when that > *state* changes. And, with the exception of the dialog event package > (and arguably the spirits-INDPs event package), you'll note that none > of these states are actual call state -- they're the state of the > resource as it pertains to the aspect that the event package monitors. > > For your proposed div-notification event package, you need to define > what this state is and how it changes. If you can't do that, then an > RFC3265 event package probably isn't the right tool for the job you > have in mind. > > /a > > On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote: >> Hi Paul, Adam >> >> Since communication diversion notification information is not related >> to any state of the actual communication, I feel there is no need to >> maintain state for this. Also the Communication diversion >> notification message gets triggered after the communication diversion has occurred. >> >> The main intent of CDIVN is to notify the subscriber of a >> communication diversion that occurred on their behalf in the network. >> This notification is not part of any communication dialog or part of >> the communication state machine and is completely independent of the >> actual communication (or call). >> >> Comments? >> >> Thanks >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, February 18, 2010 8:05 AM >> To: Avasarala Ranjit-A20990 >> Cc: Adam Roach; John-Luc Bakker >> Subject: Re: [dispatch] Preliminary version of Expert review >> ofdraft-avasarala-dispatch-comm-div-notification-03 >> >> Ranjit, >> >> [ taking IESG off the dist list for now, and adding Adam as the >> sub/not author. Perhaps we should take this back to the dispatch >> list. ] >> >> I haven't had time to read through the revised document yet, but I >> skimmed through your comments. There is one that I think we need to >> talk about because it potentially has significant impact. (I've >> picked the first place it came up, but its also mentioned in other >> parts of my issues and your responses.) >> >> Adam: Is this enough for you to understand the issue? >> >> Avasarala Ranjit-A20990 wrote: >> >> >>>> ISSUE: The document details the notification body, and some >>>> inferences >>>> >>> >>>> can be drawn about the state from the syntax of the notification >>>> >> body. >> >>>> But this is tenuous. There should be an explicit specification of >>>> the >>>> >> >>>> state maintained, and how it is mapped onto the notification body. >>>> >>> <Ranjit-Feb16> The notifications for communication diversions are >>> sent >>> >> >>> as and when they occur depending on the filter criteria set by the >>> subscribers. So there is no need of maintaining any state >>> information for the package. >>> >> That doesn't fit my understanding of how event packages are defined. >> >> IIUC, the semantics of event packages are described relative to some >> sort of "state", not against another incoming event. (Whether this is >> literally true in the implementation or not.) >> >> So minimally, when a diversion happens, some particular information >> is culled from it, and becomes the new state. Then that causes >> notifications to the existing subscriptions. >> >> After that it either sticks around, or else the state transitions >> back to "none". But if it transitions back to "none" then that would >> trigger another round of notifications - which you clearly don't want. >> >> So it makes sense that it sticks around, in which case, when a new >> subscription comes in it will get a notification about that last >> diversion. (Unless there can be some sort of "implicit" filter that >> suppresses notification when the state becomes "none".) >> >> Adam - is that valid??? >> >> Thanks, >> Paul >> > From pkyzivat@cisco.com Fri Feb 19 12:18:06 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A4928C170 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKbGv47O8HbU for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 12:18:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BDC5C28C129 for <dispatch@ietf.org>; Fri, 19 Feb 2010 12:18:05 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIuAfktAZnwN/2dsb2JhbACbCW0GpW2XaYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="87421068" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2010 20:19:53 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKJqYQ010867 for <dispatch@ietf.org>; Fri, 19 Feb 2010 20:19:52 GMT Message-ID: <4B7EF274.6040808@cisco.com> Date: Fri, 19 Feb 2010 15:20:04 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" <dispatch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 20:18:07 -0000 -------- Original Message -------- Subject: Re: [dispatch] Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03 Date: Fri, 19 Feb 2010 08:20:28 -0600 From: Adam Roach <adam@nostrum.com> To: Avasarala Ranjit-A20990 <ranjit@motorola.com> CC: Paul Kyzivat <pkyzivat@cisco.com>, John-Luc Bakker <jbakker@rim.com> References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4B786433.1060000@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> <4B795009.7050309@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> <4B7CA748.5000709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> <4B7D9C5D.6090308@nostrum.com> <4B7DB16C.2050601@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318004@ZMY16EXM66.ds.mot.com> On 2/19/10 03:59, Feb 19, Avasarala Ranjit-A20990 wrote: > Hi Paul > > In case of IMS, the diverting system would be the Application Server > (AS) that is hosting the CDIVN service. Now if we need the concept of > state, then we need to monitor the state of the AS or the CDIVN service. > > So true as you say, we prefer the notification server to be "Stateless" > and hence it would start with "idle" state before sending a notification > information and will transition to "send" state and immediately back to > "idle" state waiting for another diversion to occur. Now when another > diversion occurs, if the notification server needs to send a > notification (depending on filter criteria), then it will transition to > "send" state to send the notification, else it will remain in "idle" > state. > > True simultaneous diversions will be serialized and the server needs to > switch back and forth between states to send multiple notifications i.e > idle->send->idle. > > > Is this ok? > I don't think so. See my other notes on the topic. /a From ankriste@cisco.com Fri Feb 19 14:38:53 2010 Return-Path: <ankriste@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4FC28C168 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 14:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL2Dl+UnYls1 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 14:38:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9AD7928C153 for <dispatch@ietf.org>; Fri, 19 Feb 2010 14:38:52 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANKhfkurRN+K/2dsb2JhbACbCXOmZ5dwhGcEgxU X-IronPort-AV: E=Sophos;i="4.49,506,1262563200"; d="scan'208";a="485681637" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2010 22:40:40 +0000 Received: from [128.107.147.3] (dhcp-128-107-147-3.cisco.com [128.107.147.3]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o1JMee5Y023343 for <dispatch@ietf.org>; Fri, 19 Feb 2010 22:40:40 GMT Message-ID: <4B7F1368.6040603@cisco.com> Date: Fri, 19 Feb 2010 14:40:40 -0800 From: Anders Kristensen <ankriste@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <4B7EF1DA.60002@cisco.com> In-Reply-To: <4B7EF1DA.60002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 22:38:53 -0000 What is the state model for KPML? Seems to me that that's just as stateless as this CDIV package. Thanks, Anders On 2/19/2010 12:17 PM, Paul Kyzivat wrote: > > > -------- Original Message -------- > Subject: Re: [dispatch] Preliminary version of Expert review > ofdraft-avasarala-dispatch-comm-div-notification-03 > Date: Thu, 18 Feb 2010 14:00:29 -0600 > From: Adam Roach <adam@nostrum.com> > To: Avasarala Ranjit-A20990 <ranjit@motorola.com> > CC: Paul Kyzivat <pkyzivat@cisco.com>, John-Luc Bakker <jbakker@rim.com> > References: <4B72716A.90006@ericsson.com> > <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> > <4B786433.1060000@cisco.com> > <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> > <4B795009.7050309@cisco.com> > <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> > <4B7CA748.5000709@cisco.com> > <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> > > > > Paul is correct. The real thrust of RFC 3265 is monitoring the state of > something. State becomes interesting at transitions (hence the focus on > events), but the events are inherently talking about the state of > something. > > In your case, I agree that it won't be call state. It appears to be > related to some combination of call diversion preferences and proxy (?) > processing state? I agree with Paul that the overall model is ill > defined (even after reading 24.604), so I can't provide any concrete > suggestions here. The best I can do is recommend you examine the > existing corpus of event packages and come to an understanding about how > they work: > > conference package IETF SIPPING Working Group [RFC4575] > consent-pending-additions package Gonzalo Camarillo [RFC5362] > dialog package IETF SIPPING Working Group [RFC4235] > kpml package Eric Burger [RFC4730] > message-summary package Rohan Mahy [RFC3842] > poc-settings package Miguel A. Garcia-Martin [RFC4354] > presence package Jonathan Rosenberg [RFC3856] > reg package Jonathan Rosenberg [RFC3680] > refer package Robert Sparks [RFC3515] > spirits-INDPs package Vijay K. Gurbani [RFC3910] > spirits-user-prof package Vijay K. Gurbani [RFC3910] > winfo template-package Jonathan Rosenberg [RFC3857] > xcap-diff package IETF Real-time Applications > [RFC-ietf-sip-xcapevent-08.txt] > and Infrastructure Area > > You'll note that every one of these event packages actually talks about > the *state* of something, and describes sending notifications when that > *state* changes. And, with the exception of the dialog event package > (and arguably the spirits-INDPs event package), you'll note that none > of these states are actual call state -- they're the state of the > resource as it pertains to the aspect that the event package monitors. > > For your proposed div-notification event package, you need to define > what this state is and how it changes. If you can't do that, then an > RFC3265 event package probably isn't the right tool for the job you have > in mind. > > /a > > On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote: >> Hi Paul, Adam >> >> Since communication diversion notification information is not related to >> any state of the actual communication, I feel there is no need to >> maintain state for this. Also the Communication diversion notification >> message gets triggered after the communication diversion has occurred. >> >> The main intent of CDIVN is to notify the subscriber of a communication >> diversion that occurred on their behalf in the network. This >> notification is not part of any communication dialog or part of the >> communication state machine and is completely independent of the actual >> communication (or call). >> >> Comments? >> >> Thanks >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, >> February 18, 2010 8:05 AM >> To: Avasarala Ranjit-A20990 >> Cc: Adam Roach; John-Luc Bakker >> Subject: Re: [dispatch] Preliminary version of Expert review >> ofdraft-avasarala-dispatch-comm-div-notification-03 >> >> Ranjit, >> >> [ taking IESG off the dist list for now, and adding Adam as the sub/not >> author. Perhaps we should take this back to the dispatch list. ] >> >> I haven't had time to read through the revised document yet, but I >> skimmed through your comments. There is one that I think we need to talk >> about because it potentially has significant impact. (I've picked the >> first place it came up, but its also mentioned in other parts of my >> issues and your responses.) >> >> Adam: Is this enough for you to understand the issue? >> >> Avasarala Ranjit-A20990 wrote: >> >>>> ISSUE: The document details the notification body, and some inferences >>>> can be drawn about the state from the syntax of the notification >> body. >>>> But this is tenuous. There should be an explicit specification of the >>>> state maintained, and how it is mapped onto the notification body. >>> <Ranjit-Feb16> The notifications for communication diversions are sent >>> as and when they occur depending on the filter criteria set by the >>> subscribers. So there is no need of maintaining any state information >>> for the package. >> That doesn't fit my understanding of how event packages are defined. >> >> IIUC, the semantics of event packages are described relative to some >> sort of "state", not against another incoming event. (Whether this is >> literally true in the implementation or not.) >> >> So minimally, when a diversion happens, some particular information is >> culled from it, and becomes the new state. Then that causes >> notifications to the existing subscriptions. >> >> After that it either sticks around, or else the state transitions back >> to "none". But if it transitions back to "none" then that would trigger >> another round of notifications - which you clearly don't want. >> >> So it makes sense that it sticks around, in which case, when a new >> subscription comes in it will get a notification about that last >> diversion. (Unless there can be some sort of "implicit" filter that >> suppresses notification when the state becomes "none".) >> >> Adam - is that valid??? >> >> Thanks, >> Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Fri Feb 19 15:42:11 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7239B3A7A59 for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 15:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZVK2FYITJzy for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 15:42:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 062B03A7B89 for <dispatch@ietf.org>; Fri, 19 Feb 2010 15:42:09 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,506,1262563200"; d="scan'208";a="87459951" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2010 23:43:57 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JNhvJt012176; Fri, 19 Feb 2010 23:43:57 GMT Message-ID: <4B7F223D.3080008@cisco.com> Date: Fri, 19 Feb 2010 18:43:57 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Anders Kristensen <ankriste@cisco.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com> In-Reply-To: <4B7F1368.6040603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 23:42:11 -0000 Anders Kristensen wrote: > What is the state model for KPML? Seems to me that that's just as > stateless as this CDIV package. Sure it does. The state consists of zero or more buffered DTMF characters. Depending on how you look at it, there may be separate state for each subscriber - which is populated with incoming dtmf characters - or else you can think of it as a single buffer with a separate starting point for each subscriber. The state is essential for the handling of resubscribes that change the filter. Thanks, Paul > Thanks, > Anders > > On 2/19/2010 12:17 PM, Paul Kyzivat wrote: >> >> >> -------- Original Message -------- >> Subject: Re: [dispatch] Preliminary version of Expert review >> ofdraft-avasarala-dispatch-comm-div-notification-03 >> Date: Thu, 18 Feb 2010 14:00:29 -0600 >> From: Adam Roach <adam@nostrum.com> >> To: Avasarala Ranjit-A20990 <ranjit@motorola.com> >> CC: Paul Kyzivat <pkyzivat@cisco.com>, John-Luc Bakker <jbakker@rim.com> >> References: <4B72716A.90006@ericsson.com> >> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> >> <4B786433.1060000@cisco.com> >> <750BBC72E178114F9DC4872EBFF29A5B0A2CD7FB@ZMY16EXM66.ds.mot.com> >> <4B795009.7050309@cisco.com> >> <750BBC72E178114F9DC4872EBFF29A5B0A2CD9EA@ZMY16EXM66.ds.mot.com> >> <4B7CA748.5000709@cisco.com> >> <750BBC72E178114F9DC4872EBFF29A5B0A317F0A@ZMY16EXM66.ds.mot.com> >> >> >> >> Paul is correct. The real thrust of RFC 3265 is monitoring the state of >> something. State becomes interesting at transitions (hence the focus on >> events), but the events are inherently talking about the state of >> something. >> >> In your case, I agree that it won't be call state. It appears to be >> related to some combination of call diversion preferences and proxy (?) >> processing state? I agree with Paul that the overall model is ill >> defined (even after reading 24.604), so I can't provide any concrete >> suggestions here. The best I can do is recommend you examine the >> existing corpus of event packages and come to an understanding about how >> they work: >> >> conference package IETF SIPPING Working Group [RFC4575] >> consent-pending-additions package Gonzalo Camarillo [RFC5362] >> dialog package IETF SIPPING Working Group [RFC4235] >> kpml package Eric Burger [RFC4730] >> message-summary package Rohan Mahy [RFC3842] >> poc-settings package Miguel A. Garcia-Martin [RFC4354] >> presence package Jonathan Rosenberg [RFC3856] >> reg package Jonathan Rosenberg [RFC3680] >> refer package Robert Sparks [RFC3515] >> spirits-INDPs package Vijay K. Gurbani [RFC3910] >> spirits-user-prof package Vijay K. Gurbani [RFC3910] >> winfo template-package Jonathan Rosenberg [RFC3857] >> xcap-diff package IETF Real-time Applications >> [RFC-ietf-sip-xcapevent-08.txt] >> and Infrastructure Area >> >> You'll note that every one of these event packages actually talks about >> the *state* of something, and describes sending notifications when that >> *state* changes. And, with the exception of the dialog event package >> (and arguably the spirits-INDPs event package), you'll note that none >> of these states are actual call state -- they're the state of the >> resource as it pertains to the aspect that the event package monitors. >> >> For your proposed div-notification event package, you need to define >> what this state is and how it changes. If you can't do that, then an >> RFC3265 event package probably isn't the right tool for the job you have >> in mind. >> >> /a >> >> On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote: >>> Hi Paul, Adam >>> >>> Since communication diversion notification information is not related to >>> any state of the actual communication, I feel there is no need to >>> maintain state for this. Also the Communication diversion notification >>> message gets triggered after the communication diversion has occurred. >>> >>> The main intent of CDIVN is to notify the subscriber of a communication >>> diversion that occurred on their behalf in the network. This >>> notification is not part of any communication dialog or part of the >>> communication state machine and is completely independent of the actual >>> communication (or call). >>> >>> Comments? >>> >>> Thanks >>> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, >>> February 18, 2010 8:05 AM >>> To: Avasarala Ranjit-A20990 >>> Cc: Adam Roach; John-Luc Bakker >>> Subject: Re: [dispatch] Preliminary version of Expert review >>> ofdraft-avasarala-dispatch-comm-div-notification-03 >>> >>> Ranjit, >>> >>> [ taking IESG off the dist list for now, and adding Adam as the sub/not >>> author. Perhaps we should take this back to the dispatch list. ] >>> >>> I haven't had time to read through the revised document yet, but I >>> skimmed through your comments. There is one that I think we need to talk >>> about because it potentially has significant impact. (I've picked the >>> first place it came up, but its also mentioned in other parts of my >>> issues and your responses.) >>> >>> Adam: Is this enough for you to understand the issue? >>> >>> Avasarala Ranjit-A20990 wrote: >>> >>>>> ISSUE: The document details the notification body, and some inferences >>>>> can be drawn about the state from the syntax of the notification >>> body. >>>>> But this is tenuous. There should be an explicit specification of the >>>>> state maintained, and how it is mapped onto the notification body. >>>> <Ranjit-Feb16> The notifications for communication diversions are sent >>>> as and when they occur depending on the filter criteria set by the >>>> subscribers. So there is no need of maintaining any state information >>>> for the package. >>> That doesn't fit my understanding of how event packages are defined. >>> >>> IIUC, the semantics of event packages are described relative to some >>> sort of "state", not against another incoming event. (Whether this is >>> literally true in the implementation or not.) >>> >>> So minimally, when a diversion happens, some particular information is >>> culled from it, and becomes the new state. Then that causes >>> notifications to the existing subscriptions. >>> >>> After that it either sticks around, or else the state transitions back >>> to "none". But if it transitions back to "none" then that would trigger >>> another round of notifications - which you clearly don't want. >>> >>> So it makes sense that it sticks around, in which case, when a new >>> subscription comes in it will get a notification about that last >>> diversion. (Unless there can be some sort of "implicit" filter that >>> suppresses notification when the state becomes "none".) >>> >>> Adam - is that valid??? >>> >>> Thanks, >>> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ankriste@cisco.com Fri Feb 19 16:28:01 2010 Return-Path: <ankriste@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06133A7EFB for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 16:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHGincxSNC-Z for <dispatch@core3.amsl.com>; Fri, 19 Feb 2010 16:28:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AA4223A7A70 for <dispatch@ietf.org>; Fri, 19 Feb 2010 16:28:00 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,506,1262563200"; d="scan'208";a="90336460" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Feb 2010 00:29:49 +0000 Received: from [128.107.147.3] (dhcp-128-107-147-3.cisco.com [128.107.147.3]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o1K0Tnqa025063; Sat, 20 Feb 2010 00:29:49 GMT Message-ID: <4B7F2CFD.8070901@cisco.com> Date: Fri, 19 Feb 2010 16:29:49 -0800 From: Anders Kristensen <ankriste@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat <pkyzivat@cisco.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com> <4B7F223D.3080008@cisco.com> In-Reply-To: <4B7F223D.3080008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 00:28:01 -0000 On 2/19/2010 3:43 PM, Paul Kyzivat wrote: > > > Anders Kristensen wrote: >> What is the state model for KPML? Seems to me that that's just as >> stateless as this CDIV package. > > Sure it does. The state consists of zero or more buffered DTMF characters. > > Depending on how you look at it, there may be separate state for each > subscriber - which is populated with incoming dtmf characters - or else > you can think of it as a single buffer with a separate starting point > for each subscriber. Well, to me all the talk of buffering feels just as a way to make it appear state oriented when really these are just events. ISTM that the KPML model of buffers could be applied to *any* non-state based event package to make it comply with the 3265 requirement that there must be some actual state underneath. (I haven't read the KPML spec in years so admittedly the details escape me.) Would you say entity tags are a good match for KPML? The notion of different state per observer or different views of the same state also doesn't make sense to me. There's just one resource being observed so it doesn't seem right that two subscriptions should have different views of the resource's state. > > The state is essential for the handling of resubscribes that change the > filter. Why can't a filter apply to events without there being any state (beyond event attributes)? Thanks, Anders From zhouzp@huawei.com Sat Feb 20 00:44:32 2010 Return-Path: <zhouzp@huawei.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A499B28C0EE for <dispatch@core3.amsl.com>; Sat, 20 Feb 2010 00:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.549 X-Spam-Level: X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88mHbjor7zlv for <dispatch@core3.amsl.com>; Sat, 20 Feb 2010 00:44:31 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4BD733A80F1 for <dispatch@ietf.org>; Sat, 20 Feb 2010 00:44:31 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY400LXQTOYB5@szxga03-in.huawei.com> for dispatch@ietf.org; Sat, 20 Feb 2010 16:46:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY4009CNTOYEM@szxga03-in.huawei.com> for dispatch@ietf.org; Sat, 20 Feb 2010 16:46:10 +0800 (CST) Received: from z54906b ([10.168.86.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY400GLITOTQH@szxml06-in.huawei.com> for dispatch@ietf.org; Sat, 20 Feb 2010 16:46:10 +0800 (CST) Date: Sat, 20 Feb 2010 16:46:05 +0800 From: zhipeng zhou <zhouzp@huawei.com> In-reply-to: <mailman.85.1266609617.27282.dispatch@ietf.org> To: dispatch@ietf.org Message-id: <03a201cab209$26830150$1856a80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqxnrOfK+c4z827Qfy/n5i3MKtgJgAaRv4w Subject: Re: [dispatch] dispatch Digest, Vol 11, Issue 33 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 08:44:32 -0000 Hi Gabor and all, I like to share my viewpoint for this excellent comment email. Gabor has listed many valuable features related to the Recording device and service. IMO, absolutely the major feature for recording is focused on the Media interaction. For example the security can be an independent solution. So from my point of view, it can focus on the media architecture and related content flow. What is your opinion. Thanks. Zhipeng -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of dispatch-request@ietf.org Sent: Saturday, February 20, 2010 4:00 AM To: dispatch@ietf.org Subject: dispatch Digest, Vol 11, Issue 33 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/dispatch Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send dispatch mailing list submissions to dispatch@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dispatch or, via email, send a message with subject or body 'help' to dispatch-request@ietf.org You can reach the person managing the list at dispatch-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dispatch digest..." Today's Topics: 1. Comments on Session Recording Protocol (Gabor Moczar) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 Feb 2010 18:56:47 +0100 From: Gabor Moczar <gmoczar@gmail.com> Subject: [dispatch] Comments on Session Recording Protocol To: dispatch@ietf.org Message-ID: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Dear Working Group Members, I am new to this list and Leon Portman from Nice suggested to send my comments on the Session Recording Protocol to here directly. I have 8+ years experience with IP based call recording solutions as a solution architect and product manager. Let me know your opinion about my comments. 1. Meta data SRP should provide a standard mechanism, which allows sending meta data in addition to the media to the RS. An extendible set of fields could describe the recorded call in a detailed way including calling party number, name, agent id, etc. Currently most implementations require implementing an additional interface using standard or proprietary CTI to obtain such kind of information. These implementations quite unique across the various platforms and considered to add additional complexity, OAM overhead and failure point to the overall solution. 2. Handling multiple media streams SRP should allow RS to select, which media stream should be recorded or not for a given session. As unified communication emerge, more and more customers using voice, video, instant messaging, etc. in their communication with their partners and clients. Customers may would like to decide, which media or which direction of the media should be recorded during the session. For compliance, probably only the voice part of a video conversation is sufficient too. 3. Security and encryption The draft very well describes the sensitivity of the topic from security point of view, however the term "encryption" is missing from the requirements part. I see that "eavesdropping protection" is used, but what is the purpose of not using the most obvious solution for "eavesdropping protection". I would also add: SRP should also allow the recording of encrypted calls. 4. Redundancy SRP should provide a mechanism to allow RCs to send the media to multiple RSs at one time. Probably endpoints with limited resources or networks with restricted bandwidth will not able to provide this feature, but in mission critical environments this could be a very nice way to provide redundancy. The failover mechanism described in the draft (and used by some of the vendors) is not protected from single point of failure. 5. Negotiating media handling capabilities SRP should allow RC and RS to negotiate audio/video codec capabilities (similar to SIP/SDP) and the RC should send media in the agreed codec. In most cases the codec will be exactly the same as the one used in the recorded session. However, high definition audio and video codecs are getting used in more and more sessions, for recording, the requirement in most cases allow to record the sessions in a lower resolution format. Either the RC, either the RS should provide transcoding capabilities. I know several video endpoints, which are able to send the video in 2 formats at one time (HD and CIF) and I can also imagine devices with on-board transcoding capabilities in the future (e.g. transcoding AAC-LD to G.729 for the RS) and some of the current implementations also allow the transcoding of the recording streams using network resources. 6. Others There are some points, which are mentioned in the use cases section, but no requirement is provided to support the given feature: - Silent monitoring and real-time applications: the entire mechanism should allow the users to implement a real-time monitoring functionality, which means that the media has to be transmitted with considerably low delay, in a real-time fashion to the RS. - Handling complex calls: SRP should provide a mechanism to allow the RS to link together certain call segments in a complex call scenario (e.g. providing a global call identifier as a part of the meta data). Best regards, Gabor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/dispatch/attachments/20100219/aedc39f0 /attachment.htm> ------------------------------ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch End of dispatch Digest, Vol 11, Issue 33 **************************************** From pkyzivat@cisco.com Sat Feb 20 07:03:26 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BECB28C10A for <dispatch@core3.amsl.com>; Sat, 20 Feb 2010 07:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkkSap5Jt5Vg for <dispatch@core3.amsl.com>; Sat, 20 Feb 2010 07:03:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5C5DE3A8155 for <dispatch@ietf.org>; Sat, 20 Feb 2010 07:03:25 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,508,1262563200"; d="scan'208";a="87537229" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Feb 2010 15:05:15 +0000 Received: from [10.86.242.72] (che-vpn-cluster-2-72.cisco.com [10.86.242.72]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1KF5F2T020583; Sat, 20 Feb 2010 15:05:15 GMT Message-ID: <4B7FFA2B.5080303@cisco.com> Date: Sat, 20 Feb 2010 10:05:15 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Anders Kristensen <ankriste@cisco.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com> <4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> In-Reply-To: <4B7F2CFD.8070901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 15:03:26 -0000 Anders, I think I will leave it to Adam, as the expert, to explain this. I have found the state model the easiest way to conceptualize the behavior. I don't think there is any fundamental requirement that this force the unnecessary retention of state - its an abstract model rather than a concrete one. In any case, for the draft at hand, I found that without such a description I can't fully understand the semantics of the package in a deterministic way. Regarding kpml - it could have been described more clearly. I agree it suggests per-subscriber state, but as I noted earlier, it can also be understood in terms of common state. These views are functionally equivalent. Thanks, Paul Anders Kristensen wrote: > > On 2/19/2010 3:43 PM, Paul Kyzivat wrote: >> >> >> Anders Kristensen wrote: >>> What is the state model for KPML? Seems to me that that's just as >>> stateless as this CDIV package. >> >> Sure it does. The state consists of zero or more buffered DTMF >> characters. >> >> Depending on how you look at it, there may be separate state for each >> subscriber - which is populated with incoming dtmf characters - or else >> you can think of it as a single buffer with a separate starting point >> for each subscriber. > > Well, to me all the talk of buffering feels just as a way to make it > appear state oriented when really these are just events. ISTM that the > KPML model of buffers could be applied to *any* non-state based event > package to make it comply with the 3265 requirement that there must be > some actual state underneath. (I haven't read the KPML spec in years so > admittedly the details escape me.) > > Would you say entity tags are a good match for KPML? > > The notion of different state per observer or different views of the > same state also doesn't make sense to me. There's just one resource > being observed so it doesn't seem right that two subscriptions should > have different views of the resource's state. > >> >> The state is essential for the handling of resubscribes that change the >> filter. > > Why can't a filter apply to events without there being any state (beyond > event attributes)? > > Thanks, > Anders > From zhouzp@huawei.com Sat Feb 20 18:42:42 2010 Return-Path: <zhouzp@huawei.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810EC28C0CF for <dispatch@core3.amsl.com>; Sat, 20 Feb 2010 18:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.398 X-Spam-Level: *** X-Spam-Status: No, score=3.398 tagged_above=-999 required=5 tests=[AWL=-2.153, BAYES_50=0.001, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKGUXniyJcvM for <dispatch@core3.amsl.com>; Sat, 20 Feb 2010 18:42:41 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 30FC43A7248 for <dispatch@ietf.org>; Sat, 20 Feb 2010 18:42:41 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY600FPV7LZ4H@szxga01-in.huawei.com> for dispatch@ietf.org; Sun, 21 Feb 2010 10:44:23 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY6007HE7LZOZ@szxga01-in.huawei.com> for dispatch@ietf.org; Sun, 21 Feb 2010 10:44:23 +0800 (CST) Received: from z54906b ([10.168.86.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY600IR97LYNR@szxml06-in.huawei.com> for dispatch@ietf.org; Sun, 21 Feb 2010 10:44:23 +0800 (CST) Date: Sun, 21 Feb 2010 10:44:22 +0800 From: zhipeng zhou <zhouzp@huawei.com> To: dispatch@ietf.org Message-id: <000301cab29f$c6651d20$1856a80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_F8kIZCbodd1y33WQVA3oxw)" Thread-index: Acqyn8XwiCbimKBQSMKi4kYWepengQ== Subject: [dispatch] A question on "draft-loreto-dispatch-disaggregated-media-01" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 21 Feb 2010 02:42:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_F8kIZCbodd1y33WQVA3oxw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Salvatore and Gonzalo: =20 After reading your newly uploaded "draft-loreto-dispatch-disaggregated-media-01", esp. your section 4,=20 I have a question as following : Since Bob's device will communicate with Alice's three devices, three channels or sessions will be available to implement this scenario. While the sentece in this document "Since this type of scenario is not covered by existing mechanisms, we propose to initiate work on SIP extensions to support it." shows that = you like to implement this scenario through a new way. So, may you pls give a rough diagram and indicate the advantage of your proposed new solution. Thanks. Zhipeng =20 ----------------------------------------------------- Huawei Software Technologies Co.,Ltd. Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China Zipcode:210012 E-Mail: <mailto:zhouzp@huawei.com> zhouzp@huawei.com Phone:(+86) 25-82276771 Fax:(+86) 25-82276760 Mobile:(+86) 13404162849 ----------------------------------------------------- =20 *************************************************************************= *** *********************************** =A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE= =AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2= =CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB= =F2 =C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA= =CE=D0=CE=CA=BD=CA=B9=D3=C3 =A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5= =D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA= =BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3 = =C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1= =A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2= =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 *************************************************************************= *** *********************************** *************************************************************************= *** *********************************** This e-mail and its attachments contain confidential information = from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the = information contained herein in any way(including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited.=20 If you receive this e-mail in error, please notify the sender by = phone or email immediately and delete it! *************************************************************************= *** *********************************** =20 --Boundary_(ID_F8kIZCbodd1y33WQVA3oxw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312"> <META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial><SPAN class=3D168382702-21022010>Hi=20 </SPAN>Salvatore <SPAN class=3D168382702-21022010>and=20 Gonzalo:</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN = class=3D168382702-21022010></SPAN></FONT> </DIV> <DIV><FONT face=3DArial><SPAN class=3D168382702-21022010>After reading = your newly=20 uploaded "draft-loreto-dispatch-disaggregated-media-01", esp. your = section 4,=20 </SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN class=3D168382702-21022010>I have a = question as=20 following :</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN class=3D168382702-21022010>Since Bob's = device will=20 communicate with Alice's three devices, three channels or sessions = will be=20 available to implement this scenario.</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN class=3D168382702-21022010>While the = sentece in this=20 document "Since this type of scenario is not covered by existing = mechanisms,=20 we<BR>   propose to initiate work on SIP extensions to support = it."=20 shows that you like to implement this scenario through a new=20 way.</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN class=3D168382702-21022010>So, may you pls = give a=20 rough diagram and  indicate the advantage of your proposed new=20 solution.</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN = class=3D168382702-21022010>Thanks.</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN = class=3D168382702-21022010>Zhipeng</SPAN></FONT></DIV> <DIV><FONT face=3DArial></FONT> </DIV><?xml:namespace prefix =3D o = ns =3D=20 "urn:schemas-microsoft-com:office:office" /><o:SmartTagType = name=3D"City"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"country-region"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"place"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype> <OBJECT id=3Dieooui = classid=3Dclsid:38481807-CA0E-42D2-BF39-B33AF135CC4D></OBJECT> <STYLE> st1\:*{behavior:url(#ieooui) } </STYLE> <STYLE> <!-- /* Font Definitions */ @font-face {font-family:=CB=CE=CC=E5; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-alt:SimSun; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:"\@=CB=CE=CC=E5"; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:Albertus; mso-font-alt:"Times New Roman"; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:auto; mso-font-signature:0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:=CB=CE=CC=E5; mso-bidi-font-family:=CB=CE=CC=E5;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline; text-underline:single;} p.section1, li.section1, div.section1 {mso-style-name:section1; mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; mso-pagination:widow-orphan; font-size:12.0pt; font-family:=CB=CE=CC=E5; mso-bidi-font-family:=CB=CE=CC=E5;} span.SpellE {mso-style-name:""; mso-spl-e:yes;} span.GramE {mso-style-name:""; mso-gram-e:yes;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt; mso-header-margin:42.55pt; mso-footer-margin:49.6pt; mso-paper-source:0;} div.Section1 {page:Section1;} --> </STYLE> <DIV class=3DSection1> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20 style=3D"mso-no-proof: yes"></SPAN><SPAN=20 lang=3DEN-US>-----------------------------------------------------</SPAN>= <SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; = mso-bidi-font-family: Arial"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: = char"><SPAN=20 lang=3DEN-US>Huawei Software Technologies Co.<SPAN=20 class=3DGramE>,Ltd</SPAN>.<o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: = char"><SPAN=20 lang=3DEN-US>Floor 2, Building A, NO.48</SPAN>=A3=AC<SPAN = class=3DSpellE><SPAN=20 lang=3DEN-US>Ning</SPAN></SPAN><SPAN lang=3DEN-US> Nan <SPAN = class=3DSpellE>AV.<SPAN=20 class=3DGramE>,<?xml:namespace prefix =3D st1 ns =3D=20 "urn:schemas-microsoft-com:office:smarttags" /><st1:City=20 w:st=3D"on">Nanjing</st1:City>, </SPAN>P.R.of</SPAN> <st1:country-region = w:st=3D"on"><st1:place=20 w:st=3D"on">China</st1:place></st1:country-region><BR>Zipcode:210012<BR>E= -Mail: <A=20 title=3Dmailto:zhangrenzhou@huawei.com = href=3D"mailto:zhouzp@huawei.com"><SPAN=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; = mso-bidi-font-family: Arial">zhouzp@huawei.com</SPAN></A><BR>Phone:(+86) = 25-82276771<BR>Fax:(+86) 25-82276760</SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: = Albertus"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: = char"><SPAN=20 class=3DGramE><SPAN lang=3DEN-US>Mobile:</SPAN></SPAN><SPAN = lang=3DEN-US>(+86)=20 13404162849<BR>-----------------------------------------------------</SPA= N><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: = Albertus"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20 lang=3DEN-US><o:p> </o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20 lang=3DEN-US>************************************************************= ***************************************************<BR></SPAN>=A1=A1=A1=A1= =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7= =E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE= =CA=BD=CA=B9=D3=C3<SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1=20 style=3D"MARGIN: 0cm 0cm = 0pt">=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7= =D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE= =D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3<SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US><SPAN=20 style=3D"mso-tab-count: 1">   =20 </SPAN></SPAN>=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC= =C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC= =FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1<SPAN=20 lang=3DEN-US><BR>********************************************************= *******************************************************</SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20 lang=3DEN-US><BR>********************************************************= *******************************************************<BR><SPAN=20 style=3D"mso-tab-count: 1">    </SPAN>This e-mail and its = attachments contain confidential information from HUAWEI, which is = intended only=20 for the</SPAN><SPAN lang=3DEN-US style=3D"FONT-SIZE: = 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US>person or entity=20 whose address is listed above. Any use of the information contained = herein in=20 any way(including,</SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US>but = not limited=20 to, total or partial disclosure, reproduction, or dissemination) by = persons=20 other than the intended</SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US>recipient(s) is=20 prohibited. </SPAN><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US><SPAN=20 style=3D"mso-tab-count: 1">    </SPAN>If you receive this = e-mail in=20 error, please notify the sender by phone or email immediately and delete = it!<BR>******************************************************************= *********************************************</SPAN></P></DIV> <DIV> </DIV></BODY></HTML> --Boundary_(ID_F8kIZCbodd1y33WQVA3oxw)-- From ranjit@motorola.com Mon Feb 22 00:55:44 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11ED028C10E for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 00:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8utVwb+qhQmJ for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 00:55:43 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 1AF8328C107 for <dispatch@ietf.org>; Mon, 22 Feb 2010 00:55:43 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1266829059!21054901!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 18548 invoked from network); 22 Feb 2010 08:57:40 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-10.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Feb 2010 08:57:40 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id o1M8vdAd021713 for <dispatch@ietf.org>; Mon, 22 Feb 2010 01:57:39 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o1M8vclR012743 for <dispatch@ietf.org>; Mon, 22 Feb 2010 02:57:38 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o1M8vSSH012644 for <dispatch@ietf.org>; Mon, 22 Feb 2010 02:57:28 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Feb 2010 16:57:05 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B7FFA2B.5080303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: AcqyPiDpsLxXeTSaSYOfBIm2Xs0d+wBXVH+w References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com>, "Anders Kristensen" <ankriste@cisco.com>, "Adam Roach" <adam@nostrum.com> X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 08:55:44 -0000 Hi all Actually for the state information to be included, I can think of state for a communication diversion notification information from either subscriber point of view or from the notifier (server) point of view. >From the subscriber point of view, the states could be whether the subscriber is subscribed and if the notifications are being generated or not. So here the state model would be Subscribed->terminated When in subscribed, the notifier can transition from idle to generate notification and to send notification and finally to idle Something like idle->generate->send->idle OR idle->generate->idle =20 In IDLE state, the notifier waits for diversions to occur. Once a diversion occurs, the notifier transitions to "GENERATE" state and looks for any filter criteria. If it finds one and it matches, then it generates the notification and transitions to "SEND" state. If there is no filter criteria, then the notifier transitions back to "IDLE" state and does not send any notification. =20 Comments? Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, February 20, 2010 8:35 PM To: Anders Kristensen Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Anders, I think I will leave it to Adam, as the expert, to explain this. I have found the state model the easiest way to conceptualize the behavior. I don't think there is any fundamental requirement that this force the unnecessary retention of state - its an abstract model rather than a concrete one. In any case, for the draft at hand, I found that without such a description I can't fully understand the semantics of the package in a deterministic way. Regarding kpml - it could have been described more clearly. I agree it suggests per-subscriber state, but as I noted earlier, it can also be understood in terms of common state. These views are functionally equivalent. Thanks, Paul Anders Kristensen wrote: >=20 > On 2/19/2010 3:43 PM, Paul Kyzivat wrote: >> >> >> Anders Kristensen wrote: >>> What is the state model for KPML? Seems to me that that's just as=20 >>> stateless as this CDIV package. >> >> Sure it does. The state consists of zero or more buffered DTMF=20 >> characters. >> >> Depending on how you look at it, there may be separate state for each >> subscriber - which is populated with incoming dtmf characters - or=20 >> else you can think of it as a single buffer with a separate starting=20 >> point for each subscriber. >=20 > Well, to me all the talk of buffering feels just as a way to make it=20 > appear state oriented when really these are just events. ISTM that the > KPML model of buffers could be applied to *any* non-state based event=20 > package to make it comply with the 3265 requirement that there must be > some actual state underneath. (I haven't read the KPML spec in years=20 > so admittedly the details escape me.) >=20 > Would you say entity tags are a good match for KPML? >=20 > The notion of different state per observer or different views of the=20 > same state also doesn't make sense to me. There's just one resource=20 > being observed so it doesn't seem right that two subscriptions should=20 > have different views of the resource's state. >=20 >> >> The state is essential for the handling of resubscribes that change=20 >> the filter. >=20 > Why can't a filter apply to events without there being any state=20 > (beyond event attributes)? >=20 > Thanks, > Anders >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Mon Feb 22 03:53:46 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3136128C1C2 for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 03:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spD0aWNFlGP2 for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 03:53:45 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D111828C1B6 for <dispatch@ietf.org>; Mon, 22 Feb 2010 03:53:44 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-963016; Mon, 22 Feb 2010 12:55:41 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id DF33123F028E; Mon, 22 Feb 2010 12:55:41 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Feb 2010 12:55:42 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Gabor Moczar <gmoczar@gmail.com>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Mon, 22 Feb 2010 12:55:41 +0100 Thread-Topic: [dispatch] Comments on Session Recording Protocol Thread-Index: AcqxjUmJWictYgJCTAagjNqFGjabQACJoc7g Message-ID: <A444A0F8084434499206E78C106220CAB93E1140@MCHP058A.global-ad.net> References: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> In-Reply-To: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Comments on Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 11:53:46 -0000 Gabor, Just addressing a few of your points below:=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gabor Moczar > Sent: 19 February 2010 17:57 > To: dispatch@ietf.org > Subject: [dispatch] Comments on Session Recording Protocol >=20 > Dear Working Group Members, >=20 > I am new to this list and Leon Portman from Nice suggested to=20 > send my comments on the Session Recording Protocol to here directly. > I have 8+ years experience with IP based call recording=20 > solutions as a solution architect and product manager. > Let me know your opinion about my comments. >=20 > 1. Meta data=20 > SRP should provide a standard mechanism, which allows sending=20 > meta data in addition to the media to the RS. An extendible=20 > set of fields could describe the recorded call in a detailed=20 > way including calling party number, name, agent id, etc.=20 > Currently most implementations require implementing an=20 > additional interface using standard or proprietary CTI to=20 > obtain such kind of information. These implementations quite=20 > unique across the various platforms and considered to add=20 > additional complexity, OAM overhead and failure point to the=20 > overall solution.=20 >=20 > 2. Handling multiple media streams=20 > SRP should allow RS to select, which media stream should be=20 > recorded or not for a given session.=20 > As unified communication emerge, more and more customers=20 > using voice, video, instant messaging, etc. in their=20 > communication with their partners and clients. Customers may=20 > would like to decide, which media or which direction of the=20 > media should be recorded during the session. For compliance,=20 > probably only the voice part of a video conversation is=20 > sufficient too.=20 >=20 > 3. Security and encryption=20 > The draft very well describes the sensitivity of the topic=20 > from security point of view, however the term "encryption" is=20 > missing from the requirements part. I see that "eavesdropping=20 > protection" is used, but what is the purpose of not using the=20 > most obvious solution for "eavesdropping protection".=20 [JRE] Encryption does not necessarily give you protection against eavesdrop= ping, e.g., if keys are too weak or are exchanged in inappropriate ways. I = would say the requirement is for protection against eavesdropping. > I would also add: SRP should also allow the recording of=20 > encrypted calls.=20 [JRE] Can you please clarify whether you mean: - recording of media in the clear, said media having been transported to/fr= om the communications partner in encrypted form; or - recording of encrypted media, so that it can be played back only with kno= wledge of the keys used for the original session? >=20 > 4. Redundancy=20 > SRP should provide a mechanism to allow RCs to send the media=20 > to multiple RSs at one time.=20 > Probably endpoints with limited resources or networks with=20 > restricted bandwidth will not able to provide this feature,=20 > but in mission critical environments this could be a very=20 > nice way to provide redundancy. The failover mechanism=20 > described in the draft (and used by some of the vendors) is=20 > not protected from single point of failure.=20 >=20 > 5. Negotiating media handling capabilities=20 > SRP should allow RC and RS to negotiate audio/video codec=20 > capabilities (similar to SIP/SDP) and the RC should send=20 > media in the agreed codec.=20 > In most cases the codec will be exactly the same as the one=20 > used in the recorded session. However, high definition audio=20 > and video codecs are getting used in more and more sessions,=20 > for recording, the requirement in most cases allow to record=20 > the sessions in a lower resolution format. Either the RC,=20 > either the RS should provide transcoding capabilities. I know=20 > several video endpoints, which are able to send the video in=20 > 2 formats at one time (HD and CIF) and I can also imagine=20 > devices with on-board transcoding capabilities in the future=20 > (e.g. transcoding AAC-LD to G.729 for the RS) and some of the=20 > current implementations also allow the transcoding of the=20 > recording streams using network resources.=20 [JRE] Yes, but bear in mind that some devices might not have resources to d= ecode and re-encode. So although we could have a requirement that allows th= e possibility of different codecs, I think there also has to be a requireme= nt to support devices that are unable to transcode. >=20 > 6. Others=20 > There are some points, which are mentioned in the use cases=20 > section, but no requirement is provided to support the given feature:=20 > - Silent monitoring and real-time applications: the entire=20 > mechanism should allow the users to implement a real-time=20 > monitoring functionality, which means that the media has to=20 > be transmitted with considerably low delay, in a real-time=20 > fashion to the RS.=20 [JRE] I think we need to be clear whether this is within scope, and if so I= would agree that some sort of requirement on timing would be appropriate. > - Handling complex calls: SRP should provide a mechanism to=20 > allow the RS to link together certain call segments in a=20 > complex call scenario (e.g. providing a global call=20 > identifier as a part of the meta data).=20 [JRE] This is a topic that has arisen in other contexts, and if a solution = is to be provided I would imagine it would fall outside the scope of the SR= P work. John From scottlawrenc@avaya.com Mon Feb 22 06:04:38 2010 Return-Path: <scottlawrenc@avaya.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1189E28C2EF for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 06:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L5k9ftcBTYZ for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 06:04:37 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id E062228C134 for <dispatch@ietf.org>; Mon, 22 Feb 2010 06:04:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,518,1262581200"; d="scan'208";a="4674033" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Feb 2010 09:06:34 -0500 X-IronPort-AV: E=Sophos;i="4.49,518,1262581200"; d="scan'208";a="448309748" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2010 09:06:34 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1ME6Dl03596; Mon, 22 Feb 2010 14:06:13 GMT Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1ME6AH21520; Mon, 22 Feb 2010 14:06:11 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 09:06:05 -0500 From: "Scott Lawrence" <scottlawrenc@avaya.com> To: Gabor Moczar <gmoczar@gmail.com> In-Reply-To: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> References: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> Content-Type: text/plain Organization: Avaya Date: Mon, 22 Feb 2010 09:06:04 -0500 Message-Id: <1266847564.20274.1276.camel@scott.home.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2010 14:06:05.0915 (UTC) FILETIME=[2CC0E2B0:01CAB3C8] Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 14:04:38 -0000 On Fri, 2010-02-19 at 18:56 +0100, Gabor Moczar wrote: > > 3. Security and encryption > The draft very well describes the sensitivity of the topic from > security point of view, however the term "encryption" is missing from > the requirements part. I see that "eavesdropping protection" is used, > but what is the purpose of not using the most obvious solution for > "eavesdropping protection". Part of what you're encountering here is just the difference in preferred language. This is a requirements document, not a solution document - it is laying out what goals a solution much achieve, and it is generally preferred that such a document _not_ specify any more than needed about how the goals are met. Encryption technologies can be used in many different ways to achieve different ends, so saying "encryption" in the context of this document would not actually specify which of those ends the encryption technology was to be employed for. By writing the requirement as "confidentiality protection" that is made explicit, and there really isn't any other way to meet that requirement (in the Internet) than encryption, but writing it this way is actually more precise. > I would also add: SRP should also allow the recording of encrypted > calls. There are a bunch of potential landmines in this area in that the IETF is very careful not to specify anything that allows an intermediate party to penetrate end-to-end confidentiality (there's that word again) without the knowledge and cooperation of the parties. That's not to say that at least some interpretations of your requirement can't be met, but it does mean that the requirement must be carefully constructed to avoid creating problems. From pkyzivat@cisco.com Mon Feb 22 16:27:39 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE8228C46F for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 16:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH1bRW0hpfFV for <dispatch@core3.amsl.com>; Mon, 22 Feb 2010 16:27:38 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EF99128C488 for <dispatch@ietf.org>; Mon, 22 Feb 2010 16:27:37 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,521,1262563200"; d="scan'208";a="88063153" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2010 00:29:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1N0Tb9I027010; Tue, 23 Feb 2010 00:29:37 GMT Message-ID: <4B832169.8090100@cisco.com> Date: Mon, 22 Feb 2010 19:29:29 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 <ranjit@motorola.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 00:27:39 -0000 Avasarala Ranjit-A20990 wrote: > Hi all > > Actually for the state information to be included, I can think of state > for a communication diversion notification information from either > subscriber point of view or from the notifier (server) point of view. I really think the state ought to be per subscribed resource (identified by the R-URI of the SUBSCRIBE when it reaches the notifier plus the event type.) The subscriber point of view really is a *view* of that. If it differs from one subscriber to another, then that really ought to be considered a filter, whether an explicit one supplied by the subscriber or an implicit one provided by the notifier based on policy. >>From the subscriber point of view, the states could be whether the > subscriber is subscribed and if the notifications are being generated or > not. So here the state model would be > > Subscribed->terminated > > When in subscribed, the notifier can transition from idle to generate > notification and to send notification and finally to idle > > Something like idle->generate->send->idle OR idle->generate->idle > > In IDLE state, the notifier waits for diversions to occur. Once a > diversion occurs, the notifier transitions to "GENERATE" state and looks > for any filter criteria. If it finds one and it matches, then it > generates the notification and transitions to "SEND" state. If there is > no filter criteria, then the notifier transitions back to "IDLE" state > and does not send any notification. I think you are not understanding the kind of state model we are talking about. Think of the state as a collection of data that may change over time, that is visible to the notifier. When something in the state changes in that state, the notifier sends a NOTIFY to subscribers, saying "the state of the resource changed, here is the new value." In the simplistic form, you could view that state as exactly the data needed to populate the body of your NOTIFY. It gets a more complicated if there can be multiple subscribers, and you don't allow them all to see all of the data. (I'm not certain if you have restrictions like that or not.) If you do, then there might be data in the state that come subscribers get and others do not. In your case, it appears from your xml, that your state consists of zero or more diversions. (Specifically it can be more than one.) And for each there an originating URI, a diverting URI, a diverted-to URI, a diverting time, and a diverting reason. But the diverting-URI is redundant - its equivalent to the resource that is the target of the subscription, and so will be constant throughout the subscription. I don't understand why it is present. My suspicion is that you have in mind that the server will serve more than one diverting user and so the *server* state consists of info for each diverting user it serves. But unless you allow a subscription to address the *server* rather than a particular diverting user, this is invisible to the state of a given resource subscription target. If I have that right, then this state changes over time as calls are diverted. In particular, a new diversion is added. Then, simplistically, each notify would contain not only the most recent diversion, but all the prior diversions as well. Or you could define it so that older diversions are removed, using any of a variety of algorithms. E.g. you might keep the most recent N of them, or all that have occurred in the last N minutes. (E.g. you might keep only the single most recent one.) But that does imply that somebody subscribing *after* a diversion has occurred will get a notification immediately with whatever that state is - say the most recent diversion, even if that occurred a long time ago. (This could be a feature, but the implementation needs to support it by retaining the state.) It starts to get messy if you don't want to retain the state. Then you must pretend that the new diversion was added to the (previously empty) state, caused notification(s), and then was immediately removed from the state. If viewed that way, the removal would also cause a notification. I suggested how that might be handled, but Adam thought it improper. Thanks, Paul From ranjit@motorola.com Tue Feb 23 02:52:02 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDDB28C169 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 02:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjiuijElZ5J0 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 02:52:01 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id CDCBF28C25E for <dispatch@ietf.org>; Tue, 23 Feb 2010 02:52:01 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1266922443!18580307!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 4561 invoked from network); 23 Feb 2010 10:54:03 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-9.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2010 10:54:03 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id o1NAs2r1011093 for <dispatch@ietf.org>; Tue, 23 Feb 2010 03:54:02 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o1NAs2AX027097 for <dispatch@ietf.org>; Tue, 23 Feb 2010 04:54:02 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o1NAs1LE027085 for <dispatch@ietf.org>; Tue, 23 Feb 2010 04:54:01 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 18:53:38 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B832169.8090100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq0H0171SMfPtxrTz6ju81vzEwaNAAVgEHQ References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 10:52:03 -0000 Hi Paul My comments <Ranjit-Feb23>=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, February 23, 2010 5:59 AM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Avasarala Ranjit-A20990 wrote: > Hi all >=20 > Actually for the state information to be included, I can think of=20 > state for a communication diversion notification information from=20 > either subscriber point of view or from the notifier (server) point of view. I really think the state ought to be per subscribed resource (identified by the R-URI of the SUBSCRIBE when it reaches the notifier plus the event type.) The subscriber point of view really is a *view* of that. If it differs from one subscriber to another, then that really ought to be considered a filter, whether an explicit one supplied by the subscriber or an implicit one provided by the notifier based on policy. >>From the subscriber point of view, the states could be whether the > subscriber is subscribed and if the notifications are being generated=20 > or not. So here the state model would be >=20 > Subscribed->terminated >=20 > When in subscribed, the notifier can transition from idle to generate=20 > notification and to send notification and finally to idle >=20 > Something like idle->generate->send->idle OR idle->generate->idle > =20 > In IDLE state, the notifier waits for diversions to occur. Once a=20 > diversion occurs, the notifier transitions to "GENERATE" state and=20 > looks for any filter criteria. If it finds one and it matches, then it > generates the notification and transitions to "SEND" state. If there=20 > is no filter criteria, then the notifier transitions back to "IDLE"=20 > state and does not send any notification. I think you are not understanding the kind of state model we are talking about. Think of the state as a collection of data that may change over time, that is visible to the notifier. When something in the state changes in that state, the notifier sends a NOTIFY to subscribers, saying "the state of the resource changed, here is the new value." <Ranjit-Feb23> In case of CDIV, the notifier triggers a NOTIFY when ever a diversion occurs and the filter criteria matches. So there is no resource as such whose value changes - except that notifier can maintain the count of number of diversions that have occurred and how many times the filter criteria matched and how many notifications were sent. So every time a notification is sent, these values get incremented. In the simplistic form, you could view that state as exactly the data needed to populate the body of your NOTIFY. <Ranjit-Feb23> Then the state needs to contain the caller details, diversion time, reason for diversion and if filter criteria matched or not. It gets a more complicated if there can be multiple subscribers, and you don't allow them all to see all of the data. (I'm not certain if you have restrictions like that or not.) If you do, then there might be data in the state that come subscribers get and others do not. <Ranjit-Feb23> No need of such a thing because a particular subscriber can only subscribe to his or her diversions and not others. In your case, it appears from your xml, that your state consists of zero or more diversions. (Specifically it can be more than one.) And for each there an originating URI, a diverting URI, a diverted-to URI, a diverting time, and a diverting reason. <Ranjit-Feb23> could be.=20 But the diverting-URI is redundant - its equivalent to the resource that is the target of the subscription, and so will be constant throughout the subscription. I don't understand why it is present. My suspicion is that you have in mind that the server will serve more than one diverting user and so the *server* state consists of info for each diverting user it serves. But unless you allow a subscription to address the *server* rather than a particular diverting user, this is invisible to the state of a given resource subscription target. <Ranjit-Feb23> Yes there is no need of diverting-URI.=20 If I have that right, then this state changes over time as calls are diverted. In particular, a new diversion is added. Then, simplistically, each notify would contain not only the most recent diversion, but all the prior diversions as well. <Ranjit-Feb23> the set of previous diversions can be taken care of by use of History-Info header. Each notification will contain information about only one diversion which gets triggered when the diversion occurs. Or you could define it so that older diversions are removed, using any of a variety of algorithms. E.g. you might keep the most recent N of them, or all that have occurred in the last N minutes. (E.g. you might keep only the single most recent one.) But that does imply that somebody subscribing *after* a diversion has occurred will get a notification immediately with whatever that state is - say the most recent diversion, even if that occurred a long time ago. (This could be a feature, but the implementation needs to support it by retaining the state.) It starts to get messy if you don't want to retain the state. Then you must pretend that the new diversion was added to the (previously empty) state, caused notification(s), and then was immediately removed from the state. If viewed that way, the removal would also cause a notification.=20 I suggested how that might be handled, but Adam thought it improper. <Ranjit-Feb23> ok. Thanks, Paul From pkyzivat@cisco.com Tue Feb 23 06:08:47 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E2B3A83C0 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 06:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmnIEEcL0hx4 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 06:08:46 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 14F4A3A837B for <dispatch@ietf.org>; Tue, 23 Feb 2010 06:08:46 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,526,1262563200"; d="scan'208";a="88216746" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2010 14:10:28 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1NEASHL002786; Tue, 23 Feb 2010 14:10:28 GMT Message-ID: <4B83E1D4.7040108@cisco.com> Date: Tue, 23 Feb 2010 09:10:28 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 <ranjit@motorola.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 14:08:47 -0000 Inline. I've trimmed out irrelevant stuff Avasarala Ranjit-A20990 wrote: > Hi Paul > > My comments <Ranjit-Feb23> > > > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > I think you are not understanding the kind of state model we are talking > about. > > Think of the state as a collection of data that may change over time, > that is visible to the notifier. When something in the state changes in > that state, the notifier sends a NOTIFY to subscribers, saying "the > state of the resource changed, here is the new value." > > <Ranjit-Feb23> In case of CDIV, the notifier triggers a NOTIFY when ever > a diversion occurs and the filter criteria matches. So there is no > resource as such whose value changes - except that notifier can maintain > the count of number of diversions that have occurred and how many times > the filter criteria matched and how many notifications were sent. So > every time a notification is sent, these values get incremented. I'm trying to find another way to conceptualize your situation - one that works better with the 3265 way of describing events. > In the simplistic form, you could view that state as exactly the data > needed to populate the body of your NOTIFY. > <Ranjit-Feb23> Then the state needs to contain the caller details, > diversion time, reason for diversion and if filter criteria matched or > not. > > It gets a more complicated if there can be multiple subscribers, and you > don't allow them all to see all of the data. (I'm not certain if you > have restrictions like that or not.) If you do, then there might be data > in the state that come subscribers get and others do not. > <Ranjit-Feb23> No need of such a thing because a particular subscriber > can only subscribe to his or her diversions and not others. OK. Then we won't worry about that. > In your case, it appears from your xml, that your state consists of zero > or more diversions. (Specifically it can be more than one.) And for each > there an originating URI, a diverting URI, a diverted-to URI, a > diverting time, and a diverting reason. > <Ranjit-Feb23> could be. > > But the diverting-URI is redundant - its equivalent to the resource that > is the target of the subscription, and so will be constant throughout > the subscription. I don't understand why it is present. My suspicion is > that you have in mind that the server will serve more than one diverting > user and so the *server* state consists of info for each diverting user > it serves. But unless you allow a subscription to address the *server* > rather than a particular diverting user, this is invisible to the state > of a given resource subscription target. > <Ranjit-Feb23> Yes there is no need of diverting-URI. OK. Then it could be removed from the notification body, and the filter too, because it is redundant. Right? Its being there confuses people like me, who assume that if its there it must have a purpose. > If I have that right, then this state changes over time as calls are > diverted. In particular, a new diversion is added. Then, simplistically, > each notify would contain not only the most recent diversion, but all > the prior diversions as well. > <Ranjit-Feb23> the set of previous diversions can be taken care of by > use of History-Info header. You are thinking of something different than I am. You are talking about previous diversions of the *same call*. I'm talking about diversions of previous calls by the same diverting user. IOW, - at 2:00 a call from alice was diverted to bob. - at 3:00 a call from carol was diverted to ted. ... Its certainly possible to *imagine* such a state, gradually increasing with time as other calls are diverted. > Each notification will contain information > about only one diversion which gets triggered when the diversion occurs. So, if my phone has been *off*, when I turn it on I won't get a notification about a diversion that occurred while it was off? Is that a feature, or a limitation of the design? If notifications of diversions are only delivered in realtime as they occur, then why do you bother to include the time of the diversion in the notification? > Or you could define it so that older diversions are removed, using any > of a variety of algorithms. E.g. you might keep the most recent N of > them, or all that have occurred in the last N minutes. (E.g. you might > keep only the single most recent one.) But that does imply that somebody > subscribing *after* a diversion has occurred will get a notification > immediately with whatever that state is - say the most recent diversion, > even if that occurred a long time ago. (This could be a feature, but the > implementation needs to support it by retaining the state.) > > It starts to get messy if you don't want to retain the state. Then you > must pretend that the new diversion was added to the (previously empty) > state, caused notification(s), and then was immediately removed from the > state. If viewed that way, the removal would also cause a notification. > I suggested how that might be handled, but Adam thought it improper. > <Ranjit-Feb23> ok. The trick here is to find a way to model the state, and the implicit and explicit filters, to achieve the sort of results you want and permit the sort of implementation you want. There are no doubt several ways that may work. I think what you need is something like: - the state consists (abstractly) of x, y, z - the state is adjusted in the following way when another call is diverted - the manner of matching a particular component in a filter against the state is ... - the manner of dealing with multiple components in a filter is ... - the manner of populating the notification body from the state is ... Thanks, Paul From salvatore.loreto@ericsson.com Tue Feb 23 06:16:19 2010 Return-Path: <salvatore.loreto@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD7128C0E0 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 06:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxJehIUj5eTb for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 06:16:14 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DE0DB3A837B for <dispatch@ietf.org>; Tue, 23 Feb 2010 06:16:13 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-b0-4b83e3a7bae4 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 34.37.01038.7A3E38B4; Tue, 23 Feb 2010 15:18:15 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 15:18:15 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 15:18:15 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E40BA24D8 for <dispatch@ietf.org>; Tue, 23 Feb 2010 16:18:14 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A5DE821A41 for <dispatch@ietf.org>; Tue, 23 Feb 2010 16:18:14 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 555B2219D2 for <dispatch@ietf.org>; Tue, 23 Feb 2010 16:18:14 +0200 (EET) Message-ID: <4B83E3A6.6080701@ericsson.com> Date: Tue, 23 Feb 2010 16:18:14 +0200 From: Salvatore Loreto <salvatore.loreto@ericsson.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <000301cab29f$c6651d20$1856a80a@china.huawei.com> In-Reply-To: <000301cab29f$c6651d20$1856a80a@china.huawei.com> Content-Type: multipart/alternative; boundary="------------070900010004000203010004" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 23 Feb 2010 14:18:15.0121 (UTC) FILETIME=[09CEA410:01CAB493] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] A question on "draft-loreto-dispatch-disaggregated-media-01" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 14:16:19 -0000 This is a multi-part message in MIME format. --------------070900010004000203010004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Zhipeng, thanks for the question. The advantage of the proposed solution is that the user does not need a device that is able to act as a controller: indeed the proposed solution give the possibility for a user to create a multimedia session combining different media streams, coming from different devices under his/her control (where none of those devices can act as a controller for the other devices in the call), so that they are treated by the far end of the session as a single media session. cheers /Sal On 02/21/2010 04:44 AM, zhipeng zhou wrote: > Hi Salvatore and Gonzalo: > After reading your newly uploaded > "draft-loreto-dispatch-disaggregated-media-01", esp. your section 4, > I have a question as following : > Since Bob's device will communicate with Alice's three devices, three > channels or sessions will be available to implement this scenario. > While the sentece in this document "Since this type of scenario is not > covered by existing mechanisms, we > propose to initiate work on SIP extensions to support it." shows > that you like to implement this scenario through a new way. > So, may you pls give a rough diagram and indicate the advantage of > your proposed new solution. > Thanks. > Zhipeng > > ----------------------------------------------------- > > Huawei Software Technologies Co.,Ltd. > > Floor 2, Building A, NO.48,Ning Nan AV., Nanjing , P.R.of China > Zipcode:210012 > E-Mail: zhouzp@huawei.com <mailto:zhouzp@huawei.com> > Phone:(+86) 25-82276771 > Fax:(+86) 25-82276760 > > Mobile:(+86) 13404162849 > ----------------------------------------------------- > > *************************************************************************************************************** > ??????????????????,?????????????????????????????????? > > (?????????????????????)???????? > > ?????????,????????????? ???????! > *************************************************************************************************************** > > > *************************************************************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the > > person or entity whose address is listed above. Any use of the > information contained herein in any way(including, > > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended > > recipient(s) is prohibited. > > If you receive this e-mail in error, please notify the sender by phone > or email immediately and delete it! > *************************************************************************************************************** > --------------070900010004000203010004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> Hi Zhipeng,<br> <br> thanks for the question.<br> <br> The advantage of the proposed solution is that the user does not need a device that is able to act as a controller:<br> <br> indeed the proposed solution give the possibility for a user to create a multimedia session combining different media streams,<br> coming from different devices under his/her control (where none of those devices can act as a controller<br> for the other devices in the call), so that they are treated by the far end of the session as a single media session.<br> <br> cheers<br> /Sal<br> <br> <br> <br> <br> On 02/21/2010 04:44 AM, zhipeng zhou wrote: <blockquote cite="mid:000301cab29f$c6651d20$1856a80a@china.huawei.com" type="cite"> <meta http-equiv="Context-Type" content="text/html; charset=gb2312"> <div> <span>Hi </span>Salvatore <span>and Gonzalo:</span> </div> <div> <span></span>  </div> <div> <span>After reading your newly uploaded "draft-loreto-dispatch-disaggregated-media-01", esp. your section 4, </span> </div> <div> <span>I have a question as following :</span> </div> <div> <span>Since Bob's device will communicate with Alice's three devices, three channels or sessions will be available to implement this scenario.</span> </div> <div> <span>While the sentece in this document "Since this type of scenario is not covered by existing mechanisms, we<br>    propose to initiate work on SIP extensions to support it." shows that you like to implement this scenario through a new way.</span> </div> <div> <span>So, may you pls give a rough diagram and  indicate the advantage of your proposed new solution.</span> </div> <div> <span>Thanks.</span> </div> <div> <span>Zhipeng</span> </div> <div>  </div> <object></object> <div> <p><span lang="EN-US"></span><span lang="EN-US">-----------------------------------------------------</span><span lang="EN-US"> </span></p> <p><span lang="EN-US">Huawei Software Technologies Co.<span>,Ltd</span>. </span></p> <p><span lang="EN-US">Floor 2, Building A, NO.48</span>，<span><span lang="EN-US">Ning</span></span><span lang="EN-US"> Nan <span>AV.<span>, Nanjing , </span>P.R.of</span> China <br> Zipcode:210012<br> E-Mail: <a moz-do-not-send="true" title="mailto:zhangrenzhou@huawei.com" href="mailto:zhouzp@huawei.com"><span>zhouzp@huawei.com</span></a><br> Phone:(+86) 25-82276771<br> Fax:(+86) 25-82276760</span><span lang="EN-US"> </span></p> <p><span><span lang="EN-US">Mobile:</span></span><span lang="EN-US">(+86) 13404162849<br> -----------------------------------------------------</span><span lang="EN-US"> </span></p> <p><span lang="EN-US">   </span></p> <p><span lang="EN-US">***************************************************************************************************************<br> </span>　　本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用<span lang="EN-US"> </span></p> <p>（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。<span lang="EN-US"> </span></p> <p><span lang="EN-US"><span>    </span></span>如果您错收了本邮件，请您立即电话或邮件通知发件 人并删除本邮件！<span lang="EN-US"><br> ***************************************************************************************************************</span></p> <p><span lang="EN-US"><br> ***************************************************************************************************************<br> <span>    </span>This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the</span><span lang="EN-US"> </span></p> <p><span lang="EN-US">person or entity whose address is listed above. Any use of the information contained herein in any way(including,</span><span lang="EN-US"> </span></p> <p><span lang="EN-US">but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended</span><span lang="EN-US"> </span></p> <p><span lang="EN-US">recipient(s) is prohibited. </span><span lang="EN-US"> </span></p> <p><span lang="EN-US"><span>    </span>If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!<br> ***************************************************************************************************************</span></p> </div> <div> </div> </blockquote> <br> </body> </html> --------------070900010004000203010004-- From ranjit@motorola.com Tue Feb 23 08:41:32 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCCC28C11B for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 08:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4U5EbS5qkX3 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 08:41:31 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 2140228C0F4 for <dispatch@ietf.org>; Tue, 23 Feb 2010 08:41:31 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-9.tower-55.messagelabs.com!1266943412!80850739!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29975 invoked from network); 23 Feb 2010 16:43:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2010 16:43:33 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o1NGhUe5025778 for <dispatch@ietf.org>; Tue, 23 Feb 2010 09:43:32 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o1NGhUJZ010649 for <dispatch@ietf.org>; Tue, 23 Feb 2010 10:43:30 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o1NGhSYp010642 for <dispatch@ietf.org>; Tue, 23 Feb 2010 10:43:29 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Feb 2010 00:43:05 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B83E1D4.7040108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq0kgZAjBlwDt01RiCunIoMcL+E9AAFFaEg References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 16:41:32 -0000 Hi Paul. Thanks for the comments. <Ranjit-Feb23-2>=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, February 23, 2010 7:40 PM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Inline. I've trimmed out irrelevant stuff Avasarala Ranjit-A20990 wrote: > Hi Paul >=20 > My comments <Ranjit-Feb23> >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > I think you are not understanding the kind of state model we are=20 > talking about. >=20 > Think of the state as a collection of data that may change over time,=20 > that is visible to the notifier. When something in the state changes=20 > in that state, the notifier sends a NOTIFY to subscribers, saying "the > state of the resource changed, here is the new value." >=20 > <Ranjit-Feb23> In case of CDIV, the notifier triggers a NOTIFY when=20 > ever a diversion occurs and the filter criteria matches. So there is=20 > no resource as such whose value changes - except that notifier can=20 > maintain the count of number of diversions that have occurred and how=20 > many times the filter criteria matched and how many notifications were > sent. So every time a notification is sent, these values get incremented. I'm trying to find another way to conceptualize your situation - one that works better with the 3265 way of describing events. > In the simplistic form, you could view that state as exactly the data=20 > needed to populate the body of your NOTIFY. > <Ranjit-Feb23> Then the state needs to contain the caller details,=20 > diversion time, reason for diversion and if filter criteria matched or > not. >=20 > It gets a more complicated if there can be multiple subscribers, and=20 > you don't allow them all to see all of the data. (I'm not certain if=20 > you have restrictions like that or not.) If you do, then there might=20 > be data in the state that come subscribers get and others do not. > <Ranjit-Feb23> No need of such a thing because a particular subscriber > can only subscribe to his or her diversions and not others. OK. Then we won't worry about that. > In your case, it appears from your xml, that your state consists of=20 > zero or more diversions. (Specifically it can be more than one.) And=20 > for each there an originating URI, a diverting URI, a diverted-to URI, > a diverting time, and a diverting reason. > <Ranjit-Feb23> could be.=20 >=20 > But the diverting-URI is redundant - its equivalent to the resource=20 > that is the target of the subscription, and so will be constant=20 > throughout the subscription. I don't understand why it is present. My=20 > suspicion is that you have in mind that the server will serve more=20 > than one diverting user and so the *server* state consists of info for > each diverting user it serves. But unless you allow a subscription to=20 > address the *server* rather than a particular diverting user, this is=20 > invisible to the state of a given resource subscription target. > <Ranjit-Feb23> Yes there is no need of diverting-URI.=20 OK. Then it could be removed from the notification body, and the filter too, because it is redundant. Right? Its being there confuses people like me, who assume that if its there it must have a purpose. > If I have that right, then this state changes over time as calls are=20 > diverted. In particular, a new diversion is added. Then,=20 > simplistically, each notify would contain not only the most recent=20 > diversion, but all the prior diversions as well. > <Ranjit-Feb23> the set of previous diversions can be taken care of by=20 > use of History-Info header. You are thinking of something different than I am. You are talking about previous diversions of the *same call*. I'm talking about diversions of previous calls by the same diverting user. IOW, - at 2:00 a call from alice was diverted to bob. - at 3:00 a call from carol was diverted to ted. ... <Ranjit-Feb23-2> Ok here as you said, the notification always contains the most recent and latest diversion that occurred and the one that matched the subscriber's filter criteria.=20 Its certainly possible to *imagine* such a state, gradually increasing with time as other calls are diverted. > Each notification will contain information about only one diversion=20 > which gets triggered when the diversion occurs. So, if my phone has been *off*, when I turn it on I won't get a notification about a diversion that occurred while it was off? Is that a feature, or a limitation of the design? <Ranjit-Feb23-2> The notifications are temporarily stored in the server when the phone is *off* and they would be sent one by one when the phone is *on*. So yes it's a feature in the server to monitor phone's status and store the notifications if required - the amount of storage could depend on server policy and some may or may not. No hard rule that they should. If they do not store, then only the latest notification would be sent. If notifications of diversions are only delivered in realtime as they occur, then why do you bother to include the time of the diversion in the notification? <Ranjit-Feb23-2> true. This makes sense only when notifications are stored and sent later (phone off scenario) > Or you could define it so that older diversions are removed, using any > of a variety of algorithms. E.g. you might keep the most recent N of=20 > them, or all that have occurred in the last N minutes. (E.g. you might > keep only the single most recent one.) But that does imply that=20 > somebody subscribing *after* a diversion has occurred will get a=20 > notification immediately with whatever that state is - say the most=20 > recent diversion, even if that occurred a long time ago. (This could=20 > be a feature, but the implementation needs to support it by retaining=20 > the state.) >=20 > It starts to get messy if you don't want to retain the state. Then you > must pretend that the new diversion was added to the (previously=20 > empty) state, caused notification(s), and then was immediately removed > from the state. If viewed that way, the removal would also cause a notification. > I suggested how that might be handled, but Adam thought it improper. > <Ranjit-Feb23> ok. The trick here is to find a way to model the state, and the implicit and explicit filters, to achieve the sort of results you want and permit the sort of implementation you want. There are no doubt several ways that may work. I think what you need is something like: - the state consists (abstractly) of x, y, z - the state is adjusted in the following way when another call is diverted - the manner of matching a particular component in a filter against the state is ... - the manner of dealing with multiple components in a filter is ... - the manner of populating the notification body from the state is ... <Ranjit-Feb23-2> need to think further on this. Thanks, Paul From gmoczar@gmail.com Tue Feb 23 08:46:11 2010 Return-Path: <gmoczar@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8B828C553 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj4ti5fys0UJ for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 08:46:10 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 691F128C319 for <dispatch@ietf.org>; Tue, 23 Feb 2010 08:45:57 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so1084585fga.13 for <dispatch@ietf.org>; Tue, 23 Feb 2010 08:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pTLXK+qL6QwzW0oFty/WiWCq1MeOHW3qkXmDLfrV23Y=; b=JgZKB7tkVnmHXJpoWojsIaG2bQQBZfxdYDt0szskWF157fyXEebGXGalc634QpgyUa ap22EHQWWGN7vdrKCoHIDc0HAAgcBRuqM5bmEGRHrDaXpbAa6CgGPg8lCF8l9xLeSaOz c/TTCjOn8PfJdMgfRSYG79Q4DLwPnC/uBHE7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nxxCYe5/O24teWOkPPXsELWCKkeAbA5RKuzXmtro7QsNeheYn1EccxdPm/xa7pmRIs 7sX8iKF120Ox4jCft0zuR9Z5gGbRRH94ehQmBJqGxoVSTWjlTH9en665FFJ6IFi7PNCS XVF7K2EApEPRtPE+QJkUQCZ3ahoPmEJ8hLWTk= MIME-Version: 1.0 Received: by 10.87.73.15 with SMTP id a15mr5030134fgl.50.1266943677099; Tue, 23 Feb 2010 08:47:57 -0800 (PST) In-Reply-To: <A444A0F8084434499206E78C106220CAB93E1140@MCHP058A.global-ad.net> References: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> <A444A0F8084434499206E78C106220CAB93E1140@MCHP058A.global-ad.net> Date: Tue, 23 Feb 2010 17:47:57 +0100 Message-ID: <6a2adf621002230847o622e81ddy8f08ea0e4d388db9@mail.gmail.com> From: Gabor Moczar <gmoczar@gmail.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com> Content-Type: multipart/alternative; boundary=001636459320d2ef390480474fcc Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] Comments on Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 16:46:12 -0000 --001636459320d2ef390480474fcc Content-Type: text/plain; charset=ISO-8859-1 THX John See my answers below. On Mon, Feb 22, 2010 at 12:55 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Gabor, > > Just addressing a few of your points below: > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gabor Moczar > > Sent: 19 February 2010 17:57 > > To: dispatch@ietf.org > > Subject: [dispatch] Comments on Session Recording Protocol > > > > Dear Working Group Members, > > > > I am new to this list and Leon Portman from Nice suggested to > > send my comments on the Session Recording Protocol to here directly. > > I have 8+ years experience with IP based call recording > > solutions as a solution architect and product manager. > > Let me know your opinion about my comments. > > > > 1. Meta data > > SRP should provide a standard mechanism, which allows sending > > meta data in addition to the media to the RS. An extendible > > set of fields could describe the recorded call in a detailed > > way including calling party number, name, agent id, etc. > > Currently most implementations require implementing an > > additional interface using standard or proprietary CTI to > > obtain such kind of information. These implementations quite > > unique across the various platforms and considered to add > > additional complexity, OAM overhead and failure point to the > > overall solution. > > > > 2. Handling multiple media streams > > SRP should allow RS to select, which media stream should be > > recorded or not for a given session. > > As unified communication emerge, more and more customers > > using voice, video, instant messaging, etc. in their > > communication with their partners and clients. Customers may > > would like to decide, which media or which direction of the > > media should be recorded during the session. For compliance, > > probably only the voice part of a video conversation is > > sufficient too. > > > > 3. Security and encryption > > The draft very well describes the sensitivity of the topic > > from security point of view, however the term "encryption" is > > missing from the requirements part. I see that "eavesdropping > > protection" is used, but what is the purpose of not using the > > most obvious solution for "eavesdropping protection". > [JRE] Encryption does not necessarily give you protection against > eavesdropping, e.g., if keys are too weak or are exchanged in inappropriate > ways. I would say the requirement is for protection against eavesdropping. > Ok. I was thinking on similar mechanism like the one used in SIP with TLS and SRTP. > > > I would also add: SRP should also allow the recording of > > encrypted calls. > [JRE] Can you please clarify whether you mean: > - recording of media in the clear, said media having been transported > to/from the communications partner in encrypted form; or > - recording of encrypted media, so that it can be played back only with > knowledge of the keys used for the original session? > > The second one. After reading Scott's comment, probably it cannot be easily incorporated into the standard, but the requirements is a real one. We had several customers asking for this feature... > > > > > 4. Redundancy > > SRP should provide a mechanism to allow RCs to send the media > > to multiple RSs at one time. > > Probably endpoints with limited resources or networks with > > restricted bandwidth will not able to provide this feature, > > but in mission critical environments this could be a very > > nice way to provide redundancy. The failover mechanism > > described in the draft (and used by some of the vendors) is > > not protected from single point of failure. > > > > 5. Negotiating media handling capabilities > > SRP should allow RC and RS to negotiate audio/video codec > > capabilities (similar to SIP/SDP) and the RC should send > > media in the agreed codec. > > In most cases the codec will be exactly the same as the one > > used in the recorded session. However, high definition audio > > and video codecs are getting used in more and more sessions, > > for recording, the requirement in most cases allow to record > > the sessions in a lower resolution format. Either the RC, > > either the RS should provide transcoding capabilities. I know > > several video endpoints, which are able to send the video in > > 2 formats at one time (HD and CIF) and I can also imagine > > devices with on-board transcoding capabilities in the future > > (e.g. transcoding AAC-LD to G.729 for the RS) and some of the > > current implementations also allow the transcoding of the > > recording streams using network resources. > [JRE] Yes, but bear in mind that some devices might not have resources to > decode and re-encode. So although we could have a requirement that allows > the possibility of different codecs, I think there also has to be a > requirement to support devices that are unable to transcode. > > Agree. > > > > 6. Others > > There are some points, which are mentioned in the use cases > > section, but no requirement is provided to support the given feature: > > - Silent monitoring and real-time applications: the entire > > mechanism should allow the users to implement a real-time > > monitoring functionality, which means that the media has to > > be transmitted with considerably low delay, in a real-time > > fashion to the RS. > [JRE] I think we need to be clear whether this is within scope, and if so I > would agree that some sort of requirement on timing would be appropriate. > > > - Handling complex calls: SRP should provide a mechanism to > > allow the RS to link together certain call segments in a > > complex call scenario (e.g. providing a global call > > identifier as a part of the meta data). > [JRE] This is a topic that has arisen in other contexts, and if a solution > is to be provided I would imagine it would fall outside the scope of the SRP > work. > I think, it is a very important feature, but I am aware of the differences among the various platforms/vendors, so probably not all of them can meet this requirement. If this feature is not included in the standard, recorder vendors will be forced to implement or use existing TAPI/JTAPI/DMCC/etc. interfaces, which should be avoided in my opinion... > > John > --001636459320d2ef390480474fcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>THX John</div><div>See my answers below.</div><br><div class=3D"gmail_= quote">On Mon, Feb 22, 2010 at 12:55 PM, Elwell, John <span dir=3D"ltr"><= ;<a href=3D"mailto:john.elwell@siemens-enterprise.com" target=3D"_blank">jo= hn.elwell@siemens-enterprise.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Gabor,<br> <br> Just addressing a few of your points below:<br> <div><div></div><div><br> > -----Original Message-----<br> > From: <a href=3D"mailto:dispatch-bounces@ietf.org" target=3D"_blank">d= ispatch-bounces@ietf.org</a><br> > [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org" target=3D"_blank"= >dispatch-bounces@ietf.org</a>] On Behalf Of Gabor Moczar<br> > Sent: 19 February 2010 17:57<br> > To: <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ie= tf.org</a><br> > Subject: [dispatch] Comments on Session Recording Protocol<br> ><br> > Dear Working Group Members,<br> ><br> > I am new to this list and Leon Portman from Nice suggested to<br> > send my comments on the Session Recording Protocol to here directly.<b= r> > I have 8+ years experience with IP based call recording<br> > solutions as a solution architect and product manager.<br> > Let me know your opinion about my comments.<br> ><br> > 1. Meta data<br> > SRP should provide a standard mechanism, which allows sending<br> > meta data in addition to the media to the RS. An extendible<br> > set of fields could describe the recorded call in a detailed<br> > way including calling party number, name, agent id, etc.<br> > Currently most implementations require implementing an<br> > additional interface using standard or proprietary CTI to<br> > obtain such kind of information. These implementations quite<br> > unique across the various platforms and considered to add<br> > additional complexity, OAM overhead and failure point to the<br> > overall solution.<br> ><br> > 2. Handling multiple media streams<br> > SRP should allow RS to select, which media stream should be<br> > recorded or not for a given session.<br> > As unified communication emerge, more and more customers<br> > using voice, video, instant messaging, etc. in their<br> > communication with their partners and clients. Customers may<br> > would like to decide, which media or which direction of the<br> > media should be recorded during the session. For compliance,<br> > probably only the voice part of a video conversation is<br> > sufficient too.<br> ><br> > 3. Security and encryption<br> > The draft very well describes the sensitivity of the topic<br> > from security point of view, however the term "encryption" i= s<br> > missing from the requirements part. I see that "eavesdropping<br> > protection" is used, but what is the purpose of not using the<br> > most obvious solution for "eavesdropping protection".<br> </div></div>[JRE] Encryption does not necessarily give you protection again= st eavesdropping, e.g., if keys are too weak or are exchanged in inappropri= ate ways. I would say the requirement is for protection against eavesdroppi= ng.<br> </blockquote><div>Ok. I was thinking on similar mechanism like the one used= in SIP with TLS and SRTP.</div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><br> > I would also add: SRP should also allow the recording of<br> > encrypted calls.<br> </div>[JRE] Can you please clarify whether you mean:<br> - recording of media in the clear, said media having been transported to/fr= om the communications partner in encrypted form; or<br> - recording of encrypted media, so that it can be played back only with kno= wledge of the keys used for the original session?<br> <div><div></div><div><br></div></div></blockquote><div>The second one. Afte= r reading Scott's comment, probably it cannot be easily incorporated in= to the standard, but the requirements is a real one. We had several custome= rs asking for this feature...</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div><div> <br> ><br> > 4. Redundancy<br> > SRP should provide a mechanism to allow RCs to send the media<br> > to multiple RSs at one time.<br> > Probably endpoints with limited resources or networks with<br> > restricted bandwidth will not able to provide this feature,<br> > but in mission critical environments this could be a very<br> > nice way to provide redundancy. The failover mechanism<br> > described in the draft (and used by some of the vendors) is<br> > not protected from single point of failure.<br> ><br> > 5. Negotiating media handling capabilities<br> > SRP should allow RC and RS to negotiate audio/video codec<br> > capabilities (similar to SIP/SDP) and the RC should send<br> > media in the agreed codec.<br> > In most cases the codec will be exactly the same as the one<br> > used in the recorded session. However, high definition audio<br> > and video codecs are getting used in more and more sessions,<br> > for recording, the requirement in most cases allow to record<br> > the sessions in a lower resolution format. Either the RC,<br> > either the RS should provide transcoding capabilities. I know<br> > several video endpoints, which are able to send the video in<br> > 2 formats at one time (HD and CIF) and I can also imagine<br> > devices with on-board transcoding capabilities in the future<br> > (e.g. transcoding AAC-LD to G.729 for the RS) and some of the<br> > current implementations also allow the transcoding of the<br> > recording streams using network resources.<br> </div></div>[JRE] Yes, but bear in mind that some devices might not have re= sources to decode and re-encode. So although we could have a requirement th= at allows the possibility of different codecs, I think there also has to be= a requirement to support devices that are unable to transcode.<br> <div><br></div></blockquote><div>Agree.=A0</div><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex"><div> ><br> > 6. Others<br> > There are some points, which are mentioned in the use cases<br> > section, but no requirement is provided to support the given feature:<= br> > - Silent monitoring and real-time applications: the entire<br> > mechanism should allow the users to implement a real-time<br> > monitoring functionality, which means that the media has to<br> > be transmitted with considerably low delay, in a real-time<br> > fashion to the RS.<br> </div>[JRE] I think we need to be clear whether this is within scope, and i= f so I would agree that some sort of requirement on timing would be appropr= iate.<br> <div><br> > - Handling complex calls: SRP should provide a mechanism to<br> > allow the RS to link together certain call segments in a<br> > complex call scenario (e.g. providing a global call<br> > identifier as a part of the meta data).<br> </div>[JRE] This is a topic that has arisen in other contexts, and if a sol= ution is to be provided I would imagine it would fall outside the scope of = the SRP work.<br></blockquote><div>I think, it is a very important feature,= but I am aware of the=A0differences=A0among the various platforms/vendors,= so probably not all of them can meet this requirement. If this feature is = not included in the standard, recorder vendors will be forced to implement = or use existing TAPI/JTAPI/DMCC/etc. interfaces, which should be avoided in= my opinion...</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <font color=3D"#888888"><br> John<br> </font></blockquote></div><br> --001636459320d2ef390480474fcc-- From gmoczar@gmail.com Tue Feb 23 08:52:06 2010 Return-Path: <gmoczar@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2890C28C31D for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 08:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EsGadWlIrcf for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 08:52:05 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id CF13828C317 for <dispatch@ietf.org>; Tue, 23 Feb 2010 08:52:04 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so1086690fga.13 for <dispatch@ietf.org>; Tue, 23 Feb 2010 08:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vUw7mYPnsw88+S3MdEfLrubR8tTDW2CT3GunaRP4G9c=; b=BXQ0Qh0w1tvKh9rR/psDBpzGm0TNU+JI7qWkD1bWBS0EU75IjGPjYRBlFZBlE7f0c1 P4FGLq45asDTOdxkv3My3YJcMULEWWXbWzcOet31YXwX0MMJRbHxob4Trd/lTx1aYMIR zc2qkzenlBESAV8yz1sDdwvIaSFrdqgzpQnqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Tl/LabTBSPYDTxrkc2+lNcbjyFOu8HJo5rmsDv2bjsMenAetGI6DJ29e6Ka+Hg715S fj2T6CX6lwjsCfRr4GxwoD438rsQuUWTqrGdRe67H/e9XYoZORJJWjkKYJjkU0t9GieJ ZrNTu8uASKDsV+n2MSsnHBOe99QmbcWwWIXIU= MIME-Version: 1.0 Received: by 10.86.233.20 with SMTP id f20mr7696804fgh.30.1266944042874; Tue, 23 Feb 2010 08:54:02 -0800 (PST) In-Reply-To: <1266847564.20274.1276.camel@scott.home.skrb.org> References: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> <1266847564.20274.1276.camel@scott.home.skrb.org> Date: Tue, 23 Feb 2010 17:54:02 +0100 Message-ID: <6a2adf621002230854h70e00126lc81e54c807d10a82@mail.gmail.com> From: Gabor Moczar <gmoczar@gmail.com> To: Scott Lawrence <scottlawrenc@avaya.com> Content-Type: multipart/alternative; boundary=001485f33beca0385a04804765ce Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 16:52:06 -0000 --001485f33beca0385a04804765ce Content-Type: text/plain; charset=ISO-8859-1 THX Scott for the detailed clarification and I am now fully aware of the appropriate terminology required at this stage. I agree that the "recording of encrypted calls" topic is a very sensitive one, but as I previously wrote to John, the requirement is from real customers... On Mon, Feb 22, 2010 at 3:06 PM, Scott Lawrence <scottlawrenc@avaya.com>wrote: > On Fri, 2010-02-19 at 18:56 +0100, Gabor Moczar wrote: > > > > 3. Security and encryption > > > The draft very well describes the sensitivity of the topic from > > security point of view, however the term "encryption" is missing from > > the requirements part. I see that "eavesdropping protection" is used, > > but what is the purpose of not using the most obvious solution for > > "eavesdropping protection". > > Part of what you're encountering here is just the difference in > preferred language. This is a requirements document, not a solution > document - it is laying out what goals a solution much achieve, and it > is generally preferred that such a document _not_ specify any more than > needed about how the goals are met. > > Encryption technologies can be used in many different ways to achieve > different ends, so saying "encryption" in the context of this document > would not actually specify which of those ends the encryption technology > was to be employed for. By writing the requirement as "confidentiality > protection" that is made explicit, and there really isn't any other way > to meet that requirement (in the Internet) than encryption, but writing > it this way is actually more precise. > > > I would also add: SRP should also allow the recording of encrypted > > calls. > > There are a bunch of potential landmines in this area in that the IETF > is very careful not to specify anything that allows an intermediate > party to penetrate end-to-end confidentiality (there's that word again) > without the knowledge and cooperation of the parties. That's not to say > that at least some interpretations of your requirement can't be met, but > it does mean that the requirement must be carefully constructed to avoid > creating problems. > > > --001485f33beca0385a04804765ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable THX Scott for the detailed clarification and I am now fully aware of the=A0= appropriate terminology required=A0at this stage.<div>I agree that the &quo= t;recording of encrypted calls" topic is a very sensitive one, but as = I previously wrote to John, the requirement is from real customers...<br> <br><div class=3D"gmail_quote">On Mon, Feb 22, 2010 at 3:06 PM, Scott Lawre= nce <span dir=3D"ltr"><<a href=3D"mailto:scottlawrenc@avaya.com">scottla= wrenc@avaya.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Fri, 2010-02-19 at 18:56 +0100, Gabor Moczar wrote:<br= > ><br> > 3. Security and encryption<br> <br> > The draft very well describes the sensitivity of the topic from<br> > security point of view, however the term "encryption" is mis= sing from<br> > the requirements part. I see that "eavesdropping protection"= is used,<br> > but what is the purpose of not using the most obvious solution for<br> > "eavesdropping protection".<br> <br> </div>Part of what you're encountering here is just the difference in<b= r> preferred language. =A0This is a requirements document, not a solution<br> document - it is laying out what goals a solution much achieve, and it<br> is generally preferred that such a document _not_ specify any more than<br> needed about how the goals are met.<br> <br> Encryption technologies can be used in many different ways to achieve<br> different ends, so saying "encryption" in the context of this doc= ument<br> would not actually specify which of those ends the encryption technology<br= > was to be employed for. =A0By writing the requirement as "confidential= ity<br> protection" that is made explicit, and there really isn't any othe= r way<br> to meet that requirement (in the Internet) than encryption, but writing<br> it this way is actually more precise.<br> <div class=3D"im"><br> > =A0I would also add: SRP should also allow the recording of encrypted<= br> > calls.<br> <br> </div>There are a bunch of potential landmines in this area in that the IET= F<br> is very careful not to specify anything that allows an intermediate<br> party to penetrate end-to-end confidentiality (there's that word again)= <br> without the knowledge and cooperation of the parties. =A0That's not to = say<br> that at least some interpretations of your requirement can't be met, bu= t<br> it does mean that the requirement must be carefully constructed to avoid<br= > creating problems.<br> <br> <br> </blockquote></div><br></div> --001485f33beca0385a04804765ce-- From john.elwell@siemens-enterprise.com Tue Feb 23 09:07:39 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8306E28C321 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 09:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq5j1QyZj757 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 09:07:38 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4EC2328C324 for <dispatch@ietf.org>; Tue, 23 Feb 2010 09:07:37 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-985593; Tue, 23 Feb 2010 18:09:40 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 1F3FE1EB82AB; Tue, 23 Feb 2010 18:09:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 23 Feb 2010 18:09:40 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Gabor Moczar <gmoczar@gmail.com> Date: Tue, 23 Feb 2010 18:09:39 +0100 Thread-Topic: [dispatch] Comments on Session Recording Protocol Thread-Index: Acq0p/QQDmXZgpiMRUKLdNfZnjzeKwAANaXQ Message-ID: <A444A0F8084434499206E78C106220CABB8E6D22@MCHP058A.global-ad.net> References: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> <A444A0F8084434499206E78C106220CAB93E1140@MCHP058A.global-ad.net> <6a2adf621002230847o622e81ddy8f08ea0e4d388db9@mail.gmail.com> In-Reply-To: <6a2adf621002230847o622e81ddy8f08ea0e4d388db9@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] Comments on Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 17:07:39 -0000 Gabor, More on a couple of topics: > -----Original Message----- > From: Gabor Moczar [mailto:gmoczar@gmail.com]=20 > Sent: 23 February 2010 16:48 > To: Elwell, John > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on Session Recording Protocol >=20 > > > > 3. Security and encryption > > The draft very well describes the sensitivity of the topic > > from security point of view, however the term "encryption" is > > missing from the requirements part. I see that "eavesdropping > > protection" is used, but what is the purpose of not using the > > most obvious solution for "eavesdropping protection". > =09 > [JRE] Encryption does not necessarily give you=20 > protection against eavesdropping, e.g., if keys are too weak=20 > or are exchanged in inappropriate ways. I would say the=20 > requirement is for protection against eavesdropping. > =09 >=20 > Ok. I was thinking on similar mechanism like the one used in=20 > SIP with TLS and SRTP. [JRE] Sure, that might be a solution, but the requirement is prevention of = eavesdropping. >=20 >=20 > > I would also add: SRP should also allow the recording of > > encrypted calls. > =09 > [JRE] Can you please clarify whether you mean: > - recording of media in the clear, said media having=20 > been transported to/from the communications partner in=20 > encrypted form; or > - recording of encrypted media, so that it can be=20 > played back only with knowledge of the keys used for the=20 > original session? > =09 >=20 >=20 > The second one. After reading Scott's comment, probably it=20 > cannot be easily incorporated into the standard, but the=20 > requirements is a real one. We had several customers asking=20 > for this feature... [JRE] There are actually 3 points at which media can be encrypted: - during transmission as part of the original communication session; - during transmission as part of the media replication session from recordi= ng client to recording server; - during storage on the recording server (and subsequent retrieval for play= back purposes, although this is getting somewhat beyond the scope of the pr= oposed charter). I think you are asking that it be encrypted once and remain encrypted for a= ll three stages. If we are talking real-time media transported with SRTP, there is a problem= , because SRTP is tightly coupled to the RTP transport for the session conc= erned. This makes it unsuitable for store and forward use, as discussed in = draft-mattsson-srtp-store-and-forward. Similarly, it makes it unsuitable fo= r use across two separate RTP sessions. It seems to me to be necessary to d= ecrypt SRTP from the communication session at the recording client, and the= n re-encrypt for transmission to the recording server, and then decrypt an= d re-encrypt again for storage, and so on. Possibly the 2nd and 3rd stages = could be dealt with in one go using a technique such as in draft-naslund-sr= tp-saf, but it is unlikely that the first stage could be combined, since th= is would requiring cooperation of the remote party's UA. John From gmoczar@gmail.com Tue Feb 23 09:25:15 2010 Return-Path: <gmoczar@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD0128C15F for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 09:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLmirfR7kh+I for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 09:25:14 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id B503C28B56A for <dispatch@ietf.org>; Tue, 23 Feb 2010 09:25:13 -0800 (PST) Received: by fxm5 with SMTP id 5so4239261fxm.29 for <dispatch@ietf.org>; Tue, 23 Feb 2010 09:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1fLoHMQZrgv1AhpnCn2KugO2hy2pJXiCjwTisPHVXjM=; b=SnfV1M/I+ApW0ynBFURZjZs3kCO2kbc0cLqzpze6apMSXvLkUBrC9CBTsaXQKpD7b/ 7fzkOL4DD/AzuVaWJ6pkX+KQmRSyZYrDUstT2zWfQ3mf7USdmtw0kIE486eUEbAWt9Yc BbaoDrc/25hU8gkcHW5bEH32assuYZh0A7Leg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m5i6OgdMY9rHNop4ex449GVchn4lsKKGowAdysdIrJqFv0fysb8n2rPmok+oii88Lz UCsZQOMlO4PFQPvtCOKuwIwrotE6OHejMEgSxymmmuu8yw1W3ce8uD4KgDevP7Ob+9Xx k5RsVxZGLnm+Izd+DSpuvYNQzeHHElF85br0E= MIME-Version: 1.0 Received: by 10.86.106.7 with SMTP id e7mr9781775fgc.1.1266946028240; Tue, 23 Feb 2010 09:27:08 -0800 (PST) In-Reply-To: <A444A0F8084434499206E78C106220CABB8E6D22@MCHP058A.global-ad.net> References: <6a2adf621002190956jae37f66i791acbf627095007@mail.gmail.com> <A444A0F8084434499206E78C106220CAB93E1140@MCHP058A.global-ad.net> <6a2adf621002230847o622e81ddy8f08ea0e4d388db9@mail.gmail.com> <A444A0F8084434499206E78C106220CABB8E6D22@MCHP058A.global-ad.net> Date: Tue, 23 Feb 2010 18:27:08 +0100 Message-ID: <6a2adf621002230927n5aa0d3cduab1edfee59da9461@mail.gmail.com> From: Gabor Moczar <gmoczar@gmail.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com> Content-Type: multipart/alternative; boundary=001636c5b467f703b9048047dba2 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] Comments on Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 17:25:15 -0000 --001636c5b467f703b9048047dba2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 23, 2010 at 6:09 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Gabor, > > More on a couple of topics: > > > -----Original Message----- > > From: Gabor Moczar [mailto:gmoczar@gmail.com] > > Sent: 23 February 2010 16:48 > > To: Elwell, John > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Comments on Session Recording Protocol > > > > > > > > 3. Security and encryption > > > The draft very well describes the sensitivity of the topic > > > from security point of view, however the term "encryption" is > > > missing from the requirements part. I see that "eavesdropping > > > protection" is used, but what is the purpose of not using the > > > most obvious solution for "eavesdropping protection". > > > > [JRE] Encryption does not necessarily give you > > protection against eavesdropping, e.g., if keys are too weak > > or are exchanged in inappropriate ways. I would say the > > requirement is for protection against eavesdropping. > > > > > > Ok. I was thinking on similar mechanism like the one used in > > SIP with TLS and SRTP. > [JRE] Sure, that might be a solution, but the requirement is prevention of > eavesdropping. > > > > > > > > > I would also add: SRP should also allow the recording of > > > encrypted calls. > > > > [JRE] Can you please clarify whether you mean: > > - recording of media in the clear, said media having > > been transported to/from the communications partner in > > encrypted form; or > > - recording of encrypted media, so that it can be > > played back only with knowledge of the keys used for the > > original session? > > > > > > > > The second one. After reading Scott's comment, probably it > > cannot be easily incorporated into the standard, but the > > requirements is a real one. We had several customers asking > > for this feature... > [JRE] There are actually 3 points at which media can be encrypted: > - during transmission as part of the original communication session; > - during transmission as part of the media replication session from > recording client to recording server; > - during storage on the recording server (and subsequent retrieval for > playback purposes, although this is getting somewhat beyond the scope of the > proposed charter). > > I think you are asking that it be encrypted once and remain encrypted for > all three stages. > > If we are talking real-time media transported with SRTP, there is a > problem, because SRTP is tightly coupled to the RTP transport for the > session concerned. This makes it unsuitable for store and forward use, as > discussed in draft-mattsson-srtp-store-and-forward. Similarly, it makes it > unsuitable for use across two separate RTP sessions. It seems to me to be > necessary to decrypt SRTP from the communication session at the recording > client, and then re-encrypt for transmission to the recording server, and > then decrypt and re-encrypt again for storage, and so on. Possibly the 2nd > and 3rd stages could be dealt with in one go using a technique such as in > draft-naslund-srtp-saf, but it is unlikely that the first stage could be > combined, since this would requiring cooperation of the remote party's UA. > You are right. The implementations, I am aware, do exactly the same thing you described: re-encrypt for transmission to the RS with new keys. Storing recordings in an encrypted format is a kind of must have feature on the market, but I agree, it is out of scope of this work. > > John > --001636c5b467f703b9048047dba2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, Feb 23, 2010 at 6:09 PM, Elwell,= John <span dir=3D"ltr"><<a href=3D"mailto:john.elwell@siemens-enterpris= e.com">john.elwell@siemens-enterprise.com</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex;"> Gabor,<br> <br> More on a couple of topics:<br> <div class=3D"im"><br> > -----Original Message-----<br> > From: Gabor Moczar [mailto:<a href=3D"mailto:gmoczar@gmail.com">gmocza= r@gmail.com</a>]<br> > Sent: 23 February 2010 16:48<br> > To: Elwell, John<br> > Cc: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> > Subject: Re: [dispatch] Comments on Session Recording Protocol<br> ><br> > =A0 =A0 =A0 ><br> > =A0 =A0 =A0 > 3. Security and encryption<br> > =A0 =A0 =A0 > The draft very well describes the sensitivity of the = topic<br> > =A0 =A0 =A0 > from security point of view, however the term "e= ncryption" is<br> > =A0 =A0 =A0 > missing from the requirements part. I see that "= eavesdropping<br> > =A0 =A0 =A0 > protection" is used, but what is the purpose of = not using the<br> > =A0 =A0 =A0 > most obvious solution for "eavesdropping protect= ion".<br> ><br> > =A0 =A0 =A0 [JRE] Encryption does not necessarily give you<br> > protection against eavesdropping, e.g., if keys are too weak<br> > or are exchanged in inappropriate ways. I would say the<br> > requirement is for protection against eavesdropping.<br> ><br> ><br> > Ok. I was thinking on similar mechanism like the one used in<br> > SIP with TLS and SRTP.<br> </div>[JRE] Sure, that might be a solution, but the requirement is preventi= on of eavesdropping.<br> <div class=3D"im"><br> <br> ><br> ><br> > =A0 =A0 =A0 > I would also add: SRP should also allow the recording= of<br> > =A0 =A0 =A0 > encrypted calls.<br> ><br> > =A0 =A0 =A0 [JRE] Can you please clarify whether you mean:<br> > =A0 =A0 =A0 - recording of media in the clear, said media having<br> > been transported to/from the communications partner in<br> > encrypted form; or<br> > =A0 =A0 =A0 - recording of encrypted media, so that it can be<br> > played back only with knowledge of the keys used for the<br> > original session?<br> ><br> ><br> ><br> > The second one. After reading Scott's comment, probably it<br> > cannot be easily incorporated into the standard, but the<br> > requirements is a real one. We had several customers asking<br> > for this feature...<br> </div>[JRE] There are actually 3 points at which media can be encrypted:<br= > - during transmission as part of the original communication session;<br> - during transmission as part of the media replication session from recordi= ng client to recording server;<br> - during storage on the recording server (and subsequent retrieval for play= back purposes, although this is getting somewhat beyond the scope of the pr= oposed charter).<br> <br> I think you are asking that it be encrypted once and remain encrypted for a= ll three stages.<br> <br> If we are talking real-time media transported with SRTP, there is a problem= , because SRTP is tightly coupled to the RTP transport for the session conc= erned. This makes it unsuitable for store and forward use, as discussed in = draft-mattsson-srtp-store-and-forward. Similarly, it makes it unsuitable fo= r use across two separate RTP sessions. It seems to me to be necessary to d= ecrypt SRTP from the communication session at the recording client, and the= n re-encrypt for transmission =A0to the recording server, and then decrypt = and re-encrypt again for storage, and so on. Possibly the 2nd and 3rd stage= s could be dealt with in one go using a technique such as in draft-naslund-= srtp-saf, but it is unlikely that the first stage could be combined, since = this would requiring cooperation of the remote party's UA.<br> </blockquote><div><br></div><div>You are right. The implementations, I am a= ware, do exactly the same thing you described: re-encrypt for transmission = to the RS with new keys.</div><div>Storing recordings in an encrypted forma= t is a kind of must have feature on the market, but I agree, it is out of s= cope of this work.=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <font color=3D"#888888"><br> John<br> </font></blockquote></div><br> --001636c5b467f703b9048047dba2-- From pkyzivat@cisco.com Tue Feb 23 10:46:18 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5691A3A84CF for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 10:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK-anlVQ-dpF for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 10:46:17 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7D7F028C130 for <dispatch@ietf.org>; Tue, 23 Feb 2010 10:46:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,527,1262563200"; d="scan'208";a="88328303" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2010 18:48:06 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1NIm6FC012880; Tue, 23 Feb 2010 18:48:06 GMT Message-ID: <4B8422E6.1060709@cisco.com> Date: Tue, 23 Feb 2010 13:48:06 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 <ranjit@motorola.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 18:46:18 -0000 Avasarala Ranjit-A20990 wrote: > Hi Paul. > > Thanks for the comments. <Ranjit-Feb23-2> > > > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 23, 2010 7:40 PM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review > ofdraft-avasarala-dispatch-comm-div-notification-03] > > Inline. I've trimmed out irrelevant stuff > > Avasarala Ranjit-A20990 wrote: >> Hi Paul >> >> My comments <Ranjit-Feb23> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> I think you are not understanding the kind of state model we are >> talking about. >> >> Think of the state as a collection of data that may change over time, >> that is visible to the notifier. When something in the state changes >> in that state, the notifier sends a NOTIFY to subscribers, saying "the > >> state of the resource changed, here is the new value." >> >> <Ranjit-Feb23> In case of CDIV, the notifier triggers a NOTIFY when >> ever a diversion occurs and the filter criteria matches. So there is >> no resource as such whose value changes - except that notifier can >> maintain the count of number of diversions that have occurred and how >> many times the filter criteria matched and how many notifications were > >> sent. So every time a notification is sent, these values get > incremented. > > I'm trying to find another way to conceptualize your situation - one > that works better with the 3265 way of describing events. > >> In the simplistic form, you could view that state as exactly the data >> needed to populate the body of your NOTIFY. >> <Ranjit-Feb23> Then the state needs to contain the caller details, >> diversion time, reason for diversion and if filter criteria matched or > >> not. >> >> It gets a more complicated if there can be multiple subscribers, and >> you don't allow them all to see all of the data. (I'm not certain if >> you have restrictions like that or not.) If you do, then there might >> be data in the state that come subscribers get and others do not. >> <Ranjit-Feb23> No need of such a thing because a particular subscriber > >> can only subscribe to his or her diversions and not others. > > OK. Then we won't worry about that. > >> In your case, it appears from your xml, that your state consists of >> zero or more diversions. (Specifically it can be more than one.) And >> for each there an originating URI, a diverting URI, a diverted-to URI, > >> a diverting time, and a diverting reason. >> <Ranjit-Feb23> could be. >> >> But the diverting-URI is redundant - its equivalent to the resource >> that is the target of the subscription, and so will be constant >> throughout the subscription. I don't understand why it is present. My >> suspicion is that you have in mind that the server will serve more >> than one diverting user and so the *server* state consists of info for > >> each diverting user it serves. But unless you allow a subscription to >> address the *server* rather than a particular diverting user, this is >> invisible to the state of a given resource subscription target. >> <Ranjit-Feb23> Yes there is no need of diverting-URI. > > OK. Then it could be removed from the notification body, and the filter > too, because it is redundant. Right? > > Its being there confuses people like me, who assume that if its there it > must have a purpose. > >> If I have that right, then this state changes over time as calls are >> diverted. In particular, a new diversion is added. Then, >> simplistically, each notify would contain not only the most recent >> diversion, but all the prior diversions as well. >> <Ranjit-Feb23> the set of previous diversions can be taken care of by >> use of History-Info header. > > You are thinking of something different than I am. > You are talking about previous diversions of the *same call*. > I'm talking about diversions of previous calls by the same diverting > user. > > IOW, > - at 2:00 a call from alice was diverted to bob. > - at 3:00 a call from carol was diverted to ted. > ... > <Ranjit-Feb23-2> Ok here as you said, the notification always contains > the most recent and latest diversion that occurred and the one that > matched the subscriber's filter criteria. Except for what you say below > Its certainly possible to *imagine* such a state, gradually increasing > with time as other calls are diverted. > >> Each notification will contain information about only one diversion >> which gets triggered when the diversion occurs. > > So, if my phone has been *off*, when I turn it on I won't get a > notification about a diversion that occurred while it was off? Is that a > feature, or a limitation of the design? > <Ranjit-Feb23-2> The notifications are temporarily stored in the server > when the phone is *off* and they would be sent one by one when the phone > is *on*. So yes it's a feature in the server to monitor phone's status > and store the notifications if required - the amount of storage could > depend on server policy and some may or may not. No hard rule that they > should. If they do not store, then only the latest notification would be > sent. See, you really *do* have state!!! IIUC, you are saying that the server might store history of multiple diversions, or just the most recent one, or none. > If notifications of diversions are only delivered in realtime as they > occur, then why do you bother to include the time of the diversion in > the notification? > <Ranjit-Feb23-2> true. This makes sense only when notifications are > stored and sent later (phone off scenario) When you say "phone off", I presume you mean "phone not subscribed to this event package". Is that right? What do you do about multiple phones (extensions) on the same AOR? E.g. one at the office and another at home. Consider that case, and that I have been out of the office for some time, and arrive home without visiting the office. My home phone has been off, but the office phone has been on the whole time. Will I see the diversions that have occurred while I was out? If you clear the state as soon as you send one notification with it, then when I get home I will see no diversions. It would all be much cleaner if you kept the most recent N diversions in the server, where N>=1. When a new one comes in, if that makes N+1, then discard the oldest, and *then* send the notification to whoever is subscribed. If somebody else subscribes later, send what you have. Thanks, Paul >> Or you could define it so that older diversions are removed, using any > >> of a variety of algorithms. E.g. you might keep the most recent N of >> them, or all that have occurred in the last N minutes. (E.g. you might > >> keep only the single most recent one.) But that does imply that >> somebody subscribing *after* a diversion has occurred will get a >> notification immediately with whatever that state is - say the most >> recent diversion, even if that occurred a long time ago. (This could >> be a feature, but the implementation needs to support it by retaining >> the state.) >> >> It starts to get messy if you don't want to retain the state. Then you > >> must pretend that the new diversion was added to the (previously >> empty) state, caused notification(s), and then was immediately removed > >> from the state. If viewed that way, the removal would also cause a > notification. >> I suggested how that might be handled, but Adam thought it improper. >> <Ranjit-Feb23> ok. > > The trick here is to find a way to model the state, and the implicit and > explicit filters, to achieve the sort of results you want and permit the > sort of implementation you want. There are no doubt several ways that > may work. > > I think what you need is something like: > > - the state consists (abstractly) of x, y, z > - the state is adjusted in the following way when > another call is diverted > - the manner of matching a particular component in a > filter against the state is ... > - the manner of dealing with multiple components in > a filter is ... > - the manner of populating the notification body from > the state is ... > > <Ranjit-Feb23-2> need to think further on this. > > Thanks, > Paul > From zhouzp@huawei.com Tue Feb 23 18:07:26 2010 Return-Path: <zhouzp@huawei.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F4F28C199 for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 18:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.873 X-Spam-Level: X-Spam-Status: No, score=0.873 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOW-X2Gb23tj for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 18:07:25 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 064F628C17F for <dispatch@ietf.org>; Tue, 23 Feb 2010 18:07:25 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYB0007RPZJOD@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 24 Feb 2010 10:09:19 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYB003EBPZJRQ@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 24 Feb 2010 10:09:19 +0800 (CST) Received: from z54906b ([10.168.86.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYB000GMPZIB1@szxml06-in.huawei.com> for dispatch@ietf.org; Wed, 24 Feb 2010 10:09:19 +0800 (CST) Date: Wed, 24 Feb 2010 10:09:18 +0800 From: zhipeng zhou <zhouzp@huawei.com> In-reply-to: <mailman.4814.1266934580.4761.dispatch@ietf.org> To: dispatch@ietf.org, salvatore.loreto@ericsson.com Message-id: <009001cab4f6$5f900930$1856a80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acq0kyZYi731SW+wTPCysTI95s2aAAAYmhiQ Subject: Re: [dispatch] dispatch Digest, Vol 11, Issue 40 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Feb 2010 02:07:26 -0000 Hi Sal, Thanks for your response. While my question is what the difference for the far end device on whether it hold single or muliple sessions with the other devices. I mean, if the far end device hold several seperate sessions with the household devices, for the user it is also available to get the integrated experience by the support of the client. For the communication itself, what profit can be got your proposal. The far end device can maitain several sessions simultaneously. Thanks. Zhipeng //////////////////////////////////////////////////////////////////////////// ////////////////////////////// Message: 4 Date: Tue, 23 Feb 2010 16:18:14 +0200 From: Salvatore Loreto <salvatore.loreto@ericsson.com> Subject: Re: [dispatch] A question on "draft-loreto-dispatch-disaggregated-media-01" To: dispatch@ietf.org Message-ID: <4B83E3A6.6080701@ericsson.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Hi Zhipeng, thanks for the question. The advantage of the proposed solution is that the user does not need a device that is able to act as a controller: indeed the proposed solution give the possibility for a user to create a multimedia session combining different media streams, coming from different devices under his/her control (where none of those devices can act as a controller for the other devices in the call), so that they are treated by the far end of the session as a single media session. cheers /Sal On 02/21/2010 04:44 AM, zhipeng zhou wrote: > Hi Salvatore and Gonzalo: > After reading your newly uploaded > "draft-loreto-dispatch-disaggregated-media-01", esp. your section 4, > I have a question as following : > Since Bob's device will communicate with Alice's three devices, three > channels or sessions will be available to implement this scenario. > While the sentece in this document "Since this type of scenario is not > covered by existing mechanisms, we > propose to initiate work on SIP extensions to support it." shows > that you like to implement this scenario through a new way. > So, may you pls give a rough diagram and indicate the advantage of > your proposed new solution. > Thanks. > Zhipeng > > ----------------------------------------------------- > > Huawei Software Technologies Co.,Ltd. > > Floor 2, Building A, NO.48,Ning Nan AV., Nanjing , P.R.of China > Zipcode:210012 > E-Mail: zhouzp@huawei.com <mailto:zhouzp@huawei.com> > Phone:(+86) 25-82276771 > Fax:(+86) 25-82276760 > > Mobile:(+86) 13404162849 > ----------------------------------------------------- > > **************************************************************************** *********************************** > ??????????????????,?????????????????????????????????? > > (?????????????????????)???????? > > ?????????,????????????? ???????! > **************************************************************************** *********************************** > > > **************************************************************************** *********************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the > > person or entity whose address is listed above. Any use of the > information contained herein in any way(including, > > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended > > recipient(s) is prohibited. > > If you receive this e-mail in error, please notify the sender by phone > or email immediately and delete it! > **************************************************************************** *********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/dispatch/attachments/20100223/2f8a06ce /attachment.htm> ------------------------------ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch End of dispatch Digest, Vol 11, Issue 40 **************************************** From gao.yang2@zte.com.cn Tue Feb 23 22:14:40 2010 Return-Path: <gao.yang2@zte.com.cn> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5480E28C21E for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 22:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTlVG+dYcmcy for <dispatch@core3.amsl.com>; Tue, 23 Feb 2010 22:14:25 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E281228C21D for <dispatch@ietf.org>; Tue, 23 Feb 2010 22:14:21 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 11164992332426; Wed, 24 Feb 2010 13:38:43 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.2400836458; Wed, 24 Feb 2010 14:16:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o1O6G5gw012155; Wed, 24 Feb 2010 14:16:06 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: salvatore.loreto@ericsson.com, Gonzalo.Camarillo@ericsson.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: <OFDD5F94DA.2FD39BD1-ON482576D4.001F0731-482576D4.00226889@zte.com.cn> From: gao.yang2@zte.com.cn Date: Wed, 24 Feb 2010 14:14:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-02-24 14:15:59, Serialize complete at 2010-02-24 14:15:59 Content-Type: multipart/alternative; boundary="=_alternative 00226883482576D4_=" X-MAIL: mse2.zte.com.cn o1O6G5gw012155 Cc: dispatch@ietf.org Subject: [dispatch] Suggestion on draft-loreto-dispatch-disaggregated-media-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Feb 2010 06:14:40 -0000 This is a multipart message in MIME format. --=_alternative 00226883482576D4_= Content-Type: text/plain; charset="US-ASCII" Hi Salvatore and Gonzalo, I also think there are requirements to express a particular relationship between two or more of streams(m= lines) in different sessions/dialogs, while people do not want to combine there m= lines in one SDP or doing so is too hard for them. And further, I think we should allow; 1. combine only part of session1's streams and part of session2's streams as one group; 2. one session's differet streams can be in differet groups. And as we have the mechanism to express a particular relationship between two or more of streams(m= lines) in one session(RFC3388), we may do extension on this base. If we can do the extension along this way, I have some suggestion: 1. To group media streams in different session(SDP), then we need the placeholder of session1's stream in session2; 2. While grouping streams in different sessions, session ID may be needed as part of the index. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00226883482576D4_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Salvatore and Gonzalo,</font> <br> <br><font size=2 face="sans-serif">I also think there are requirements to express a particular relationship between two or more of streams(m= lines) in different sessions/dialogs, while people do not want to combine there m= lines in one SDP or doing so is too hard for them. </font> <br><font size=2 face="sans-serif">And further, I think we should allow;</font> <br><font size=2 face="sans-serif">1. combine only part of session1's streams and part of session2's streams as one group;</font> <br><font size=2 face="sans-serif">2. one session's differet streams can be in differet groups.</font> <br> <br><font size=2 face="sans-serif">And as we have the mechanism to express a particular relationship between two or more of streams(m= lines) in one session(RFC3388), we may do extension on this base. </font> <br> <br><font size=2 face="sans-serif">If we can do the extension along this way, I have some suggestion:</font> <br><font size=2 face="sans-serif">1. To group media streams in different session(SDP), then we need the placeholder of session1's stream in session2;</font> <br><font size=2 face="sans-serif">2. While grouping streams in different sessions, session ID may be needed as part of the index. </font> <br> <br><font size=2 face="sans-serif">Thanks,</font> <br> <br><font size=2 face="sans-serif">Gao</font> <br> <br><font size=2 face="sans-serif">===================================<br> Zip    : 210012<br> Tel    : 87211<br> Tel2   :(+86)-025-52877211<br> e_mail : gao.yang2@zte.com.cn<br> ===================================</font><br><pre> -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. </pre> --=_alternative 00226883482576D4_=-- From john.elwell@siemens-enterprise.com Wed Feb 24 00:38:13 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041F53A764F for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 00:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mySuhsQt5cww for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 00:38:11 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F170A3A6E5D for <dispatch@ietf.org>; Wed, 24 Feb 2010 00:38:10 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-992150; Wed, 24 Feb 2010 09:40:15 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 456791EB82AB; Wed, 24 Feb 2010 09:40:15 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 24 Feb 2010 09:40:15 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Paul Kyzivat <pkyzivat@cisco.com>, Avasarala Ranjit-A20990 <ranjit@motorola.com> Date: Wed, 24 Feb 2010 09:40:13 +0100 Thread-Topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Thread-Index: Acq0uM/YRsJ1okfdT7qaKEmerEEMIgAcvI+Q Message-ID: <A444A0F8084434499206E78C106220CABB8E6FD1@MCHP058A.global-ad.net> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> In-Reply-To: <4B8422E6.1060709@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Feb 2010 08:38:13 -0000 I appreciate Paul's efforts to try to sort this out, but it seems to me tha= t we are having to go to great lengths to make this fit the RFC 3265 model.= Perhaps HTTP would be a better way of getting call log information, includ= ing not only diverted calls but also, say, missed calls that were not diver= ted (e.g., when no UA registered and no diversion conditions apply). Parame= ters in the GET request could filter for particular types (e.g., diverted c= alls only) and indicate how far to go back in history. For the UA to become= aware that a state change has occurred, the event package in draft-roach-h= ttp-subscribe could be used. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23 February 2010 18:48 > To: Avasarala Ranjit-A20990 > Cc: dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version=20 > ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] >=20 >=20 >=20 > Avasarala Ranjit-A20990 wrote: > > Hi Paul. > >=20 > > Thanks for the comments. <Ranjit-Feb23-2>=20 > >=20 > >=20 > > Regards > > Ranjit > >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Sent: Tuesday, February 23, 2010 7:40 PM > > To: Avasarala Ranjit-A20990 > > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > > Subject: Re: [dispatch] [Fwd: Re: Preliminary version=20 > ofExpert review > > ofdraft-avasarala-dispatch-comm-div-notification-03] > >=20 > > Inline. I've trimmed out irrelevant stuff > >=20 > > Avasarala Ranjit-A20990 wrote: > >> Hi Paul > >> > >> My comments <Ranjit-Feb23> > >> > >> > >> Regards > >> Ranjit > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >=20 > >> I think you are not understanding the kind of state model we are=20 > >> talking about. > >> > >> Think of the state as a collection of data that may change=20 > over time,=20 > >> that is visible to the notifier. When something in the=20 > state changes=20 > >> in that state, the notifier sends a NOTIFY to subscribers,=20 > saying "the > >=20 > >> state of the resource changed, here is the new value." > >> > >> <Ranjit-Feb23> In case of CDIV, the notifier triggers a=20 > NOTIFY when=20 > >> ever a diversion occurs and the filter criteria matches.=20 > So there is=20 > >> no resource as such whose value changes - except that notifier can=20 > >> maintain the count of number of diversions that have=20 > occurred and how=20 > >> many times the filter criteria matched and how many=20 > notifications were > >=20 > >> sent. So every time a notification is sent, these values get > > incremented. > >=20 > > I'm trying to find another way to conceptualize your situation - one > > that works better with the 3265 way of describing events. > >=20 > >> In the simplistic form, you could view that state as=20 > exactly the data=20 > >> needed to populate the body of your NOTIFY. > >> <Ranjit-Feb23> Then the state needs to contain the caller details,=20 > >> diversion time, reason for diversion and if filter=20 > criteria matched or > >=20 > >> not. > >> > >> It gets a more complicated if there can be multiple=20 > subscribers, and=20 > >> you don't allow them all to see all of the data. (I'm not=20 > certain if=20 > >> you have restrictions like that or not.) If you do, then=20 > there might=20 > >> be data in the state that come subscribers get and others do not. > >> <Ranjit-Feb23> No need of such a thing because a=20 > particular subscriber > >=20 > >> can only subscribe to his or her diversions and not others. > >=20 > > OK. Then we won't worry about that. > >=20 > >> In your case, it appears from your xml, that your state=20 > consists of=20 > >> zero or more diversions. (Specifically it can be more than=20 > one.) And=20 > >> for each there an originating URI, a diverting URI, a=20 > diverted-to URI, > >=20 > >> a diverting time, and a diverting reason. > >> <Ranjit-Feb23> could be.=20 > >> > >> But the diverting-URI is redundant - its equivalent to the=20 > resource=20 > >> that is the target of the subscription, and so will be constant=20 > >> throughout the subscription. I don't understand why it is=20 > present. My=20 > >> suspicion is that you have in mind that the server will serve more=20 > >> than one diverting user and so the *server* state consists=20 > of info for > >=20 > >> each diverting user it serves. But unless you allow a=20 > subscription to=20 > >> address the *server* rather than a particular diverting=20 > user, this is=20 > >> invisible to the state of a given resource subscription target. > >> <Ranjit-Feb23> Yes there is no need of diverting-URI.=20 > >=20 > > OK. Then it could be removed from the notification body,=20 > and the filter > > too, because it is redundant. Right? > >=20 > > Its being there confuses people like me, who assume that if=20 > its there it > > must have a purpose. > >=20 > >> If I have that right, then this state changes over time as=20 > calls are=20 > >> diverted. In particular, a new diversion is added. Then,=20 > >> simplistically, each notify would contain not only the most recent=20 > >> diversion, but all the prior diversions as well. > >> <Ranjit-Feb23> the set of previous diversions can be taken=20 > care of by=20 > >> use of History-Info header. > >=20 > > You are thinking of something different than I am. > > You are talking about previous diversions of the *same call*. > > I'm talking about diversions of previous calls by the same diverting > > user. > >=20 > > IOW, > > - at 2:00 a call from alice was diverted to bob. > > - at 3:00 a call from carol was diverted to ted. > > ... > > <Ranjit-Feb23-2> Ok here as you said, the notification=20 > always contains > > the most recent and latest diversion that occurred and the one that > > matched the subscriber's filter criteria.=20 >=20 > Except for what you say below >=20 > > Its certainly possible to *imagine* such a state, gradually=20 > increasing > > with time as other calls are diverted. > >=20 > >> Each notification will contain information about only one=20 > diversion=20 > >> which gets triggered when the diversion occurs. > >=20 > > So, if my phone has been *off*, when I turn it on I won't get a > > notification about a diversion that occurred while it was=20 > off? Is that a > > feature, or a limitation of the design? > > <Ranjit-Feb23-2> The notifications are temporarily stored=20 > in the server > > when the phone is *off* and they would be sent one by one=20 > when the phone > > is *on*. So yes it's a feature in the server to monitor=20 > phone's status > > and store the notifications if required - the amount of=20 > storage could > > depend on server policy and some may or may not. No hard=20 > rule that they > > should. If they do not store, then only the latest=20 > notification would be > > sent. >=20 > See, you really *do* have state!!! >=20 > IIUC, you are saying that the server might store history of multiple=20 > diversions, or just the most recent one, or none. >=20 > > If notifications of diversions are only delivered in=20 > realtime as they > > occur, then why do you bother to include the time of the=20 > diversion in > > the notification? > > <Ranjit-Feb23-2> true. This makes sense only when notifications are > > stored and sent later (phone off scenario) >=20 > When you say "phone off", I presume you mean "phone not subscribed to=20 > this event package". Is that right? >=20 > What do you do about multiple phones (extensions) on the same=20 > AOR? E.g.=20 > one at the office and another at home. Consider that case, and that I=20 > have been out of the office for some time, and arrive home without=20 > visiting the office. My home phone has been off, but the office phone=20 > has been on the whole time. Will I see the diversions that=20 > have occurred=20 > while I was out? >=20 > If you clear the state as soon as you send one notification with it,=20 > then when I get home I will see no diversions. >=20 > It would all be much cleaner if you kept the most recent N=20 > diversions in=20 > the server, where N>=3D1. When a new one comes in, if that=20 > makes N+1, then=20 > discard the oldest, and *then* send the notification to whoever is=20 > subscribed. If somebody else subscribes later, send what you have. >=20 > Thanks, > Paul >=20 > >> Or you could define it so that older diversions are=20 > removed, using any > >=20 > >> of a variety of algorithms. E.g. you might keep the most=20 > recent N of=20 > >> them, or all that have occurred in the last N minutes.=20 > (E.g. you might > >=20 > >> keep only the single most recent one.) But that does imply that=20 > >> somebody subscribing *after* a diversion has occurred will get a=20 > >> notification immediately with whatever that state is - say=20 > the most=20 > >> recent diversion, even if that occurred a long time ago.=20 > (This could=20 > >> be a feature, but the implementation needs to support it=20 > by retaining=20 > >> the state.) > >> > >> It starts to get messy if you don't want to retain the=20 > state. Then you > >=20 > >> must pretend that the new diversion was added to the (previously=20 > >> empty) state, caused notification(s), and then was=20 > immediately removed > >=20 > >> from the state. If viewed that way, the removal would also cause a > > notification. > >> I suggested how that might be handled, but Adam thought it=20 > improper. > >> <Ranjit-Feb23> ok. > >=20 > > The trick here is to find a way to model the state, and the=20 > implicit and > > explicit filters, to achieve the sort of results you want=20 > and permit the > > sort of implementation you want. There are no doubt several=20 > ways that > > may work. > >=20 > > I think what you need is something like: > >=20 > > - the state consists (abstractly) of x, y, z > > - the state is adjusted in the following way when > > another call is diverted > > - the manner of matching a particular component in a > > filter against the state is ... > > - the manner of dealing with multiple components in > > a filter is ... > > - the manner of populating the notification body from > > the state is ... > >=20 > > <Ranjit-Feb23-2> need to think further on this. > >=20 > > Thanks, > > Paul > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From salvatore.loreto@ericsson.com Wed Feb 24 05:27:49 2010 Return-Path: <salvatore.loreto@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AF028C15E for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 05:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNqxUIdPW0UW for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 05:27:48 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4EB3B28C152 for <dispatch@ietf.org>; Wed, 24 Feb 2010 05:27:47 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-9b-4b8529d0e4a5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 30.AC.31641.0D9258B4; Wed, 24 Feb 2010 14:29:52 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 14:28:59 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 14:28:58 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AF1B8298D; Wed, 24 Feb 2010 15:28:58 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6FF9921A43; Wed, 24 Feb 2010 15:28:58 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 05261219C4; Wed, 24 Feb 2010 15:28:57 +0200 (EET) Message-ID: <4B852999.4060200@ericsson.com> Date: Wed, 24 Feb 2010 15:28:57 +0200 From: Salvatore Loreto <salvatore.loreto@ericsson.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn> References: <OFDD5F94DA.2FD39BD1-ON482576D4.001F0731-482576D4.00226889@zte.com.cn> In-Reply-To: <OFDD5F94DA.2FD39BD1-ON482576D4.001F0731-482576D4.00226889@zte.com.cn> Content-Type: multipart/alternative; boundary="------------060300050100080701070602" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 24 Feb 2010 13:28:58.0678 (UTC) FILETIME=[520AFD60:01CAB555] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Subject: Re: [dispatch] Suggestion on draft-loreto-dispatch-disaggregated-media-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Feb 2010 13:27:49 -0000 This is a multi-part message in MIME format. --------------060300050100080701070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gao, can you provide us some simple use cases for your two proposed scenarios? thanks Sal On 02/24/2010 08:14 AM, gao.yang2@zte.com.cn wrote: > > Hi Salvatore and Gonzalo, > > I also think there are requirements to express a particular > relationship between two or more of streams(m= lines) in different > sessions/dialogs, while people do not want to combine there m= lines > in one SDP or doing so is too hard for them. > And further, I think we should allow; > 1. combine only part of session1's streams and part of session2's > streams as one group; > 2. one session's differet streams can be in differet groups. > And as we have the mechanism to express a particular relationship > between two or more of streams(m= lines) in one session(RFC3388), we > may do extension on this base. > > If we can do the extension along this way, I have some suggestion: > 1. To group media streams in different session(SDP), then we need the > placeholder of session1's stream in session2; > 2. While grouping streams in different sessions, session ID may be > needed as part of the index. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > --------------060300050100080701070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> Hi Gao,<br> <br> can you provide us some simple use cases for your two proposed scenarios?<br> <br> thanks<br> Sal<br> <br> On 02/24/2010 08:14 AM, <a class="moz-txt-link-abbreviated" href="mailto:gao.yang2@zte.com.cn">gao.yang2@zte.com.cn</a> wrote: <blockquote cite="mid:OFDD5F94DA.2FD39BD1-ON482576D4.001F0731-482576D4.00226889@zte.com.cn" type="cite"> <meta http-equiv="Context-Type" content="text/html; charset=us-ascii"> <br> Hi Salvatore and Gonzalo, <br> <br> I also think there are requirements to express a particular relationship between two or more of streams(m= lines) in different sessions/dialogs, while people do not want to combine there m= lines in one SDP or doing so is too hard for them. <br> And further, I think we should allow; <br> 1. combine only part of session1's streams and part of session2's streams as one group; <br> 2. one session's differet streams can be in differet groups.<br> </blockquote> <blockquote cite="mid:OFDD5F94DA.2FD39BD1-ON482576D4.001F0731-482576D4.00226889@zte.com.cn" type="cite"> And as we have the mechanism to express a particular relationship between two or more of streams(m= lines) in one session(RFC3388), we may do extension on this base. <br> <br> If we can do the extension along this way, I have some suggestion: <br> 1. To group media streams in different session(SDP), then we need the placeholder of session1's stream in session2; <br> 2. While grouping streams in different sessions, session ID may be needed as part of the index. <br> <br> Thanks, <br> <br> Gao <br> <br> ===================================<br> Zip    : 210012<br> Tel    : 87211<br> Tel2   :(+86)-025-52877211<br> e_mail : <a class="moz-txt-link-abbreviated" href="mailto:gao.yang2@zte.com.cn">gao.yang2@zte.com.cn</a><br> =================================== <br> <pre>-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. </pre> </blockquote> <br> </body> </html> --------------060300050100080701070602-- From gao.yang2@zte.com.cn Wed Feb 24 18:02:44 2010 Return-Path: <gao.yang2@zte.com.cn> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C492728C251 for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 18:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.212 X-Spam-Level: X-Spam-Status: No, score=-95.212 tagged_above=-999 required=5 tests=[AWL=-2.422, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVOGYYSqSgSD for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 18:02:43 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C7E0628C10B for <dispatch@ietf.org>; Wed, 24 Feb 2010 18:02:42 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 46907992332426; Thu, 25 Feb 2010 09:36:39 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.2400836458; Thu, 25 Feb 2010 10:04:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o1P245lO078576; Thu, 25 Feb 2010 10:04:05 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B852999.4060200@ericsson.com> To: Salvatore Loreto <salvatore.loreto@ericsson.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: <OF8E0A3E7C.076E3C0F-ON482576D5.0006DF6C-482576D5.000B4DA2@zte.com.cn> From: gao.yang2@zte.com.cn Date: Thu, 25 Feb 2010 10:02:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-02-25 10:04:03, Serialize complete at 2010-02-25 10:04:03 Content-Type: multipart/alternative; boundary="=_alternative 000B4D9F482576D5_=" X-MAIL: mse2.zte.com.cn o1P245lO078576 Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Subject: [dispatch] =?gb2312?b?tPC4tDogUmU6IFN1Z2dlc3Rpb24gb24gZHJhZnQt?= =?gb2312?b?bG9yZXRvLWRpc3BhdGNoLWRpc2FnZ3JlZ2F0ZWQtbWVkaWEtMDEudHh0?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 02:02:44 -0000 This is a multipart message in MIME format. --=_alternative 000B4D9F482576D5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FsLA0KDQpDb25zaWRlcmluZyByZW1vdGUgdmlydHVhbCByZWFsaXR5IG9yIHJlbW90ZSAz RCBtb25pdG9yo6x3ZSB3YW50IHRvIA0KY29tYmluZSB0d28ga2luZHMgb2YgbWVkaWEgaW4gb25l IGR5bmFtaWMgcHJlc2VuY2UuIFN1cHBvc2Ugb25lIGtpbmQgb2YgDQptZWRpYSBpcyB2ZWRpby9p bWFnZSwgYW5vdGhlciBpcyBhdWRpby4gVGhyZWUgYXJlIHRocmVlIHZlZGlvIHNhbXBsaW5nIA0K c3RyZWFtcywgYXMgdjEsIHYyLCB2MyBhdCBkaWZmZXJlbnQgYW5nbGUuIFR3byBhdWRpbyBzYW1w bGluZyBzdHJlYW1zLCBhcyANCmExLCBhMiwgYWNjb3JkaW5nIHRvIHYxIGFuZCB2MiBzZXBhcmF0 ZWx5LiBXZSBzZW5kIHRoZSB3aG9sZSBmaXZlIHN0cmVhbXMgDQpzZXBhcmF0ZWx5IHRvIHRoZSBy ZW1vdGUuDQoNCldlIG5lZWQgZ3JvdXBzIHRvIGRlc2NyaWJlIHRoZXNlIG1lZGlhIHN0cmVhbXM6 DQoxLiBncm91cDEodjEsIGExKTsNCjIuIGdyb3VwMih2MiwgYTIpOw0KMy4gZ3JvdXAzKHYxLCB2 MiwgdjMpLg0KDQpXZSBuZWVkIHRvIGV4cHJlc3MgdGhpcyBjaGFyYWN0ZXJpc3RpYywgbm8gbWF0 dGVyIGhvdyB3ZSBhcnJhbmdlIFNEUC4NClVzdWFsbHksIHdlIG5lZWQgc29tZSBEU1AgcHJvY2Vz cyBmb3IgdGhlIHZlZGlvIHN0cmVhbXMuIFRoZW4sIHRoZSB0aHJlZSANCnZlZGlvIHN0cmVhbSBt YXkgYmUgc2VudCB0byBvbmUgc3BlY2lhbCBtZWRpYSBzZXJ2ZXIgdG8gZG8gM0QgbW9kZWwgDQpj b21wdXRpbmcgYW5kIHJlLWNvbnN0cnVjdCBwcm9jZXNzLiBUaGUgbWVkaWEgc2VydmVyIHRoZW4g c2VuZHMgcHJvY2Vzc2VkIA0KdmVkaW8gc3RyZWFtcyBpbiBvbmUgc2Vzc2lvbiB0byB0aGUgbXVs dGktcHJvamVjdG9yIHRvIGRvIHRoZSBwcmVzZW5jZS4gDQpUaGlzIGtpbmQgb2YgbWVkaWEgc2Vy dmVyIHVzdWFsbHkgbmVlZCB0aGUgdGhyZWUgdmVkaW8gc3RyZWFtIGluIG9uZSANClNEUChTRFAx KSwgdGhlbiB3ZSBtYXkgdXNlIG9uZSBBUyB0byBkbyBzdWNoIHdvcmsuDQoNClRoZW4gd2UgY2Fu IGNvbXBhcmUgU0RQMSB3aXRoIHRoZSBhMSdzIFNEUChTRFAyKS4NCnYxIG9mIFNEUDEgYW5kIGEx IG9mIFNEUDIgYXJlIGluIG9uZSBncm91cC4gVGhhdCdzIHRoZSBjYXNlIG9mICJjb21iaW5lIA0K b25seSBwYXJ0IG9mIHNlc3Npb24xJ3Mgc3RyZWFtcyBhbmQgcGFydCBvZiBzZXNzaW9uMidzIHN0 cmVhbXMgYXMgb25lIA0KZ3JvdXAiOw0KdjEgb2YgU0RQMSBhbmQgdjIgb2YgU0RQMSBhcmUgaW4g ZGlmZmVyZW50IGdyb3Vwcy4gVGhhdCdzIHRoZSBjYXNlIG9mICJvbmUgDQpzZXNzaW9uJ3MgZGlm ZmVyZXQgc3RyZWFtcyBjYW4gYmUgaW4gZGlmZmVyZXQgZ3JvdXBzIg0KDQpGdXJ0aGVyLCB2MSBv ZiBTRFAxIGNhbiBiZSBpbiBncm91cDEgYW5kIGdyb3VwMywgdGhlbiwgd2UgbWF5IG5lZWQgdGhl IA0KdGhpcmQgcnVsZXMgaGVyZSwgYXMgIm9uZSBzZXNzaW9uJ3Mgb25lIHN0cmVhbSBjYW4gYmUg aW4gZGlmZmVyZW50IGdyb3VwcyANCnJlbGF0aW5nIHRvIHN0cmVhbXMgb3V0c2lkZSBvZiB0aGUg c2Vzc2lvbiIuDQoNCkNoZWVycywNCg0KR2FvIA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDoo Kzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNClNhbHZhdG9yZSBMb3JldG8gPHNh bHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tPiANCjIwMTAtMDItMjQgMjE6MjgNCg0KytW8/sjL DQoiZ2FvLnlhbmcyQHp0ZS5jb20uY24iIDxnYW8ueWFuZzJAenRlLmNvbS5jbj4NCrOty80NCkdv bnphbG8gQ2FtYXJpbGxvIDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+LCAiZGlzcGF0 Y2hAaWV0Zi5vcmciIA0KPGRpc3BhdGNoQGlldGYub3JnPg0K1vfM4g0KUmU6IFN1Z2dlc3Rpb24g b24gZHJhZnQtbG9yZXRvLWRpc3BhdGNoLWRpc2FnZ3JlZ2F0ZWQtbWVkaWEtMDEudHh0DQoNCg0K DQoNCg0KDQpIaSBHYW8sDQoNCmNhbiB5b3UgcHJvdmlkZSB1cyBzb21lIHNpbXBsZSB1c2UgY2Fz ZXMgZm9yIHlvdXIgdHdvIHByb3Bvc2VkIHNjZW5hcmlvcz8NCg0KdGhhbmtzDQpTYWwNCg0KT24g MDIvMjQvMjAxMCAwODoxNCBBTSwgZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6IA0KDQpIaSBT YWx2YXRvcmUgYW5kIEdvbnphbG8sIA0KDQpJIGFsc28gdGhpbmsgdGhlcmUgYXJlIHJlcXVpcmVt ZW50cyB0byBleHByZXNzIGEgcGFydGljdWxhciByZWxhdGlvbnNoaXAgDQpiZXR3ZWVuIHR3byBv ciBtb3JlIG9mIHN0cmVhbXMobT0gbGluZXMpIGluIGRpZmZlcmVudCBzZXNzaW9ucy9kaWFsb2dz LCANCndoaWxlIHBlb3BsZSBkbyBub3Qgd2FudCB0byBjb21iaW5lIHRoZXJlIG09IGxpbmVzIGlu IG9uZSBTRFAgb3IgZG9pbmcgc28gDQppcyB0b28gaGFyZCBmb3IgdGhlbS4gDQpBbmQgZnVydGhl ciwgSSB0aGluayB3ZSBzaG91bGQgYWxsb3c7IA0KMS4gY29tYmluZSBvbmx5IHBhcnQgb2Ygc2Vz c2lvbjEncyBzdHJlYW1zIGFuZCBwYXJ0IG9mIHNlc3Npb24yJ3Mgc3RyZWFtcyANCmFzIG9uZSBn cm91cDsgDQoyLiBvbmUgc2Vzc2lvbidzIGRpZmZlcmV0IHN0cmVhbXMgY2FuIGJlIGluIGRpZmZl cmV0IGdyb3Vwcy4NCkFuZCBhcyB3ZSBoYXZlIHRoZSBtZWNoYW5pc20gdG8gZXhwcmVzcyBhIHBh cnRpY3VsYXIgcmVsYXRpb25zaGlwIGJldHdlZW4gDQp0d28gb3IgbW9yZSBvZiBzdHJlYW1zKG09 IGxpbmVzKSBpbiBvbmUgc2Vzc2lvbihSRkMzMzg4KSwgd2UgbWF5IGRvIA0KZXh0ZW5zaW9uIG9u IHRoaXMgYmFzZS4gDQoNCklmIHdlIGNhbiBkbyB0aGUgZXh0ZW5zaW9uIGFsb25nIHRoaXMgd2F5 LCBJIGhhdmUgc29tZSBzdWdnZXN0aW9uOiANCjEuIFRvIGdyb3VwIG1lZGlhIHN0cmVhbXMgaW4g ZGlmZmVyZW50IHNlc3Npb24oU0RQKSwgdGhlbiB3ZSBuZWVkIHRoZSANCnBsYWNlaG9sZGVyIG9m IHNlc3Npb24xJ3Mgc3RyZWFtIGluIHNlc3Npb24yOyANCjIuIFdoaWxlIGdyb3VwaW5nIHN0cmVh bXMgaW4gZGlmZmVyZW50IHNlc3Npb25zLCBzZXNzaW9uIElEIG1heSBiZSBuZWVkZWQgDQphcyBw YXJ0IG9mIHRoZSBpbmRleC4gDQoNClRoYW5rcywgDQoNCkdhbyANCg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NClppcCAgICA6IDIxMDAxMg0KVGVsICAgIDogODcyMTENClRl bDIgICA6KCs4NiktMDI1LTUyODc3MjExDQplX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg DQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0u DQogDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNl bmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50 aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2Vj cmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRo aXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJh bnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRk cmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBu b3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQg aW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50 aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 000B4D9F482576D5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNhbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNvbnNpZGVyaW5nIHJlbW90ZSB2 aXJ0dWFsIHJlYWxpdHkgb3INCnJlbW90ZSAzRCBtb25pdG9yo6x3ZSB3YW50IHRvIGNvbWJpbmUg dHdvIGtpbmRzIG9mIG1lZGlhIGluIG9uZSBkeW5hbWljDQpwcmVzZW5jZS4gU3VwcG9zZSBvbmUg a2luZCBvZiBtZWRpYSBpcyB2ZWRpby9pbWFnZSwgYW5vdGhlciBpcyBhdWRpby4gVGhyZWUNCmFy ZSB0aHJlZSB2ZWRpbyBzYW1wbGluZyBzdHJlYW1zLCBhcyB2MSwgdjIsIHYzIGF0IGRpZmZlcmVu dCBhbmdsZS4gVHdvDQphdWRpbyBzYW1wbGluZyBzdHJlYW1zLCBhcyBhMSwgYTIsIGFjY29yZGlu ZyB0byB2MSBhbmQgdjIgc2VwYXJhdGVseS4gV2UNCnNlbmQgdGhlIHdob2xlIGZpdmUgc3RyZWFt cyBzZXBhcmF0ZWx5IHRvIHRoZSByZW1vdGUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBuZWVkIGdyb3VwcyB0byBkZXNjcmliZSB0aGVzZSBtZWRp YQ0Kc3RyZWFtczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEu IGdyb3VwMSh2MSwgYTEpOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Mi4gZ3JvdXAyKHYyLCBhMik7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4zLiBncm91cDModjEsIHYyLCB2MykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBuZWVkIHRvIGV4cHJlc3MgdGhpcyBjaGFyYWN0ZXJp c3RpYywNCm5vIG1hdHRlciBob3cgd2UgYXJyYW5nZSBTRFAuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Vc3VhbGx5LCB3ZSBuZWVkIHNvbWUgRFNQIHByb2Nlc3Mg Zm9yDQp0aGUgdmVkaW8gc3RyZWFtcy4gVGhlbiwgdGhlIHRocmVlIHZlZGlvIHN0cmVhbSBtYXkg YmUgc2VudCB0byBvbmUgc3BlY2lhbA0KbWVkaWEgc2VydmVyIHRvIGRvIDNEIG1vZGVsIGNvbXB1 dGluZyBhbmQgcmUtY29uc3RydWN0IHByb2Nlc3MuIFRoZSBtZWRpYQ0Kc2VydmVyIHRoZW4gc2Vu ZHMgcHJvY2Vzc2VkIHZlZGlvIHN0cmVhbXMgaW4gb25lIHNlc3Npb24gdG8gdGhlIG11bHRpLXBy b2plY3Rvcg0KdG8gZG8gdGhlIHByZXNlbmNlLiBUaGlzIGtpbmQgb2YgbWVkaWEgc2VydmVyIHVz dWFsbHkgbmVlZCB0aGUgdGhyZWUgdmVkaW8NCnN0cmVhbSBpbiBvbmUgU0RQKFNEUDEpLCB0aGVu IHdlIG1heSB1c2Ugb25lIEFTIHRvIGRvIHN1Y2ggd29yay48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZW4gd2UgY2FuIGNvbXBhcmUgU0RQMSB3aXRo IHRoZSBhMSdzDQpTRFAoU0RQMikuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj52MSBvZiBTRFAxIGFuZCBhMSBvZiBTRFAyIGFyZSBpbiBvbmUNCmdyb3VwLiBUaGF0 J3MgdGhlIGNhc2Ugb2YgJnF1b3Q7Y29tYmluZSBvbmx5IHBhcnQgb2Ygc2Vzc2lvbjEncyBzdHJl YW1zDQphbmQgcGFydCBvZiBzZXNzaW9uMidzIHN0cmVhbXMgYXMgb25lIGdyb3VwJnF1b3Q7Ozwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+djEgb2YgU0RQMSBhbmQg djIgb2YgU0RQMSBhcmUgaW4gZGlmZmVyZW50DQpncm91cHMuIFRoYXQncyB0aGUgY2FzZSBvZiAm cXVvdDtvbmUgc2Vzc2lvbidzIGRpZmZlcmV0IHN0cmVhbXMgY2FuIGJlDQppbiBkaWZmZXJldCBn cm91cHMmcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkZ1cnRoZXIsIHYxIG9mIFNEUDEgY2FuIGJlIGluIGdyb3VwMQ0KYW5kIGdyb3VwMywgdGhl biwgd2UgbWF5IG5lZWQgdGhlIHRoaXJkIHJ1bGVzIGhlcmUsIGFzICZxdW90O29uZSBzZXNzaW9u J3MNCm9uZSBzdHJlYW0gY2FuIGJlIGluIGRpZmZlcmVudCBncm91cHMgcmVsYXRpbmcgdG8gc3Ry ZWFtcyBvdXRzaWRlIG9mIHRoZQ0Kc2Vzc2lvbiZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNoZWVycyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJz cDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9t YWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj48Yj5TYWx2YXRvcmUgTG9yZXRvICZsdDtzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNv bSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAx MC0wMi0yNCAyMToyODwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZxdW90OyAmbHQ7Z2FvLnlh bmcyQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Hb256YWxvIENhbWFyaWxsbyAm bHQ7Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OywNCiZxdW90O2Rpc3BhdGNoQGll dGYub3JnJnF1b3Q7ICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJlOiBTdWdnZXN0aW9uIG9uIGRyYWZ0LWxvcmV0by1kaXNwYXRjaC1kaXNhZ2dyZWdhdGVkLW1l ZGlhLTAxLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mz5IaSBHYW8sPGJyPg0KPGJyPg0KY2FuIHlvdSBwcm92aWRlIHVzIHNvbWUgc2ltcGxl IHVzZSBjYXNlcyBmb3IgeW91ciB0d28gcHJvcG9zZWQgc2NlbmFyaW9zPzxicj4NCjxicj4NCnRo YW5rczxicj4NClNhbDxicj4NCjxicj4NCk9uIDAyLzI0LzIwMTAgMDg6MTQgQU0sIDwvZm9udD48 YSBocmVmPW1haWx0bzpnYW8ueWFuZzJAenRlLmNvbS5jbj48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZT48dT5nYW8ueWFuZzJAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCndy b3RlOiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCkhpIFNhbHZhdG9yZSBhbmQgR29u emFsbywgPGJyPg0KPGJyPg0KSSBhbHNvIHRoaW5rIHRoZXJlIGFyZSByZXF1aXJlbWVudHMgdG8g ZXhwcmVzcyBhIHBhcnRpY3VsYXIgcmVsYXRpb25zaGlwDQpiZXR3ZWVuIHR3byBvciBtb3JlIG9m IHN0cmVhbXMobT0gbGluZXMpIGluIGRpZmZlcmVudCBzZXNzaW9ucy9kaWFsb2dzLA0Kd2hpbGUg cGVvcGxlIGRvIG5vdCB3YW50IHRvIGNvbWJpbmUgdGhlcmUgbT0gbGluZXMgaW4gb25lIFNEUCBv ciBkb2luZw0Kc28gaXMgdG9vIGhhcmQgZm9yIHRoZW0uIDxicj4NCkFuZCBmdXJ0aGVyLCBJIHRo aW5rIHdlIHNob3VsZCBhbGxvdzsgPGJyPg0KMS4gY29tYmluZSBvbmx5IHBhcnQgb2Ygc2Vzc2lv bjEncyBzdHJlYW1zIGFuZCBwYXJ0IG9mIHNlc3Npb24yJ3Mgc3RyZWFtcw0KYXMgb25lIGdyb3Vw OyA8YnI+DQoyLiBvbmUgc2Vzc2lvbidzIGRpZmZlcmV0IHN0cmVhbXMgY2FuIGJlIGluIGRpZmZl cmV0IGdyb3Vwcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkFuZCBhcyB3ZSBoYXZlIHRoZSBt ZWNoYW5pc20gdG8gZXhwcmVzcyBhIHBhcnRpY3VsYXIgcmVsYXRpb25zaGlwDQpiZXR3ZWVuIHR3 byBvciBtb3JlIG9mIHN0cmVhbXMobT0gbGluZXMpIGluIG9uZSBzZXNzaW9uKFJGQzMzODgpLCB3 ZSBtYXkNCmRvIGV4dGVuc2lvbiBvbiB0aGlzIGJhc2UuIDxicj4NCjxicj4NCklmIHdlIGNhbiBk byB0aGUgZXh0ZW5zaW9uIGFsb25nIHRoaXMgd2F5LCBJIGhhdmUgc29tZSBzdWdnZXN0aW9uOiA8 YnI+DQoxLiBUbyBncm91cCBtZWRpYSBzdHJlYW1zIGluIGRpZmZlcmVudCBzZXNzaW9uKFNEUCks IHRoZW4gd2UgbmVlZCB0aGUgcGxhY2Vob2xkZXINCm9mIHNlc3Npb24xJ3Mgc3RyZWFtIGluIHNl c3Npb24yOyA8YnI+DQoyLiBXaGlsZSBncm91cGluZyBzdHJlYW1zIGluIGRpZmZlcmVudCBzZXNz aW9ucywgc2Vzc2lvbiBJRCBtYXkgYmUgbmVlZGVkDQphcyBwYXJ0IG9mIHRoZSBpbmRleC4gPGJy Pg0KPGJyPg0KVGhhbmtzLCA8YnI+DQo8YnI+DQpHYW8gPGJyPg0KPGJyPg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJy Pg0KVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KVGVsMiAmbmJzcDsgOigrODYpLTAyNS01 Mjg3NzIxMTxicj4NCmVfbWFpbCA6IDwvZm9udD48YSBocmVmPW1haWx0bzpnYW8ueWFuZzJAenRl LmNvbS5jbj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5nYW8ueWFuZzJAenRlLmNvbS5jbjwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PSA8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpv dGhlcnMuPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQg YXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQNCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YNCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwNCnNlbmRlci48YnI+DQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS48YnI+DQogJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHByZT4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZu YnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFp bCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJz cDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDtt YWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJt aXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtv ZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlz Jm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVk Jm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5i c3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5i c3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5 b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZu YnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRv ciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNw O2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0 aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMm bmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJz cDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1T cGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000B4D9F482576D5_=-- From ranjit@motorola.com Wed Feb 24 20:55:04 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B6D28C171 for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 20:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orxHxHAX+vXz for <dispatch@core3.amsl.com>; Wed, 24 Feb 2010 20:55:02 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 4BFD828C12C for <dispatch@ietf.org>; Wed, 24 Feb 2010 20:55:02 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-6.tower-55.messagelabs.com!1267073825!19671153!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10247 invoked from network); 25 Feb 2010 04:57:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Feb 2010 04:57:06 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o1P4v5rY026931 for <dispatch@ietf.org>; Wed, 24 Feb 2010 21:57:05 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o1P4v54d002215 for <dispatch@ietf.org>; Wed, 24 Feb 2010 22:57:05 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o1P4v3Mh002207 for <dispatch@ietf.org>; Wed, 24 Feb 2010 22:57:04 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 12:56:41 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B8422E6.1060709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq0uMNhQ++Ix6DVQcKaG/fkuHzGSABHQXTg References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 04:55:04 -0000 Hi Paul My comments <Ranjit-Feb25>=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, February 24, 2010 12:18 AM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Avasarala Ranjit-A20990 wrote: > Hi Paul. >=20 > Thanks for the comments. <Ranjit-Feb23-2> >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 23, 2010 7:40 PM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review=20 > ofdraft-avasarala-dispatch-comm-div-notification-03] >=20 > Inline. I've trimmed out irrelevant stuff >=20 > Avasarala Ranjit-A20990 wrote: >> Hi Paul >> >> My comments <Ranjit-Feb23> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >=20 >> I think you are not understanding the kind of state model we are=20 >> talking about. >> >> Think of the state as a collection of data that may change over time, >> that is visible to the notifier. When something in the state changes=20 >> in that state, the notifier sends a NOTIFY to subscribers, saying=20 >> "the >=20 >> state of the resource changed, here is the new value." >> >> <Ranjit-Feb23> In case of CDIV, the notifier triggers a NOTIFY when=20 >> ever a diversion occurs and the filter criteria matches. So there is=20 >> no resource as such whose value changes - except that notifier can=20 >> maintain the count of number of diversions that have occurred and how >> many times the filter criteria matched and how many notifications=20 >> were >=20 >> sent. So every time a notification is sent, these values get > incremented. >=20 > I'm trying to find another way to conceptualize your situation - one=20 > that works better with the 3265 way of describing events. >=20 >> In the simplistic form, you could view that state as exactly the data >> needed to populate the body of your NOTIFY. >> <Ranjit-Feb23> Then the state needs to contain the caller details,=20 >> diversion time, reason for diversion and if filter criteria matched=20 >> or >=20 >> not. >> >> It gets a more complicated if there can be multiple subscribers, and=20 >> you don't allow them all to see all of the data. (I'm not certain if=20 >> you have restrictions like that or not.) If you do, then there might=20 >> be data in the state that come subscribers get and others do not. >> <Ranjit-Feb23> No need of such a thing because a particular=20 >> subscriber >=20 >> can only subscribe to his or her diversions and not others. >=20 > OK. Then we won't worry about that. <Ranjit-Feb25> Yes >=20 >> In your case, it appears from your xml, that your state consists of=20 >> zero or more diversions. (Specifically it can be more than one.) And=20 >> for each there an originating URI, a diverting URI, a diverted-to=20 >> URI, >=20 >> a diverting time, and a diverting reason. >> <Ranjit-Feb23> could be.=20 >> >> But the diverting-URI is redundant - its equivalent to the resource=20 >> that is the target of the subscription, and so will be constant=20 >> throughout the subscription. I don't understand why it is present. My >> suspicion is that you have in mind that the server will serve more=20 >> than one diverting user and so the *server* state consists of info=20 >> for >=20 >> each diverting user it serves. But unless you allow a subscription to >> address the *server* rather than a particular diverting user, this is >> invisible to the state of a given resource subscription target. >> <Ranjit-Feb23> Yes there is no need of diverting-URI.=20 >=20 > OK. Then it could be removed from the notification body, and the=20 > filter too, because it is redundant. Right? <Ranjit-Feb25> yes we do not need diverting-URI in the notification body. >=20 > Its being there confuses people like me, who assume that if its there=20 > it must have a purpose. >=20 >> If I have that right, then this state changes over time as calls are=20 >> diverted. In particular, a new diversion is added. Then,=20 >> simplistically, each notify would contain not only the most recent=20 >> diversion, but all the prior diversions as well. >> <Ranjit-Feb23> the set of previous diversions can be taken care of by >> use of History-Info header. >=20 > You are thinking of something different than I am. > You are talking about previous diversions of the *same call*. > I'm talking about diversions of previous calls by the same diverting=20 > user. >=20 > IOW, > - at 2:00 a call from alice was diverted to bob. > - at 3:00 a call from carol was diverted to ted. > ... > <Ranjit-Feb23-2> Ok here as you said, the notification always contains > the most recent and latest diversion that occurred and the one that=20 > matched the subscriber's filter criteria. Except for what you say below > Its certainly possible to *imagine* such a state, gradually increasing > with time as other calls are diverted. >=20 >> Each notification will contain information about only one diversion=20 >> which gets triggered when the diversion occurs. >=20 > So, if my phone has been *off*, when I turn it on I won't get a=20 > notification about a diversion that occurred while it was off? Is that > a feature, or a limitation of the design? > <Ranjit-Feb23-2> The notifications are temporarily stored in the=20 > server when the phone is *off* and they would be sent one by one when=20 > the phone is *on*. So yes it's a feature in the server to monitor=20 > phone's status and store the notifications if required - the amount of > storage could depend on server policy and some may or may not. No hard > rule that they should. If they do not store, then only the latest=20 > notification would be sent. See, you really *do* have state!!! IIUC, you are saying that the server might store history of multiple diversions, or just the most recent one, or none. > If notifications of diversions are only delivered in realtime as they=20 > occur, then why do you bother to include the time of the diversion in=20 > the notification? > <Ranjit-Feb23-2> true. This makes sense only when notifications are=20 > stored and sent later (phone off scenario) When you say "phone off", I presume you mean "phone not subscribed to this event package". Is that right? <Ranjit-Feb25> True. This is ths phone state - being ON or OFF i.e registered with the network or not and then if it Is subscribed to CDIVN service or not.=20 What do you do about multiple phones (extensions) on the same AOR? E.g.=20 one at the office and another at home. Consider that case, and that I have been out of the office for some time, and arrive home without visiting the office. My home phone has been off, but the office phone has been on the whole time. Will I see the diversions that have occurred while I was out? <Ranjit-Feb25> Here it depends on the target of the call. i.e if the call was targetted for your home phone and it was off, and there was a rule that Diverts all incoming calls to home be diverted, then you would get a notification.=20 If you clear the state as soon as you send one notification with it, then when I get home I will see no diversions. <Ranjit-Feb25> True. Once a notification about a particular diversion is sent, then the server's state is back to idle as if no diversions have occurred and nothing to do.=20 It would all be much cleaner if you kept the most recent N diversions in the server, where N>=3D1. When a new one comes in, if that makes N+1, = then discard the oldest, and *then* send the notification to whoever is subscribed. If somebody else subscribes later, send what you have. <Ranjit-Feb25> This actually depends on how many diversions u want to store, server storage per subscriber - subscription types like silver. Gold where gold subscriber gets higher storage than silver subscriber Thanks, Paul >> Or you could define it so that older diversions are removed, using=20 >> any >=20 >> of a variety of algorithms. E.g. you might keep the most recent N of=20 >> them, or all that have occurred in the last N minutes. (E.g. you=20 >> might >=20 >> keep only the single most recent one.) But that does imply that=20 >> somebody subscribing *after* a diversion has occurred will get a=20 >> notification immediately with whatever that state is - say the most=20 >> recent diversion, even if that occurred a long time ago. (This could=20 >> be a feature, but the implementation needs to support it by retaining >> the state.) >> >> It starts to get messy if you don't want to retain the state. Then=20 >> you >=20 >> must pretend that the new diversion was added to the (previously >> empty) state, caused notification(s), and then was immediately=20 >> removed >=20 >> from the state. If viewed that way, the removal would also cause a > notification. >> I suggested how that might be handled, but Adam thought it improper. >> <Ranjit-Feb23> ok. >=20 > The trick here is to find a way to model the state, and the implicit=20 > and explicit filters, to achieve the sort of results you want and=20 > permit the sort of implementation you want. There are no doubt several > ways that may work. >=20 > I think what you need is something like: >=20 > - the state consists (abstractly) of x, y, z > - the state is adjusted in the following way when > another call is diverted > - the manner of matching a particular component in a > filter against the state is ... > - the manner of dealing with multiple components in > a filter is ... > - the manner of populating the notification body from > the state is ... >=20 > <Ranjit-Feb23-2> need to think further on this. >=20 > Thanks, > Paul >=20 From pkyzivat@cisco.com Thu Feb 25 13:05:46 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E44E28C27F for <dispatch@core3.amsl.com>; Thu, 25 Feb 2010 13:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUxjBQPthQya for <dispatch@core3.amsl.com>; Thu, 25 Feb 2010 13:05:41 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2EC0828C150 for <dispatch@ietf.org>; Thu, 25 Feb 2010 13:05:41 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,541,1262563200"; d="scan'208";a="88857062" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2010 21:07:52 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1PL7qGT028589; Thu, 25 Feb 2010 21:07:52 GMT Message-ID: <4B86E6AE.6010308@cisco.com> Date: Thu, 25 Feb 2010 16:07:58 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 <ranjit@motorola.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 21:05:46 -0000 Avasarala Ranjit-A20990 wrote: >>> But the diverting-URI is redundant - its equivalent to the resource >>> that is the target of the subscription, and so will be constant >>> throughout the subscription. I don't understand why it is present. My > >>> suspicion is that you have in mind that the server will serve more >>> than one diverting user and so the *server* state consists of info >>> for >>> each diverting user it serves. But unless you allow a subscription to >>> address the *server* rather than a particular diverting user, this is > >>> invisible to the state of a given resource subscription target. >>> <Ranjit-Feb23> Yes there is no need of diverting-URI. >> OK. Then it could be removed from the notification body, and the >> filter too, because it is redundant. Right? > <Ranjit-Feb25> yes we do not need diverting-URI in the notification > body. >> Its being there confuses people like me, who assume that if its there >> it must have a purpose. If you want to leave it there, even though its redundant, the main issue is making it *clear* that it is redundant and will always match the subscribed-to URI. The big problem is the potential that it might differ, and what it would mean if it did. > IIUC, you are saying that the server might store history of multiple > diversions, or just the most recent one, or none. > >> If notifications of diversions are only delivered in realtime as they >> occur, then why do you bother to include the time of the diversion in >> the notification? >> <Ranjit-Feb23-2> true. This makes sense only when notifications are >> stored and sent later (phone off scenario) > > When you say "phone off", I presume you mean "phone not subscribed to > this event package". Is that right? > <Ranjit-Feb25> True. This is ths phone state - being ON or OFF i.e > registered with the network or not and then if it > Is subscribed to CDIVN service or not. Well, in IMS I guess if you aren't registered you can't be subscribed. But presumably you can be registered and not subscribed. Its the subscription that is the gating factor here, right? > What do you do about multiple phones (extensions) on the same AOR? E.g. > one at the office and another at home. Consider that case, and that I > have been out of the office for some time, and arrive home without > visiting the office. My home phone has been off, but the office phone > has been on the whole time. Will I see the diversions that have occurred > while I was out? > > <Ranjit-Feb25> Here it depends on the target of the call. i.e if the > call was targetted for your home phone and it was off, and there was a > rule that > Diverts all incoming calls to home be diverted, then you would get a > notification. I don't quite understand, and think it may be significant. I was talking about two phones registered to the same URI. E.g. AOR sip:alice@atlanta.org with two contacts: sip:line1@alice.office.atlanta.com and sip:line2@alice.home.atlanta.com. Hence both phones would be subscribing to the CDIV service at sip:alice@atlanta.org. In that arrangement a caller can't (easily, without callerprefs or gruus) target a call to the home or the office. Rather the calls just ring both places. And then diversion rules will apply to calls to that AOR in general, so that both phones need to know about the diversion so that alice will know about it regardless of where she is. But I think you are talking about some other arrangement, with multiple AORs that have some relationship to one another here, that isn't clear to me from the text. If that is so, can you explain? > If you clear the state as soon as you send one notification with it, > then when I get home I will see no diversions. > <Ranjit-Feb25> True. Once a notification about a particular diversion is > sent, then the server's state is back to idle as if no diversions have > occurred and nothing to do. > > It would all be much cleaner if you kept the most recent N diversions in > the server, where N>=1. When a new one comes in, if that makes N+1, then > discard the oldest, and *then* send the notification to whoever is > subscribed. If somebody else subscribes later, send what you have. > <Ranjit-Feb25> This actually depends on how many diversions u want to > store, server storage per subscriber - subscription types like silver. > Gold where gold subscriber gets higher storage than silver subscriber In the above I was assuming that the value of N is configurable. A given AOR has some value. (Or maybe the whole CDIV service has a common value.) And maybe its enough for that value to always be one. The problem case is where the value of N is zero. Thanks, Paul From ranjit@motorola.com Thu Feb 25 21:33:45 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E5828C4FF for <dispatch@core3.amsl.com>; Thu, 25 Feb 2010 21:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXk-9eJscncP for <dispatch@core3.amsl.com>; Thu, 25 Feb 2010 21:33:44 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id C652628C251 for <dispatch@ietf.org>; Thu, 25 Feb 2010 21:33:43 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1267162551!36511333!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27083 invoked from network); 26 Feb 2010 05:35:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Feb 2010 05:35:51 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o1Q5Zph2026871 for <dispatch@ietf.org>; Thu, 25 Feb 2010 22:35:51 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o1Q5ZoVj018574 for <dispatch@ietf.org>; Thu, 25 Feb 2010 23:35:50 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o1Q5ZnBP018567 for <dispatch@ietf.org>; Thu, 25 Feb 2010 23:35:50 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Feb 2010 13:35:27 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B86E6AE.6010308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq2Xp0z85H9TPeSQPqDFwPWf2VZugAQsPDw References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 05:33:45 -0000 Hi Paul My comments <Ranjit-Feb26> [1] diverting-URI: I plan to remove this field from the list of elements that can be part of the notification body and filter criteria.=20 [2] phone-off and not subscribed-to: Here I mean, phone is off implies the subscriber is not registered to the IMS network at that moment. But the subcription could still be valid. So when the subscriber's phone is switched off, the notifier will not be able to send the notification to the subscriber and could store the notifications until the subscriber re-registers with the IMS network. The number of notifications that the notifier would store would be policy dependent.=20 But if the subscriber is registered and not subscribed, then there is no way the notifier can send any notifications. A case of no subscription. [3] in the example u suggested where sip:alice@atlanta.org with two contacts: sip:line1@alice.office.atlanta.com and sip:line2@alice.home.atlanta.com and both the phones ring, then it would be a case of parallel forking. Now say one or both the phones have set diversion rules, to divert the call to say=20 sip:voicemail@alice.atlanta.com, then the notifications would get generated with respect to both the contacts. [4] Yes the value of N is configurable and depends on how many diversions the subscribe wants to keep or could be dependent on server policy (some maximum number). If the server policy is to send notifications as and when they occur and not keep any divsersions information, then the value of last N=20 diversions will be zero. But if the server chooses to retain the last diversion always, then the value of N will be 1 and so on. Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, February 26, 2010 2:38 AM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Avasarala Ranjit-A20990 wrote: >>> But the diverting-URI is redundant - its equivalent to the resource=20 >>> that is the target of the subscription, and so will be constant=20 >>> throughout the subscription. I don't understand why it is present.=20 >>> My >=20 >>> suspicion is that you have in mind that the server will serve more=20 >>> than one diverting user and so the *server* state consists of info=20 >>> for each diverting user it serves. But unless you allow a=20 >>> subscription to address the *server* rather than a particular=20 >>> diverting user, this is >=20 >>> invisible to the state of a given resource subscription target. >>> <Ranjit-Feb23> Yes there is no need of diverting-URI.=20 >> OK. Then it could be removed from the notification body, and the=20 >> filter too, because it is redundant. Right? > <Ranjit-Feb25> yes we do not need diverting-URI in the notification=20 > body. >> Its being there confuses people like me, who assume that if its there >> it must have a purpose. If you want to leave it there, even though its redundant, the main issue is making it *clear* that it is redundant and will always match the subscribed-to URI. The big problem is the potential that it might differ, and what it would mean if it did. <Ranjit-Feb26> [1] > IIUC, you are saying that the server might store history of multiple=20 > diversions, or just the most recent one, or none. >=20 >> If notifications of diversions are only delivered in realtime as they >> occur, then why do you bother to include the time of the diversion in >> the notification? >> <Ranjit-Feb23-2> true. This makes sense only when notifications are=20 >> stored and sent later (phone off scenario) >=20 > When you say "phone off", I presume you mean "phone not subscribed to=20 > this event package". Is that right? > <Ranjit-Feb25> True. This is ths phone state - being ON or OFF i.e=20 > registered with the network or not and then if it Is subscribed to=20 > CDIVN service or not. Well, in IMS I guess if you aren't registered you can't be subscribed. But presumably you can be registered and not subscribed. Its the subscription that is the gating factor here, right? <Ranjit-Feb26> [2] > What do you do about multiple phones (extensions) on the same AOR? E.g.=20 > one at the office and another at home. Consider that case, and that I=20 > have been out of the office for some time, and arrive home without=20 > visiting the office. My home phone has been off, but the office phone=20 > has been on the whole time. Will I see the diversions that have=20 > occurred while I was out? >=20 > <Ranjit-Feb25> Here it depends on the target of the call. i.e if the=20 > call was targetted for your home phone and it was off, and there was a > rule that Diverts all incoming calls to home be diverted, then you=20 > would get a notification. I don't quite understand, and think it may be significant. I was talking about two phones registered to the same URI. E.g. AOR sip:alice@atlanta.org with two contacts:=20 sip:line1@alice.office.atlanta.com and sip:line2@alice.home.atlanta.com. Hence both phones would be subscribing to the CDIV service at sip:alice@atlanta.org. In that arrangement a caller can't (easily, without callerprefs or gruus) target a call to the home or the office. Rather the calls just ring both places. And then diversion rules will apply to calls to that AOR in general, so that both phones need to know about the diversion so that alice will know about it regardless of where she is. But I think you are talking about some other arrangement, with multiple AORs that have some relationship to one another here, that isn't clear to me from the text. If that is so, can you explain? <Ranjit-Feb26> [3] > If you clear the state as soon as you send one notification with it,=20 > then when I get home I will see no diversions. > <Ranjit-Feb25> True. Once a notification about a particular diversion=20 > is sent, then the server's state is back to idle as if no diversions=20 > have occurred and nothing to do. >=20 > It would all be much cleaner if you kept the most recent N diversions=20 > in the server, where N>=3D1. When a new one comes in, if that makes = N+1, > then discard the oldest, and *then* send the notification to whoever=20 > is subscribed. If somebody else subscribes later, send what you have. > <Ranjit-Feb25> This actually depends on how many diversions u want to=20 > store, server storage per subscriber - subscription types like silver. > Gold where gold subscriber gets higher storage than silver subscriber In the above I was assuming that the value of N is configurable. A given AOR has some value. (Or maybe the whole CDIV service has a common value.) And maybe its enough for that value to always be one. The problem case is where the value of N is zero. <Ranjit-Feb26> [4] Thanks, Paul From pkyzivat@cisco.com Fri Feb 26 06:34:19 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C3828C13B for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 06:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.345 X-Spam-Level: X-Spam-Status: No, score=-10.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDAIAbLR0BRB for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 06:34:18 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C8FA83A84DB for <dispatch@ietf.org>; Fri, 26 Feb 2010 06:34:17 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,546,1262563200"; d="scan'208";a="89021169" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Feb 2010 14:36:32 +0000 Received: from [10.86.244.206] ([10.86.244.206]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1QEaVIt023127; Fri, 26 Feb 2010 14:36:32 GMT Message-ID: <4B87DC79.6010104@cisco.com> Date: Fri, 26 Feb 2010 09:36:41 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 <ranjit@motorola.com> References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 14:34:19 -0000 Avasarala Ranjit-A20990 wrote: > Hi Paul > > My comments <Ranjit-Feb26> > > [1] diverting-URI: I plan to remove this field from the list of elements > that can be part of the notification body and filter criteria. OK. > [2] phone-off and not subscribed-to: Here I mean, phone is off implies > the subscriber is not registered to the IMS network at that moment. But > the > subcription could still be valid. So when the subscriber's phone is > switched off, the notifier will not be able to send the notification to > the > subscriber and could store the notifications until the subscriber > re-registers with the IMS network. The number of notifications that the > notifier would store would be policy dependent. > > But if the subscriber is registered and not subscribed, then there is > no way the notifier can send any notifications. A case of no > subscription. I'm still a little confused here. If phone is on and subscription is active, then in general notification should be possible, regardless of registration. I realize IMS doesn't permit that, but from a general standard perspective we shouldn't assume it. The manifestation in this case is that the NOTIFY would fail and the subscription would eventually be torn down. So I think the cases are: - there is a subscription and notification works - there is a subscription but notification fails - there is no subscription. > [3] in the example u suggested where sip:alice@atlanta.org with two > contacts: sip:line1@alice.office.atlanta.com and > sip:line2@alice.home.atlanta.com and > both the phones ring, then it would be a case of parallel forking. > Now say one or both the phones have set diversion rules, to divert the In this case, what does it mean for "one or both phones have set diversion rules"? Does that somehow imply distinct rules for each phone? I don't see how that could work. Aren't the diversion rules for the *AOR*? I see they could be set/changed from either phone. But its a single set of rules isn't it? So I might set the rules from the office, and then cancel them from home. > call to say > sip:voicemail@alice.atlanta.com, then the notifications would get > generated with respect to both the contacts. Again I'm confused by the terminology you use, and how it relates operationally. The diversion happens on the AOR, and the subscriptions are on the AOR, and the notifications are sent to the subscribers. I don't see where the registered contacts enter into the picture at all. If you have something else in mind, I hope you can explain it better in the draft. > [4] Yes the value of N is configurable and depends on how many > diversions the subscribe wants to keep or could be dependent on server > policy (some maximum > number). If the server policy is to send notifications as and when > they occur and not keep any divsersions information, then the value of > last N > diversions will be zero. But if the server chooses to retain the > last diversion always, then the value of N will be 1 and so on. All is straightforward for N>=1. For N=0 things are messy. If we are modeling this as state, and notifications are about state changes, then the new diversion is added to the (previously empty) state and that triggers notifications to all current subscriptions. Then if you don't want to retain even this much state (because N=0) you immediately remove that version from the state. But that is again a state change, so you end up with another notification of that state change. I presume you don't want that behavior. If you can live with N>=1 then we don't have the problem at all. If you need to support N=0 and don't want the extra notify, then we have to figure out if there is some trick to how things are modeled to get the desired effect. I've suggested something previously, but Adam didn't like it. This needs sorting out. Thanks, Paul > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, February 26, 2010 2:38 AM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review > ofdraft-avasarala-dispatch-comm-div-notification-03] > > > > Avasarala Ranjit-A20990 wrote: > >>>> But the diverting-URI is redundant - its equivalent to the resource >>>> that is the target of the subscription, and so will be constant >>>> throughout the subscription. I don't understand why it is present. >>>> My >>>> suspicion is that you have in mind that the server will serve more >>>> than one diverting user and so the *server* state consists of info >>>> for each diverting user it serves. But unless you allow a >>>> subscription to address the *server* rather than a particular >>>> diverting user, this is >>>> invisible to the state of a given resource subscription target. >>>> <Ranjit-Feb23> Yes there is no need of diverting-URI. >>> OK. Then it could be removed from the notification body, and the >>> filter too, because it is redundant. Right? >> <Ranjit-Feb25> yes we do not need diverting-URI in the notification >> body. >>> Its being there confuses people like me, who assume that if its there > >>> it must have a purpose. > > If you want to leave it there, even though its redundant, the main issue > is making it *clear* that it is redundant and will always match the > subscribed-to URI. > > The big problem is the potential that it might differ, and what it would > mean if it did. > <Ranjit-Feb26> [1] > >> IIUC, you are saying that the server might store history of multiple >> diversions, or just the most recent one, or none. >> >>> If notifications of diversions are only delivered in realtime as they > >>> occur, then why do you bother to include the time of the diversion in > >>> the notification? >>> <Ranjit-Feb23-2> true. This makes sense only when notifications are >>> stored and sent later (phone off scenario) >> When you say "phone off", I presume you mean "phone not subscribed to >> this event package". Is that right? >> <Ranjit-Feb25> True. This is ths phone state - being ON or OFF i.e >> registered with the network or not and then if it Is subscribed to >> CDIVN service or not. > > Well, in IMS I guess if you aren't registered you can't be subscribed. > But presumably you can be registered and not subscribed. Its the > subscription that is the gating factor here, right? > <Ranjit-Feb26> [2] > >> What do you do about multiple phones (extensions) on the same AOR? > E.g. >> one at the office and another at home. Consider that case, and that I >> have been out of the office for some time, and arrive home without >> visiting the office. My home phone has been off, but the office phone >> has been on the whole time. Will I see the diversions that have >> occurred while I was out? >> >> <Ranjit-Feb25> Here it depends on the target of the call. i.e if the >> call was targetted for your home phone and it was off, and there was a > >> rule that Diverts all incoming calls to home be diverted, then you >> would get a notification. > > I don't quite understand, and think it may be significant. > I was talking about two phones registered to the same URI. E.g. AOR > sip:alice@atlanta.org with two contacts: > sip:line1@alice.office.atlanta.com and sip:line2@alice.home.atlanta.com. > > Hence both phones would be subscribing to the CDIV service at > sip:alice@atlanta.org. > > In that arrangement a caller can't (easily, without callerprefs or > gruus) target a call to the home or the office. Rather the calls just > ring both places. And then diversion rules will apply to calls to that > AOR in general, so that both phones need to know about the diversion so > that alice will know about it regardless of where she is. > > But I think you are talking about some other arrangement, with multiple > AORs that have some relationship to one another here, that isn't clear > to me from the text. If that is so, can you explain? > > <Ranjit-Feb26> [3] > >> If you clear the state as soon as you send one notification with it, >> then when I get home I will see no diversions. >> <Ranjit-Feb25> True. Once a notification about a particular diversion >> is sent, then the server's state is back to idle as if no diversions >> have occurred and nothing to do. >> >> It would all be much cleaner if you kept the most recent N diversions >> in the server, where N>=1. When a new one comes in, if that makes N+1, > >> then discard the oldest, and *then* send the notification to whoever >> is subscribed. If somebody else subscribes later, send what you have. >> <Ranjit-Feb25> This actually depends on how many diversions u want to >> store, server storage per subscriber - subscription types like silver. >> Gold where gold subscriber gets higher storage than silver subscriber > > In the above I was assuming that the value of N is configurable. A given > AOR has some value. (Or maybe the whole CDIV service has a common > value.) And maybe its enough for that value to always be one. > > The problem case is where the value of N is zero. > > <Ranjit-Feb26> [4] > > Thanks, > Paul > From ranjit@motorola.com Fri Feb 26 08:01:54 2010 Return-Path: <ranjit@motorola.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2491928C1AC for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 08:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj4vpQBNFB9Y for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 08:01:52 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 5FDBD28C1B1 for <dispatch@ietf.org>; Fri, 26 Feb 2010 08:01:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1267200242!22496301!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 20712 invoked from network); 26 Feb 2010 16:04:02 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-12.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Feb 2010 16:04:02 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o1QG41uw002254 for <dispatch@ietf.org>; Fri, 26 Feb 2010 09:04:01 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o1QG3uVb016946 for <dispatch@ietf.org>; Fri, 26 Feb 2010 10:03:56 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o1QG3soP016866 for <dispatch@ietf.org>; Fri, 26 Feb 2010 10:03:55 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Feb 2010 00:03:31 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B87DC79.6010104@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq28Rvzk9rbXYStTpaVyYHDdFnJ0wACks+A References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> From: "Avasarala Ranjit-A20990" <ranjit@motorola.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 16:01:54 -0000 Hi Paul Comments <Ranjit-Feb26-2>=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, February 26, 2010 8:07 PM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Avasarala Ranjit-A20990 wrote: > Hi Paul >=20 > My comments <Ranjit-Feb26> >=20 > [1] diverting-URI: I plan to remove this field from the list of=20 > elements that can be part of the notification body and filter criteria. OK. <Ranjit-Feb26-2> OK > [2] phone-off and not subscribed-to: Here I mean, phone is off implies > the subscriber is not registered to the IMS network at that moment.=20 > But the > subcription could still be valid. So when the subscriber's phone is > switched off, the notifier will not be able to send the notification=20 > to the > subscriber and could store the notifications until the subscriber=20 > re-registers with the IMS network. The number of notifications that the > notifier would store would be policy dependent.=20 >=20 > But if the subscriber is registered and not subscribed, then there=20 > is no way the notifier can send any notifications. A case of no=20 > subscription. I'm still a little confused here. If phone is on and subscription is active, then in general notification should be possible, regardless of registration. I realize IMS doesn't permit that, but from a general standard perspective we shouldn't assume it. The manifestation in this case is that the NOTIFY would fail and the subscription would eventually be torn down. So I think the cases are: - there is a subscription and notification works - there is a subscription but notification fails - there is no subscription. <Ranjit-Feb26-2> Agreed. Actually instead of calling it as Notification fails, we can say - not sending notification due to (1) no match of filter criteria (2) phone not registered or outside coverage area due to which there is no connectivity and hence notification cannot be sent=20 Anyway if no subscription, no notification.=20 > [3] in the example u suggested where sip:alice@atlanta.org with two > contacts: sip:line1@alice.office.atlanta.com and=20 > sip:line2@alice.home.atlanta.com and > both the phones ring, then it would be a case of parallel forking. > Now say one or both the phones have set diversion rules, to divert the In this case, what does it mean for "one or both phones have set diversion rules"? Does that somehow imply distinct rules for each phone? I don't see how that could work. Aren't the diversion rules for the *AOR*? <Ranjit-Feb26-2> Yes the diversion rules are for AoR. So when there is a diversion rule set for the AoR and when diversions occur, the notifications are Sent to the AoR. I see they could be set/changed from either phone. But its a single set of rules isn't it? So I might set the rules from the office, and then cancel them from home. <Ranjit-Feb26-2> yes single set and could be set from either of the phones. True. > call to say=20 > sip:voicemail@alice.atlanta.com, then the notifications would get=20 > generated with respect to both the contacts. Again I'm confused by the terminology you use, and how it relates operationally. The diversion happens on the AOR, and the subscriptions are on the AOR, and the notifications are sent to the subscribers. I don't see where the registered contacts enter into the picture at all. <Ranjit-Feb26-2> Ya agree with you on this. Sorry for the confusion. If you have something else in mind, I hope you can explain it better in the draft. > [4] Yes the value of N is configurable and depends on how many=20 > diversions the subscribe wants to keep or could be dependent on server > policy (some maximum > number). If the server policy is to send notifications as and when > they occur and not keep any divsersions information, then the value of > last N > diversions will be zero. But if the server chooses to retain the=20 > last diversion always, then the value of N will be 1 and so on. All is straightforward for N>=3D1. For N=3D0 things are messy. If we are modeling this as state, and notifications are about state changes, then the new diversion is added to the (previously empty) state and that triggers notifications to all current subscriptions. Then if you don't want to retain even this much state (because N=3D0) you immediately remove that version from the = state.=20 But that is again a state change, so you end up with another notification of that state change. <Ranjit-Feb26-2> True. Actually the notifications are for informing the subscriber of the call diversions that happen. The notifications are not for informing the subscriber of state changes in the notifier or the number of diversions that occurred. As I mentioned in the abstract as well as 24.604, the main intent of CDIVN service is to inform the subscribers of communication diversions that occur on their behalf in the network and this information will help them manage their rules better.=20 <Ranjit-Feb26-2> But if we want to include the information related to how many diversions have happened till time (say from 12 AM ) till the time the notification is being sent, then as you say we can store the diversions. This would be useful when the subscriber specifies in the filter criteria to send notifications only during certain time like between 5 and 6 PM and not whenever a diversion occurs. Then N is grater than 1. I presume you don't want that behavior. If you can live with N>=3D1 then we don't have the problem at all. If you need to support N=3D0 and don't want the extra notify, then we have to figure out if there is some trick to how things are modeled to get the desired effect. I've suggested something previously, but Adam didn't like it. This needs sorting out. Thanks, Paul > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, February 26, 2010 2:38 AM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review=20 > ofdraft-avasarala-dispatch-comm-div-notification-03] >=20 >=20 >=20 > Avasarala Ranjit-A20990 wrote: >=20 >>>> But the diverting-URI is redundant - its equivalent to the resource >>>> that is the target of the subscription, and so will be constant=20 >>>> throughout the subscription. I don't understand why it is present. >>>> My >>>> suspicion is that you have in mind that the server will serve more=20 >>>> than one diverting user and so the *server* state consists of info=20 >>>> for each diverting user it serves. But unless you allow a=20 >>>> subscription to address the *server* rather than a particular=20 >>>> diverting user, this is invisible to the state of a given resource=20 >>>> subscription target. >>>> <Ranjit-Feb23> Yes there is no need of diverting-URI.=20 >>> OK. Then it could be removed from the notification body, and the=20 >>> filter too, because it is redundant. Right? >> <Ranjit-Feb25> yes we do not need diverting-URI in the notification=20 >> body. >>> Its being there confuses people like me, who assume that if its=20 >>> there >=20 >>> it must have a purpose. >=20 > If you want to leave it there, even though its redundant, the main=20 > issue is making it *clear* that it is redundant and will always match=20 > the subscribed-to URI. >=20 > The big problem is the potential that it might differ, and what it=20 > would mean if it did. > <Ranjit-Feb26> [1] >=20 >> IIUC, you are saying that the server might store history of multiple=20 >> diversions, or just the most recent one, or none. >> >>> If notifications of diversions are only delivered in realtime as=20 >>> they >=20 >>> occur, then why do you bother to include the time of the diversion=20 >>> in >=20 >>> the notification? >>> <Ranjit-Feb23-2> true. This makes sense only when notifications are=20 >>> stored and sent later (phone off scenario) >> When you say "phone off", I presume you mean "phone not subscribed to >> this event package". Is that right? >> <Ranjit-Feb25> True. This is ths phone state - being ON or OFF i.e=20 >> registered with the network or not and then if it Is subscribed to=20 >> CDIVN service or not. >=20 > Well, in IMS I guess if you aren't registered you can't be subscribed. > But presumably you can be registered and not subscribed. Its the=20 > subscription that is the gating factor here, right? > <Ranjit-Feb26> [2] >=20 >> What do you do about multiple phones (extensions) on the same AOR? > E.g.=20 >> one at the office and another at home. Consider that case, and that I >> have been out of the office for some time, and arrive home without=20 >> visiting the office. My home phone has been off, but the office phone >> has been on the whole time. Will I see the diversions that have=20 >> occurred while I was out? >> >> <Ranjit-Feb25> Here it depends on the target of the call. i.e if the=20 >> call was targetted for your home phone and it was off, and there was=20 >> a >=20 >> rule that Diverts all incoming calls to home be diverted, then you=20 >> would get a notification. >=20 > I don't quite understand, and think it may be significant. > I was talking about two phones registered to the same URI. E.g. AOR=20 > sip:alice@atlanta.org with two contacts: > sip:line1@alice.office.atlanta.com and sip:line2@alice.home.atlanta.com. >=20 > Hence both phones would be subscribing to the CDIV service at=20 > sip:alice@atlanta.org. >=20 > In that arrangement a caller can't (easily, without callerprefs or > gruus) target a call to the home or the office. Rather the calls just=20 > ring both places. And then diversion rules will apply to calls to that > AOR in general, so that both phones need to know about the diversion=20 > so that alice will know about it regardless of where she is. >=20 > But I think you are talking about some other arrangement, with=20 > multiple AORs that have some relationship to one another here, that=20 > isn't clear to me from the text. If that is so, can you explain? >=20 > <Ranjit-Feb26> [3] >=20 >> If you clear the state as soon as you send one notification with it,=20 >> then when I get home I will see no diversions. >> <Ranjit-Feb25> True. Once a notification about a particular diversion >> is sent, then the server's state is back to idle as if no diversions=20 >> have occurred and nothing to do. >> >> It would all be much cleaner if you kept the most recent N diversions >> in the server, where N>=3D1. When a new one comes in, if that makes=20 >> N+1, >=20 >> then discard the oldest, and *then* send the notification to whoever=20 >> is subscribed. If somebody else subscribes later, send what you have. >> <Ranjit-Feb25> This actually depends on how many diversions u want to >> store, server storage per subscriber - subscription types like silver. >> Gold where gold subscriber gets higher storage than silver subscriber >=20 > In the above I was assuming that the value of N is configurable. A=20 > given AOR has some value. (Or maybe the whole CDIV service has a=20 > common > value.) And maybe its enough for that value to always be one. >=20 > The problem case is where the value of N is zero. >=20 > <Ranjit-Feb26> [4] >=20 > Thanks, > Paul >=20 From andrew.hutton@siemens-enterprise.com Fri Feb 26 08:30:34 2010 Return-Path: <andrew.hutton@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428093A82FA for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 08:30:34 -0800 (PST) X-Quarantine-ID: <6bKlszmuMs-V> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bKlszmuMs-V for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 08:30:33 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E66613A86D9 for <dispatch@ietf.org>; Fri, 26 Feb 2010 08:30:32 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1031502 for dispatch@ietf.org; Fri, 26 Feb 2010 17:32:47 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0C79823F028E for <dispatch@ietf.org>; Fri, 26 Feb 2010 17:32:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 26 Feb 2010 17:32:47 +0100 From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> To: DISPATCH <dispatch@ietf.org> Date: Fri, 26 Feb 2010 17:33:17 +0100 Thread-Topic: I-D Action:draft-hutton-dispatch-session-recording-arch-00.txt Thread-Index: Acq2+PUDWPqdXwMnS5KbiiPFedvAqQACDp/A Message-ID: <101C6067BEC68246B0C3F6843BCCC1E306F075899F@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_101C6067BEC68246B0C3F6843BCCC1E306F075899FMCHP058Agloba_" MIME-Version: 1.0 Subject: [dispatch] I-D Action:draft-hutton-dispatch-session-recording-arch-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 16:30:34 -0000 --_002_101C6067BEC68246B0C3F6843BCCC1E306F075899FMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted the following draft which relates to the hopefully soon to= be formed media recording working group. --------------------- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: 26 February 2010 15:30 To: i-d-announce@ietf.org Subject: I-D Action:draft-hutton-dispatch-session-recording-arch-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : A. Hutton, et al. Filename : draft-hutton-dispatch-session-recording-arch-00.txt Pages : 14 Date : 2010-02-26 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). This is an initial draft which explores possible architectural solutions and has many open issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hutton-dispatch-session-recording= -arch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --_002_101C6067BEC68246B0C3F6843BCCC1E306F075899FMCHP058Agloba_ Content-Type: message/external-body; name="draft-hutton-dispatch-session-recording-arch-00.url" Content-Description: draft-hutton-dispatch-session-recording-arch-00.url Content-Disposition: attachment; filename="draft-hutton-dispatch-session-recording-arch-00.url"; size=112; creation-date="Fri, 26 Feb 2010 16:32:51 GMT"; modification-date="Fri, 26 Feb 2010 16:32:51 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1odXR0b24tZGlzcGF0Y2gtc2Vzc2lvbi1yZWNvcmRpbmctYXJjaC0wMC50eHQNCg== --_002_101C6067BEC68246B0C3F6843BCCC1E306F075899FMCHP058Agloba_-- From D.Hancock@CableLabs.com Fri Feb 26 11:55:20 2010 Return-Path: <D.Hancock@CableLabs.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5871528C31A for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 11:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya0VumOozODq for <dispatch@core3.amsl.com>; Fri, 26 Feb 2010 11:55:19 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 3429928C310 for <dispatch@ietf.org>; Fri, 26 Feb 2010 11:55:19 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o1QJvXUD029238 for <dispatch@ietf.org>; Fri, 26 Feb 2010 12:57:33 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 26 Feb 2010 12:57:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 26 Feb 2010 12:57:34 -0700 From: David Hancock <D.Hancock@CableLabs.com> To: "dispatch@ietf.org" <dispatch@ietf.org> Date: Fri, 26 Feb 2010 12:57:32 -0700 Thread-Topic: Requesting comments on draft-yu-tel-dai Thread-Index: Acq3He7vfeYMy4fYRFaV+eMjXT3ftw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D31659@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7CD4D31659srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [dispatch] Requesting comments on draft-yu-tel-dai X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 19:55:20 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CD4D31659srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The following I-D has been updated based on previously received expert revi= ew feedback from Milan Patel. Additional comments, if any, from interested = participants are welcome and will be appreciated. http://tools.ietf.org/html/draft-yu-tel-dai-08 >From the I-D: " This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC4694], and indicates how the carrier identified in the "cic" parameter was selected. This document also expands the use of the "cic" parameter to support pre-subscribed and dialed long-distance carrier requirements." Thanks, David --_000_76AC5FEF83F1E64491446437EA81A61F7CD4D31659srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} p.MsoCommentText, li.MsoCommentText, div.MsoCommentText {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p.Comment-blue, li.Comment-blue, div.Comment-blue {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman"; font-weight:bold;} span.EmailStyle19 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>Folks,<o:p></o:p></spa= n></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></spa= n></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>The following I-D has = been updated based on previously received expert review feedback from Milan Pate= l. Additional comments, if any, from interested participants are welcome and w= ill be appreciated.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></spa= n></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'><a href=3D"http://tools.ietf.org/html/draft-yu-tel-dai-08">http://tools.ietf.o= rg/html/draft-yu-tel-dai-08</a><o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></spa= n></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></spa= n></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>From the I-D:<o:p></o:= p></span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>"   Thi= s document defines a "dai" parameter for the "tel" Unifor= m<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>   Resource Identifier (URI) to support the Dial Around Indicator (DAI).<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>   The "dai" parameter is associated with the "cic" parameter, defined<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>   in [RFC46= 94], and indicates how the carrier identified in the "cic"<o:p></o:p><= /span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>   parameter= was selected.  This document also expands the use of the<o:p></o:p></span>= </font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>   "cic= " parameter to support pre-subscribed and dialed long-distance<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>   carrier requirements."<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></spa= n></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>Thanks,<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3D"C= ourier New"><span style=3D'font-size:10.0pt;font-family:"Courier New"'>David<o:p></o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </body> </html> --_000_76AC5FEF83F1E64491446437EA81A61F7CD4D31659srvxchg_--