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