From rjsparks@nostrum.com Wed Sep 2 06:37:59 2009 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 4E7403A6AF8; Wed, 2 Sep 2009 06:37:59 -0700 (PDT) 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, 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 74y8rX-fjfOM; Wed, 2 Sep 2009 06:37:58 -0700 (PDT) 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 D86F63A6BA7; Wed, 2 Sep 2009 06:36:34 -0700 (PDT) Received: from [192.168.2.2] (pool-71-170-52-89.dllstx.fios.verizon.net [71.170.52.89]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n82Dam4B074752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Sep 2009 08:36:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <8E7F9C5B-2554-42DB-A907-FD59EC73DBD4@nostrum.com> From: Robert Sparks To: rai@ietf.org, dispatch mailing list Content-Type: multipart/alternative; boundary=Apple-Mail-292-860984748 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Sep 2009 08:36:47 -0500 References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 71.170.52.89 is authenticated by a trusted mechanism) Subject: [dispatch] PLEASE NOTE (Fwd: IETF-76 DISPATCH WG deadlines) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dispatch mailing list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 13:37:59 -0000 --Apple-Mail-292-860984748 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit (apologies for cross-post: reply-to set to dispatch) The first deadline below is next Monday. Please get in touch with Mary and Gonzalo if you are going to have trouble hitting that date. RjS Begin forwarded message: > From: "Mary Barnes" > Date: August 21, 2009 11:25:16 AM CDT > To: > Cc: rai-ads@tools.ietf.org > Subject: [dispatch] IETF-76 DISPATCH WG deadlines > > Hi all, > > As was done for IETF-75, we are setting earlier deadlines for > discussing topics in DISPATCH prior to the WG session at IETF-76. > > We will again follow the deadlines for BoFs: > http://www.ietf.org/meeting/cutoff-dates.html#76 > > This provides enough time to dispatch topics prior to the meeting as > appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs, > mailing lists, etc. Thus, allowing us to have more focused and > constructive discussions on a smaller set of topics prior to the WG > session. > > Please note that the dates are much sooner than you might expect as > the time between IETF-75 and IETF-76 is 3 weeks less than the time > between IETF-74 and IETF-75. The document deadlines are 9 and 10 > weeks away from next Monday (August 24th). > > > Thus, the following are the proposed deadlines: > > Sept 7th - Cutoff date to notify the chairs and DISPATCH WG mailing > list of plans to submit a proposal. > -------------------------------------------------------------------------------------------------------- > > This will help folks with similar topics to work together before the > meeting. If a preliminary charter proposal is available at this > point, please include it. > > > September 21st - Cutoff for charter proposals for topics. > -------------------------------------------------------- > > A charter proposal must consist of a minimum of a problem statement > and at least one milestone/deliverable. This deadline will allow > time for consideration of proposals that could potentially be > "dispatched" prior to the WG session. > > > September 28th - Topics that are to be the focus of IETF-76 are > announced. > --------------------------------------------------------------------------- > > The idea here is to focus the discussion over the weeks preceding > IETF-76 on these main topics, noting that any new or updates to any > documents are due 3-4 weeks later. This will ensure we have > constructive discussions before the meeting and are actually able to > determine consensus as to where work should be progressed (e.g., > separate BoF, a new WG, an existing WG, individual document, etc.) > at IETF-76. Note, that the exact disposition for a topic may (per > the usual process) require follow-up and confirmation by the ADS and/ > or IESG (e.g., for a new WG, Bof, individually sponsored document, > etc.) or with another WG to ensure agreement with the DISPATCH WG > consensus for the topic. > > > As discussed previously, the intention is not necessarily to > preclude folks submitting documents on other topics, however, it is > very unlikely there would be agenda time allocated to documents/ > topics submitted after the deadlines. We can include one or two > slides on these topics in the DISPATCH WG chair charts so that the > authors can gather other interested parties to contribute to the work. > > Regards, > Mary and Gonzalo > DISPATCH WG co-chairs > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-292-860984748 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
(apologies for cross-post: = reply-to set to dispatch)

The first deadline below = is next Monday. Please get in touch with Mary = and Gonzalo if you are going to have&nb= sp;trouble hitting that date.

RjS

Begin forwarded message:

From: = "Mary Barnes" <mary.barnes@nortel.com>
Date: August 21, 2009 11:25:16 AM = CDT
Cc: rai-ads@tools.ietf.org
Subject: [dispatch] IETF-76 DISPATCH WG = deadlines
Hi all,

As was done for IETF-75, we are setting = earlier deadlines for discussing topics in DISPATCH prior to the WG = session at IETF-76. 

We will again follow the deadlines for BoFs:
http://www.ietf.org/meeting/cutoff-dates.html#76 =

This provides enough time = to dispatch topics prior to the meeting as appropriate - e.g., = mini-bofs, official bofs, other WGs, new WGs,  mailing lists, etc. = Thus, allowing us to have more focused and constructive discussions on a = smaller set of topics prior to the WG session.

Please note that the dates are much = sooner than you might expect as the time between IETF-75 and IETF-76 is = 3 weeks less than the time between IETF-74 and IETF-75. The document = deadlines are 9 and 10 weeks away from next Monday (August 24th).  =


Thus, the = following are the proposed deadlines:

Sept 7th  - Cutoff date to notify the chairs = and DISPATCH WG mailing list of plans to submit a proposal. =
---------------------------------------------------------------------= -----------------------------------

This will help folks with similar topics to work = together before the meeting. If a preliminary charter proposal is = available at this point, please include it.


September 21st - Cutoff for charter = proposals for topics.
-------------------------------------------------------- =

A charter proposal must = consist of a minimum of a problem statement and at least one = milestone/deliverable. This deadline will allow time for consideration = of proposals that could potentially be "dispatched" prior to the WG = session.


September 28th - Topics that are to be the focus of IETF-76 are = announced.
---------------------------------------------------------------------= ------

The idea = here is to focus the discussion over the weeks preceding IETF-76 on = these main topics, noting that any new or updates to any documents are = due 3-4 weeks later.  This will ensure we have constructive = discussions before the meeting and are actually able to determine = consensus as to where work should be progressed (e.g., separate BoF, a = new WG, an existing WG, individual document, etc.) at IETF-76. Note, = that the exact disposition for a topic may (per the usual process) = require follow-up and confirmation by the ADS and/or IESG (e.g., for a = new WG, Bof, individually sponsored document, etc.) or with another WG = to ensure agreement with the DISPATCH WG consensus for the = topic.


As = discussed previously, the intention is not necessarily to preclude folks = submitting documents on other topics, however, it is very unlikely there = would be agenda time allocated to documents/topics submitted after the = deadlines. We can include one or two slides on these topics in the = DISPATCH WG chair charts so that the authors can gather other interested = parties to contribute to the work.

Regards,
Mary and Gonzalo
DISPATCH WG co-chairs

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

= --Apple-Mail-292-860984748-- From alan@sipstation.com Wed Sep 2 15:12:52 2009 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 4F4AB3A69D8 for ; Wed, 2 Sep 2009 15:12:52 -0700 (PDT) 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 u3aiFtWiuqgo for ; Wed, 2 Sep 2009 15:12:51 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 140EF3A6AE1 for ; Wed, 2 Sep 2009 15:12:51 -0700 (PDT) Received: from pat2.wufi.wustl.edu ([128.252.78.82] helo=Alans-PowerBook-G4-17.local) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mixk8-0005Dj-FV for dispatch@ietf.org; Wed, 02 Sep 2009 21:51:52 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 128.252.78.82 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+KF3Y//A/14XvKwAqmtRKRF0XS0z5IzEc= Message-ID: <4A9EE8F6.9040309@sipstation.com> Date: Wed, 02 Sep 2009 16:51:50 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Call Control UUI for SIP Issue 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, 02 Sep 2009 22:12:52 -0000 Based on feedback during my presentation in Stockholm, I think I have a good idea how to modify the proposed charter text. One issue perhaps needs a little more discussion so I'd like to kick that off here. The question is, for some kind of information, when should a new SIP header field be used, when should this UUI transport mechanism be used, and when should a proprietary header field be used. It seemed like we had some differing opinions on this with respect to UUI. I think which approach depends on the information being transported. Here's my take on this: New SIP header field to transport user information. I think a new SIP header field is needed when: 1. SIP behavior is changed 2. The information is generated and consumed at the SIP layer by SIP elements 3. SIP elements besides the UAC and UAS might be interested and consume the information 4. There are specific privacy or cross-RAI issues involved with the information being transported 5. Interoperability is important UUI Transport mechanism. I think this mechanism is suitable when: 1. The information is generated and consumed by an application using SIP during session setup but not necessarily even SIP aware. 2. SIP behavior is unchanged 3. Generally only the UAC and UAS are interested in the information 4. The information is expected to survive retargeting, redirection, and retargeting 5. SIP elements may need to apply policy about passing and screening the information 6. Multivendor interop is important Proprietary header field (the old P-header) 1. The information is only of interest to UAC and UAS 2. No SIP elements need apply policy to the information 3. Single vendor or closed system application If we disagree strongly on these points, lets have that discussion now, and this may help us formulate charter text about the mechanism itself. Thanks, Alan From pkyzivat@cisco.com Thu Sep 3 08:43:02 2009 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 362F728C2EC for ; Thu, 3 Sep 2009 08:43:02 -0700 (PDT) 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 gOCNacjoTT+C for ; Thu, 3 Sep 2009 08:42:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E211628C2CE for ; Thu, 3 Sep 2009 08:42:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC6An0qrR7PE/2dsb2JhbADCaYhBAZAlBYItgW4 X-IronPort-AV: E=Sophos;i="4.44,325,1249257600"; d="scan'208";a="237015472" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Sep 2009 15:42:06 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n83Fg3gf019982; Thu, 3 Sep 2009 08:42:03 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n83Ffx3W027496; Thu, 3 Sep 2009 15:42:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:42:02 -0400 Received: from [10.86.245.247] ([10.86.245.247]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:42:02 -0400 Message-ID: <4A9FE3C4.5050805@cisco.com> Date: Thu, 03 Sep 2009 11:41:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alan Johnston References: <4A9EE8F6.9040309@sipstation.com> In-Reply-To: <4A9EE8F6.9040309@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2009 15:42:02.0258 (UTC) FILETIME=[14C01F20:01CA2CAD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2677; t=1251992523; x=1252856523; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Call=20Control=20UUI=20for =20SIP=20Issue |Sender:=20; bh=Wjr/QTaOHVoGP/a6qYQXRI+GZl7fQcLE4eu2xVMtpIo=; b=Sm/aYwalIZr+4wpQl4lzKDMTmhY7EllvFz00yN6xllTJjsWadpSAo0utdM hflN3mNYoRKW5sPxLTRJH6KMjY0yMYxPXSoKpqPVgDe5IHtKlv1RAXxgYK+q lJlPNsJaVh; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Call Control UUI for SIP Issue 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, 03 Sep 2009 15:43:02 -0000 Alan, I agree it is a good idea to partition the use cases in this way. I'm a little confused about the criteria you give for UUI below, because - I thought one of the reasons originally given for the proposed mechanism was that it was needed before call establishment for purpose of making routing decisions. If so, that means that it impacts sip behavior. - Also, isn't the applying of policy by sip elements also a change to sip behavior? Thanks, Paul Alan Johnston wrote: > Based on feedback during my presentation in Stockholm, I think I have a > good idea how to modify the proposed charter text. > > One issue perhaps needs a little more discussion so I'd like to kick > that off here. > > The question is, for some kind of information, when should a new SIP > header field be used, when should this UUI transport mechanism be used, > and when should a proprietary header field be used. It seemed like we > had some differing opinions on this with respect to UUI. I think which > approach depends on the information being transported. Here's my take > on this: > > New SIP header field to transport user information. I think a new SIP > header field is needed when: > 1. SIP behavior is changed > 2. The information is generated and consumed at the SIP layer by SIP > elements > 3. SIP elements besides the UAC and UAS might be interested and consume > the information > 4. There are specific privacy or cross-RAI issues involved with the > information being transported > 5. Interoperability is important > > UUI Transport mechanism. I think this mechanism is suitable when: > 1. The information is generated and consumed by an application using SIP > during session setup but not necessarily even SIP aware. > 2. SIP behavior is unchanged > 3. Generally only the UAC and UAS are interested in the information > 4. The information is expected to survive retargeting, redirection, and > retargeting > 5. SIP elements may need to apply policy about passing and screening the > information > 6. Multivendor interop is important > > Proprietary header field (the old P-header) > 1. The information is only of interest to UAC and UAS > 2. No SIP elements need apply policy to the information > 3. Single vendor or closed system application > > If we disagree strongly on these points, lets have that discussion now, > and this may help us formulate charter text about the mechanism itself. > > Thanks, > Alan > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From alan@sipstation.com Thu Sep 3 13:26:50 2009 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 410273A68BE for ; Thu, 3 Sep 2009 13:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ldpnE9b86rPI for ; Thu, 3 Sep 2009 13:26:49 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 3B4DE3A68BB for ; Thu, 3 Sep 2009 13:26:46 -0700 (PDT) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MjHy0-000Eud-7o; Thu, 03 Sep 2009 19:27:32 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+SweWci+FqFnWBXmb0PrVQc7PvaCi8YY0= Message-ID: <4AA018A2.2090707@sipstation.com> Date: Thu, 03 Sep 2009 14:27:30 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4A9EE8F6.9040309@sipstation.com> <4A9FE3C4.5050805@cisco.com> In-Reply-To: <4A9FE3C4.5050805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Call Control UUI for SIP Issue 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, 03 Sep 2009 20:26:50 -0000 Paul, Thanks for your comments - see mine below. Thanks, Alan Paul Kyzivat wrote: > Alan, > > I agree it is a good idea to partition the use cases in this way. > > I'm a little confused about the criteria you give for UUI below, because > - I thought one of the reasons originally given for the proposed > mechanism was that it was needed before call establishment for > purpose of making routing decisions. If so, that means that it > impacts sip behavior. The information does need to be rendered and parsed at the time of call establishment - that is why it is carried in an INVITE. But it is not really used for SIP routing decisions. I suppose it could be used in deciding whether to answer a call or reject it, but again I'd say that is not SIP behavior. > > - Also, isn't the applying of policy by sip elements also a change > to sip behavior? No, the policy is just whether to pass the information element up the protocol stack or whether to block its transport within a domain. The policy isn't, because this type of UUI is present, do some special SIP operation or invoke a special SIP feature. So, here's an example of what I mean by "changing SIP behavior". Lets say we had this UUI mechanism but we didn't have the Refer-Sub: no header field. One could argue that suppressing the REFER implicit subscription is just a piece of user information, which is generated by the UAC and consumed by the UAS, so why not transport it using the UUI mechanism. Well, this information changes SIP behavior in that no NOTIFY is sent. Hence, this would not be a suitable usage for this UUI mechanism. > > Thanks, > Paul > > Alan Johnston wrote: >> Based on feedback during my presentation in Stockholm, I think I >> have a good idea how to modify the proposed charter text. >> >> One issue perhaps needs a little more discussion so I'd like to kick >> that off here. >> >> The question is, for some kind of information, when should a new SIP >> header field be used, when should this UUI transport mechanism be >> used, and when should a proprietary header field be used. It seemed >> like we had some differing opinions on this with respect to UUI. I >> think which approach depends on the information being transported. >> Here's my take on this: >> >> New SIP header field to transport user information. I think a new >> SIP header field is needed when: >> 1. SIP behavior is changed >> 2. The information is generated and consumed at the SIP layer by SIP >> elements >> 3. SIP elements besides the UAC and UAS might be interested and >> consume the information >> 4. There are specific privacy or cross-RAI issues involved with the >> information being transported >> 5. Interoperability is important >> >> UUI Transport mechanism. I think this mechanism is suitable when: >> 1. The information is generated and consumed by an application using >> SIP during session setup but not necessarily even SIP aware. >> 2. SIP behavior is unchanged >> 3. Generally only the UAC and UAS are interested in the information >> 4. The information is expected to survive retargeting, redirection, >> and retargeting >> 5. SIP elements may need to apply policy about passing and screening >> the information >> 6. Multivendor interop is important >> >> Proprietary header field (the old P-header) >> 1. The information is only of interest to UAC and UAS >> 2. No SIP elements need apply policy to the information >> 3. Single vendor or closed system application >> >> If we disagree strongly on these points, lets have that discussion >> now, and this may help us formulate charter text about the mechanism >> itself. >> >> Thanks, >> Alan >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From scott.lawrence@nortel.com Thu Sep 3 13:38:36 2009 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 13C5D3A68F9 for ; Thu, 3 Sep 2009 13:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 Q7DfYRHWlmYZ for ; Thu, 3 Sep 2009 13:38:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 62FC13A68EC for ; Thu, 3 Sep 2009 13:38:34 -0700 (PDT) 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 n83K8hM16449; Thu, 3 Sep 2009 20:08:43 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 16:08:28 -0400 From: "Scott Lawrence" To: "Mary Barnes" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 03 Sep 2009 20:08:26 +0000 Message-Id: <1252008506.15547.1305.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2009 20:08:28.0426 (UTC) FILETIME=[4D3FC6A0:01CA2CD2] Cc: dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines 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, 03 Sep 2009 20:38:36 -0000 On Fri, 2009-08-21 at 11:25 -0500, Mary Barnes wrote: > Sept 7th - Cutoff date to notify the chairs and DISPATCH WG mailing > list of plans to submit a proposal. I plan to respin and expand my draft problem statement on third party authentication, and would like to plan time to discuss it. From dyork@voxeo.com Thu Sep 3 14:21:01 2009 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 D0AD828C0CF for ; Thu, 3 Sep 2009 14:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPVq0NSfo4l4 for ; Thu, 3 Sep 2009 14:21:00 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id A628B3A6834 for ; Thu, 3 Sep 2009 14:21:00 -0700 (PDT) Received: from 97.sub-97-60-241.myvzw.com (account dyork [97.60.241.97] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 50585588; Thu, 03 Sep 2009 21:11:48 +0000 Message-Id: <52D749FD-BE59-4370-9517-D328FD4B0C3B@voxeo.com> From: Dan York To: Victor Pascual Avila In-Reply-To: <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.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, 3 Sep 2009 11:19:49 -0400 References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 03 Sep 2009 21:21:01 -0000 Victor and John, In getting caught up on all that's been going on in DISPATCH over the past bit, I will only say that *yes*, I think this is both helpful and going in the right direction. Please do continue your work on it. I do not currently have further feedback beyond saying that. Thanks for doing this, Dan On Jul 21, 2009, at 12:17 PM, Victor Pascual Avila wrote: > As mentioned in the below message, the authors would appreciate > feedback as to whether this is helpful and going in the right > direction. > > Thanks, > -Victor > > 2009/6/29 Elwell, John : >> There was an extensive discussion at IETF#74 on SIP Identity, where >> a good many views were put forward. The only consensus seemed to be >> to continue to discuss the topic. >> >> One of the themes during that discussion was to focus more on >> requirements, which the authors have attempted to do in this new >> draft: >> http://www.ietf.org/internet-drafts/draft-elwell-dispatch-identity-reqs-00.txt >> >> We would appreciate feedback as to whether this is helpful and >> going in the right direction, as well as detailed comments. >> >> I had hoped to do this a lot earlier, to trigger a discussion in >> time to get something set up for DISPATCH at IETF#75, but I failed, >> and also I failed to talk to the many of you who have interest in >> the topic and expressed opinions in the past. But since the >> deadline is approaching, I thought it best to post the draft and >> let discussion continue on that basis. >> >> John >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo From gonzalo.camarillo@ericsson.com Fri Sep 4 00:54:36 2009 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 951633A6942 for ; Fri, 4 Sep 2009 00:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.271 X-Spam-Level: X-Spam-Status: No, score=-5.271 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, HELO_EQ_SE=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 atOi4zdtR0pK for ; Fri, 4 Sep 2009 00:54:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1AA4528B23E for ; Fri, 4 Sep 2009 00:54:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-0a-4aa0c3f53091 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0D.02.01983.5F3C0AA4; Fri, 4 Sep 2009 09:38:30 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 09:38:29 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 09:38:29 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3694724C8; Fri, 4 Sep 2009 10:38:29 +0300 (EEST) Message-ID: <4AA0C3F4.3080200@ericsson.com> Date: Fri, 04 Sep 2009 10:38:28 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2009 07:38:29.0617 (UTC) FILETIME=[B2482E10:01CA2D32] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Nomcom info 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: Fri, 04 Sep 2009 07:54:36 -0000 FYI. Gonzalo -------- Original Message -------- Subject: Nomcom 2009-10: Reminder Call for Nominations, Local Office hours, Nominee Questionnaires available Date: Mon, 31 Aug 2009 15:23:03 -0700 (PDT) From: Mary Barnes To: IETF Announcement list CC: ietf@ietf.org Hi all, This email covers 3 topics: 1) Reminder: Call for Nominations 2) New: Local Office Hours 3) New: Questionnaires available for nominees Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com =============================================================================== 1) Call for Nominations ------------------------ The nomination period ends in less than 3 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours ----------------------- In order to facilitate additional feedback, the Nomcom is planning to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA: Stephen Kent - kent@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.barnes@gmail.com Lucy Yong - lucyyong@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.brim@gmail.com Montevideo, Uruguay: Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+ietf@qualcomm.com Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders before the deadline. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From Simo.Veikkolainen@nokia.com Fri Sep 4 05:10:13 2009 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 9FAB63A68D5 for ; Fri, 4 Sep 2009 05:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ORKnxmf5jvjh for ; Fri, 4 Sep 2009 05:10:12 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 889A33A68C5 for ; Fri, 4 Sep 2009 05:10:12 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n84C8XrD022049; Fri, 4 Sep 2009 07:09:05 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 15:09:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 15:09:07 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 4 Sep 2009 14:09:07 +0200 From: To: , , Date: Fri, 4 Sep 2009 14:09:04 +0200 Thread-Topic: New topic proposal for DISPATCH Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsg== Message-ID: 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_B23B311878A0B4438F5F09F47E01AAE03B10AD6263NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Sep 2009 12:09:07.0410 (UTC) FILETIME=[80C2C320:01CA2D58] Cc: Markus.Isomaki@nokia.com Subject: [dispatch] New topic proposal for DISPATCH 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: Fri, 04 Sep 2009 12:10:13 -0000 --_000_B23B311878A0B4438F5F09F47E01AAE03B10AD6263NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We would like to propose a new DISPATCH topic on how SIP and XMPP can be us= ed together in a complementary fashion. We have been working on a solution which combines SIP based VoIP and XMPP b= ased IM and Presence. The requirements and a proposed solution is outlined = in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01. The motivation for this work comes from experience which shows that most st= andards based VoIP deployments use SIP. At the same time, the Extensible Me= ssaging and Presence Protocol (XMPP) is widely used in instant messaging an= d presence services. An interesting scenario arises when a SIP based voice = (and video) service is combined together with an XMPP based instant messagi= ng and presence service. Note that the goal in this work is not SIP-XMPP protocol translation, but t= o define protocol extensions and best practises such that SIP based VoIP an= d XMPP based IM and presence could be seamlessly combined and offered to th= e end user. For rapid deployment, we assume no changes in the server infras= tructure, and instead impose new requirements and protocol extensions only = to the endpoints. We would like to get some discussion going on the use case itself as well a= s on the solution. Also, we would like to hear you thoughts on DISPATCH or = a new "dispatched" mini-WG as the home for such work. Exact charter proposal and problem statemen is to follow. Regards, Simo and Markus --_000_B23B311878A0B4438F5F09F47E01AAE03B10AD6263NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
We would like to propose a new DISPATCH topic on how SIP and XMPP can = be used together in a complementary fashion.
 
We have been working on a solution which combines SIP based VoIP and X= MPP based IM and Presence. The requirements and a proposed solution is outl= ined in http://tools.ietf.org/html/draft-veik= kolainen-sip-voip-xmpp-im-01.
 
The motivation for this work comes from experience which shows that mo= st standards based VoIP deployments use SIP. At the same time, the Extensib= le Messaging and Presence Protocol (XMPP) is widely used in instant messagi= ng and presence services. An interesting scenario arises when a SIP based voice (and video) service is combined toge= ther with an XMPP based instant messaging and presence service.
 
Note that the goal in this work is not SIP-XMPP protocol translation, = but to define protocol extensions and best practises such that SIP based Vo= IP and XMPP based IM and presence could be seamlessly combined and offered = to the end user. For rapid deployment, we assume no changes in the server infrastructure, and instead impose new r= equirements and protocol extensions only to the endpoints.
 
We would like to get some discussion going on the use case itself as w= ell as on the solution. Also, we would like to hear you thoughts on DISPATC= H or a new "dispatched" mini-WG as the home for such work.
 
Exact charter proposal and problem statemen is to follow.
 
Regards,
Simo and Markus
 
 
 --_000_B23B311878A0B4438F5F09F47E01AAE03B10AD6263NOKEUMSG01mgd_-- From oej@edvina.net Fri Sep 4 05:14:58 2009 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 0EEE23A68A3 for ; Fri, 4 Sep 2009 05:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_SE=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 ojudumf2NXtP for ; Fri, 4 Sep 2009 05:14:57 -0700 (PDT) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 336193A67F1 for ; Fri, 4 Sep 2009 05:14:56 -0700 (PDT) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 7D15D28426; Fri, 4 Sep 2009 13:58:36 +0200 (CEST) From: "Olle E. Johansson" To: In-Reply-To: References: Message-Id: <1D405AF2-4211-4F39-A2AB-26C1DD0AE1AF@edvina.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 4 Sep 2009 14:14:16 +0200 X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, Markus.Isomaki@nokia.com, Camarillo Gonzalo Subject: Re: [dispatch] New topic proposal for DISPATCH 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: Fri, 04 Sep 2009 12:14:58 -0000 4 sep 2009 kl. 14.09 skrev : > Hi, > > We would like to propose a new DISPATCH topic on how SIP and XMPP > can be used together in a complementary fashion. > > We have been working on a solution which combines SIP based VoIP and > XMPP based IM and Presence. The requirements and a proposed solution > is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 > . > > The motivation for this work comes from experience which shows that > most standards based VoIP deployments use SIP. At the same time, the > Extensible Messaging and Presence Protocol (XMPP) is widely used in > instant messaging and presence services. An interesting scenario > arises when a SIP based voice (and video) service is combined > together with an XMPP based instant messaging and presence service. > > Note that the goal in this work is not SIP-XMPP protocol > translation, but to define protocol extensions and best practises > such that SIP based VoIP and XMPP based IM and presence could be > seamlessly combined and offered to the end user. For rapid > deployment, we assume no changes in the server infrastructure, and > instead impose new requirements and protocol extensions only to the > endpoints. > > Exact charter proposal and problem statemen is to follow. The XMPP forum has a few drafts on this, so we should coordinate with them. There are a lot of issues to sort out. We had a workshop on this topic with Asterisk, Kamailio and a few other products at Inria in France and saw a lot of issues to sort out both in regards to IM and presence. For Asterisk we have both SIP and XMPP telephony, for Kamailio we have modules that try to bridge presence updates and IM. I think it's hard to separate protocol translation. It's all about making it work together seamlessly. /O From vkg@alcatel-lucent.com Fri Sep 4 07:53:27 2009 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 AE6253A6821 for ; Fri, 4 Sep 2009 07:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 8o5fRKEHbap3 for ; Fri, 4 Sep 2009 07:53:26 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id A202E3A679F for ; Fri, 4 Sep 2009 07:53:26 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n84EqQtt011095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 09:52:26 -0500 (CDT) 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 n84EqPwV007622; Fri, 4 Sep 2009 09:52:25 -0500 (CDT) Message-ID: <4AA129A9.8040107@alcatel-lucent.com> Date: Fri, 04 Sep 2009 09:52:25 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "dispatch@ietf.org" 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: Leon Portman , "Jain, Rajnish" , Hadriel Kaplan , "'Ken Rehor \(krehor\)'" Subject: [dispatch] SIP recording proposal 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: Fri, 04 Sep 2009 14:53:27 -0000 On Aug 21, 2009, Mary Barnes wrote: > Thus, the following are the proposed deadlines: > > Sept 7th - Cutoff date to notify the chairs and DISPATCH WG > mailing list of plans to submit a proposal. > ------------------------------------------------------------- > > This will help folks with similar topics to work together before > the meeting. If a preliminary charter proposal is available at > this point, please include it. Mary, Gonzalo: This is a quick notification of our intent to continue the work on SIP recording that was started in the Stockholm IETF. We are currently working on a charter proposal and will submit that by the next deadline -- Sept. 21, 2009. The media (slides, audio recording, minutes, drafts) relevant to the recording work discussed in Stockholm can be retrieved from http://www.softarmor.com/dispatch/IETF75/. Thanks, - 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 pkyzivat@cisco.com Fri Sep 4 07:55:48 2009 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 8A64B3A68C7 for ; Fri, 4 Sep 2009 07:55:48 -0700 (PDT) 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 PpWDLAxqINC1 for ; Fri, 4 Sep 2009 07:55:47 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2B52A3A6821 for ; Fri, 4 Sep 2009 07:55:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOfGoEpAZnme/2dsb2JhbADBKohBAZA6BYItgW4 X-IronPort-AV: E=Sophos;i="4.44,333,1249257600"; d="scan'208";a="56816446" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Sep 2009 14:55:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n84EtDTY020201; Fri, 4 Sep 2009 10:55:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n84EtDiQ013534; Fri, 4 Sep 2009 14:55:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 10:55:13 -0400 Received: from [10.86.254.246] ([10.86.254.246]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 10:55:12 -0400 Message-ID: <4AA12A4D.8090605@cisco.com> Date: Fri, 04 Sep 2009 10:55:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alan Johnston References: <4A9EE8F6.9040309@sipstation.com> <4A9FE3C4.5050805@cisco.com> <4AA018A2.2090707@sipstation.com> In-Reply-To: <4AA018A2.2090707@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2009 14:55:12.0882 (UTC) FILETIME=[B4A51D20:01CA2D6F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4204; t=1252076113; x=1252940113; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Call=20Control=20UUI=20for =20SIP=20Issue |Sender:=20 |To:=20Alan=20Johnston=20; bh=/PpuXYMy3mc47yCuyj8M4HGa6omQZFiy3WCTTvgQO4E=; b=IZthB4nh0P6F+6AIhFVTHtAUieYUp7KgQ6LRm62wpyaNwNtb7X3UDNLT1m eyhU9ABzupvFO+na6Fuhh7w55wX6mDnV+8eFpuYE835i6CSe9FXg4qEuVKtI LOujWTN/6g; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Call Control UUI for SIP Issue 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: Fri, 04 Sep 2009 14:55:48 -0000 Alan, Based on your answers, I'm ok with your categorization of cases. Thanks, Paul Alan Johnston wrote: > Paul, > > Thanks for your comments - see mine below. > > Thanks, > Alan > > Paul Kyzivat wrote: >> Alan, >> >> I agree it is a good idea to partition the use cases in this way. >> >> I'm a little confused about the criteria you give for UUI below, because >> - I thought one of the reasons originally given for the proposed >> mechanism was that it was needed before call establishment for >> purpose of making routing decisions. If so, that means that it >> impacts sip behavior. > > The information does need to be rendered and parsed at the time of call > establishment - that is why it is carried in an INVITE. But it is not > really used for SIP routing decisions. I suppose it could be used in > deciding whether to answer a call or reject it, but again I'd say that > is not SIP behavior. > >> >> - Also, isn't the applying of policy by sip elements also a change >> to sip behavior? > > No, the policy is just whether to pass the information element up the > protocol stack or whether to block its transport within a domain. The > policy isn't, because this type of UUI is present, do some special SIP > operation or invoke a special SIP feature. > > So, here's an example of what I mean by "changing SIP behavior". Lets > say we had this UUI mechanism but we didn't have the Refer-Sub: no > header field. One could argue that suppressing the REFER implicit > subscription is just a piece of user information, which is generated by > the UAC and consumed by the UAS, so why not transport it using the UUI > mechanism. Well, this information changes SIP behavior in that no > NOTIFY is sent. Hence, this would not be a suitable usage for this UUI > mechanism. >> >> Thanks, >> Paul >> >> Alan Johnston wrote: >>> Based on feedback during my presentation in Stockholm, I think I >>> have a good idea how to modify the proposed charter text. >>> >>> One issue perhaps needs a little more discussion so I'd like to kick >>> that off here. >>> >>> The question is, for some kind of information, when should a new SIP >>> header field be used, when should this UUI transport mechanism be >>> used, and when should a proprietary header field be used. It seemed >>> like we had some differing opinions on this with respect to UUI. I >>> think which approach depends on the information being transported. >>> Here's my take on this: >>> >>> New SIP header field to transport user information. I think a new >>> SIP header field is needed when: >>> 1. SIP behavior is changed >>> 2. The information is generated and consumed at the SIP layer by SIP >>> elements >>> 3. SIP elements besides the UAC and UAS might be interested and >>> consume the information >>> 4. There are specific privacy or cross-RAI issues involved with the >>> information being transported >>> 5. Interoperability is important >>> >>> UUI Transport mechanism. I think this mechanism is suitable when: >>> 1. The information is generated and consumed by an application using >>> SIP during session setup but not necessarily even SIP aware. >>> 2. SIP behavior is unchanged >>> 3. Generally only the UAC and UAS are interested in the information >>> 4. The information is expected to survive retargeting, redirection, >>> and retargeting >>> 5. SIP elements may need to apply policy about passing and screening >>> the information >>> 6. Multivendor interop is important >>> >>> Proprietary header field (the old P-header) >>> 1. The information is only of interest to UAC and UAS >>> 2. No SIP elements need apply policy to the information >>> 3. Single vendor or closed system application >>> >>> If we disagree strongly on these points, lets have that discussion >>> now, and this may help us formulate charter text about the mechanism >>> itself. >>> >>> Thanks, >>> Alan >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> > > From hsinnrei@adobe.com Fri Sep 4 08:42:21 2009 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 2F0E43A6A3C for ; Fri, 4 Sep 2009 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 NLbuXQVAccpO for ; Fri, 4 Sep 2009 08:42:13 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 5A7DA3A68DE for ; Fri, 4 Sep 2009 08:42:11 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSqE1VL9D4tMZDrmJfavYg5KPu4poWT8x@postini.com; Fri, 04 Sep 2009 08:42:34 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n84Fg9WG026479; Fri, 4 Sep 2009 08:42:10 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n84Fg2Y2007712; Fri, 4 Sep 2009 08:42:02 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 4 Sep 2009 08:42:01 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Fri, 4 Sep 2009 08:42:01 -0700 From: Henry Sinnreich To: "Simo.Veikkolainen@nokia.com" , "dispatch@ietf.org" , "mary.barnes@nortel.com" , "gonzalo.camarillo@ericsson.com" Date: Fri, 4 Sep 2009 08:41:58 -0700 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgAHb1p/ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6C69F765AB1hsinnreiadobecom_" MIME-Version: 1.0 Cc: "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] New topic proposal for DISPATCH 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: Fri, 04 Sep 2009 15:42:21 -0000 --_000_C6C69F765AB1hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to second such work, but a far deeper look under the hood is n= ecessary, so we don't do another Elbonia project. http://dilbert.com/strips/comic/2009-09-01/ Here are some not very mature thoughts on the scope of the work. The most interesting, ROI estimate and REST architecture support are at the= end. Servers Fundamentally, we need a registrar, a proxy and a presence server: Three in= total * What will be the duplication of servers and where specifically? * How does the SIP registrar communicate with the XMPP server(s)? * What may be the routing protocol(s) inside a SIP+XMMP network? Think o= f IMS as a stressing use case. User Agents * Same as with servers: How many and what protocol RFCs are there in the= combination? * Which of the "services" can be placed in the applications in the endpo= ints or in the network application protocols, such as SIP and XMPP. This is= the topic on infrastructure vs. endpoint applications. Application Protocol Stacks * How many protocol stacks does this involve and more to the point, how = many RFCs? * For SIP alone, see http://rfc3261.net/. What will be the total combine= d RFC count? NAT Traversal * Will STUN/TURN/ICE work the same for SIP and for XMPP? Return on Investment (ROI): Cost and effort by developers. More network inf= rastructure, not even counting B2B NEs. * What is the additional time/money required for developers that know SI= P to also learn XMPP and vice versa? This is all about return on investment= . Support for a REST-full architecture The WWW has a REST architecture was formulated in 2000, after the emergence= of SIP and XMMP. As a result of its architecture, the WWW has had a trans= formational effect on the following (this is not a complete list). Some SIP= work recommends already recommends REST, such as in RFC 4240 and in http:/= /tools.ietf.org/html/draft-griffin-bliss-rest-00 * Web applications from mail to office apps * Internet applications previously served by dedicated network applicati= ons protocols * Many other industries, from banking to newsprint to travel. And Oh, so= cial networks, they also have registrars... Now please keep in mind the WWW architecture uses basically only 3 componen= ts*: The URI for addressing, HTTP for transport and HTML for data rendering= , augmented by some other languages (XML) and namespaces. Can we benefit so= mething from the WWW architecture? If yes what specifically? Heresy: If the web developers could use HTTP only, what other application l= evel protocols do we really need except RTP/UDP? This includes in my mind TLS and DTLS for secure transport or even better I= MO: HIP for many reasons. * T.V. Raman: "Toward 2W, Beyond Web 2.0", Communications of the ACM, Febru= ary 2009 Many or most of these points may be moot or make no sense, but maybe should= be cleared up, in case there are more naive people like me that may be int= erested. My strict personal 2 cents. FRANK comments are most welcome. Henry On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" wrote: Hi, We would like to propose a new DISPATCH topic on how SIP and XMPP can be us= ed together in a complementary fashion. We have been working on a solution which combines SIP based VoIP and XMPP b= ased IM and Presence. The requirements and a proposed solution is outlined = in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 . The motivation for this work comes from experience which shows that most st= andards based VoIP deployments use SIP. At the same time, the Extensible Me= ssaging and Presence Protocol (XMPP) is widely used in instant messaging an= d presence services. An interesting scenario arises when a SIP based voice = (and video) service is combined together with an XMPP based instant messagi= ng and presence service. Note that the goal in this work is not SIP-XMPP protocol translation, but t= o define protocol extensions and best practises such that SIP based VoIP an= d XMPP based IM and presence could be seamlessly combined and offered to th= e end user. For rapid deployment, we assume no changes in the server infras= tructure, and instead impose new requirements and protocol extensions only = to the endpoints. We would like to get some discussion going on the use case itself as well a= s on the solution. Also, we would like to hear you thoughts on DISPATCH or = a new "dispatched" mini-WG as the home for such work. Exact charter proposal and problem statemen is to follow. Regards, Simo and Markus --_000_C6C69F765AB1hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] New topic proposal for DISPATCH I would like to second such work, but a far deeper l= ook under the hood is necessary, so we don’t do another Elbonia proje= ct.
http://dilbert.com/= strips/comic/2009-09-01/

Here are some not very mature thoughts on the scope of the work.
The most interesting, ROI estimate and REST architecture support are at the= end.

Servers

Fundamentally, we need a registrar, a proxy and a presence server: Three in= total
  • What will be the duplic= ation of servers and where specifically?
  • How does the SIP registrar = communicate with the XMPP server(s)?
  • What may be the routing pro= tocol(s) inside a SIP+XMMP network? Think of IMS as a stressing use case.

User Agents

  • Same as with servers: H= ow many and what protocol RFCs are there in the combination?
  • Which of the “service= s” can be placed in the applications in the endpoints or in the netwo= rk application protocols, such as SIP and XMPP. This is the topic on infras= tructure vs. endpoint applications.

Application Protocol Stacks

  • How many protocol stack= s does this involve and more to the point, how many RFCs?
  • For SIP alone, see http://rfc3261.net/. What will be the total co= mbined RFC count?

NAT Traversal

  • Will STUN/TURN/ICE work= the same for SIP and for XMPP?

Return on Investment (ROI): Cost and effort by developers. More network inf= rastructure, not even counting B2B NEs.

  • What is the additional = time/money required for developers that know SIP to also learn XMPP and vic= e versa? This is all about return on investment.

Support for a REST-full architecture

The WWW has a REST architecture was formulated in 2000, after the emergence= of SIP and XMMP.  As a result of its architecture, the WWW has had a = transformational effect on the following (this is not a complete list). Som= e SIP work recommends already recommends REST, such as in RFC 4240 and in <= a href=3D"http://tools.ietf.org/html/draft-griffin-bliss-rest-00">http://to= ols.ietf.org/html/draft-griffin-bliss-rest-00
 
  • Web applications from m= ail to office apps=20
  • Internet applications previ= ously served by dedicated network applications protocols
  • Many other industries, from= banking to newsprint to travel. And Oh, social networks, they also have re= gistrars...

Now please keep in mind the WWW architecture uses basically only 3 componen= ts*: The URI for addressing, HTTP for transport and HTML for data rendering= , augmented by some other languages (XML) and namespaces. Can we benefit so= mething from the WWW architecture? If yes what specifically?

Heresy: If the web developers could use HTTP only, what other application l= evel protocols do we really need except RTP/UDP?
This includes in my mind TLS and DTLS for secure transport or even better I= MO: HIP for many reasons.

* T.V. Raman: “Toward 2W, Beyond Web 2.0”, Communications of th= e ACM, February 2009

Many or most of these points may be moot or make no sense, but maybe should= be cleared up, in case there are more naive people like me that may be int= erested.

My strict personal 2 cents.

FRANK comments are most welcome.

Henry



On 9/4/09 7:09 AM, "Simo.Veikk= olainen@nokia.com" <Sim= o.Veikkolainen@nokia.com> wrote:

Hi,
 
We would like to propose a new DISPATCH topic on how SIP and XMPP can be us= ed together in a complementary fashion.
 
We have been working on a solution which combines SIP based VoIP and XMPP b= ased IM and Presence. The requirements and a proposed solution is outlined = in http://tools.ietf.org/html/draft-veikkolai= nen-sip-voip-xmpp-im-01 <http://tools.ietf.org/html/dr= aft-veikkolainen-sip-voip-xmpp-im-01> .
 
The motivation for this work comes from experience which shows that most st= andards based VoIP deployments use SIP. At the same time, the Extensible Me= ssaging and Presence Protocol (XMPP) is widely used in instant messaging an= d presence services. An interesting scenario arises when a SIP based voice = (and video) service is combined together with an XMPP based instant messagi= ng and presence service.
 
Note that the goal in this work is not SIP-XMPP protocol translation, but t= o define protocol extensions and best practises such that SIP based VoIP an= d XMPP based IM and presence could be seamlessly combined and offered to th= e end user. For rapid deployment, we assume no changes in the server infras= tructure, and instead impose new requirements and protocol extensions only = to the endpoints.
 
We would like to get some discussion going on the use case itself as well a= s on the solution. Also, we would like to hear you thoughts on DISPATCH or = a new "dispatched" mini-WG as the home for such work.
 
Exact charter proposal and problem statemen is to follow.
 
Regards,
Simo and Markus
 
 

--_000_C6C69F765AB1hsinnreiadobecom_-- From richard@shockey.us Fri Sep 4 13:00:46 2009 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 372043A6877 for ; Fri, 4 Sep 2009 13:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2lc0eZmsVnf for ; Fri, 4 Sep 2009 13:00:45 -0700 (PDT) Received: from outbound-mail-133.bluehost.com (outbound-mail-133.bluehost.com [67.222.39.23]) by core3.amsl.com (Postfix) with SMTP id 419623A6783 for ; Fri, 4 Sep 2009 13:00:45 -0700 (PDT) Received: (qmail 29949 invoked by uid 0); 4 Sep 2009 19:53:50 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 4 Sep 2009 19:53:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=OQ2yb4qQhsCzOaLULVBfDJTEKxxl4r0s0oZVkVmIBqKSSrumXIXhQCg+HyTuTSJF9ssJKrOkgQ9JhE2RglEz3WE+6J+GwqV+q3dTmoclVLnyzocMP3IhCtiBtvlUFYvw; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mjeqz-0000gp-OS; Fri, 04 Sep 2009 13:53:50 -0600 From: "Richard Shockey" To: "'Mary Barnes'" , , "'Gonzalo Camarillo'" References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 4 Sep 2009 15:53:41 -0400 Message-ID: <019d01ca2d99$67f0a1f0$37d1e5d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcohwNkciiguS2xuQiuKUNJpbaNnbQAuvWPQAeJSDFAA40D88A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: 'Hadriel Kaplan' Subject: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic Domain Registration 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: Fri, 04 Sep 2009 20:00:46 -0000 Dispatch Chairs: We would like to reserve some time during DISPATCH to discuss the topic of domain registration in SIP. A draft from Hadriel Kaplan that fully describes the issue will be forthcoming but the problem statement can be described in the following excerpt: In some environments, notably the Small-to-Medium Business (SMB) market, SIP devices in the Enterprise are effectively IP-PBX's,receiving PRI-type SIP trunk services from a SIP Service Provider (SSP). The SIP IP-PBX device is authoritative for its local domain of AoR's. Even if the IP-PBX has its own Domain Name, not every small business owner has a DNS, or has the technical capability to provision DNS entries (e.g., SRV's) appropriately in their DNS, or has the ability to do so through any third party which hosts their domain name(s),or may not wish to make their SIP device address known publicly. Furthermore, the SMB may not have its own Domain Name at all, and instead merely has an IP Address. Because a single SSP may support multiple thousands of such SMB IP- PBX's, it is impractical and cost-prohibitive to manually provision their IP Addresses in every SIP node along the path which needs to reach the SMB IP-PBX customer. Instead, a dynamic reachability mechanism is needed. Such a mechanism already exists for SIP: the REGISTER transaction. A REGISTER request transaction provides dynamic reachability information of an AoR for its authoritative domain. Since a REGISTER request mechanism is generally supported by most SIP Service Providers' equipment, it has become common practice for small IP-PBX's to use the mechanism as a means of providing their reachability information. In some cases interoperability problems have arisen, due to differing expectations and implementations of how such a mechanism should work in practice. Richard Shockey PSTN Mobile: +1 703.593.2683 skype/AIM: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 From richard@shockey.us Fri Sep 4 13:12:19 2009 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 E518F3A6A80 for ; Fri, 4 Sep 2009 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPQAt5ISwj1m for ; Fri, 4 Sep 2009 13:12:19 -0700 (PDT) Received: from outbound-mail-102.bluehost.com (outbound-mail-102.bluehost.com [69.89.22.12]) by core3.amsl.com (Postfix) with SMTP id 7588128C0CF for ; Fri, 4 Sep 2009 13:12:19 -0700 (PDT) Received: (qmail 3865 invoked by uid 0); 4 Sep 2009 20:06:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 4 Sep 2009 20:06:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=bijHYAljBqXUuyUwSgYAM1gJTyQXamE9F8ElivtDrFHen3PjRJviIb7I2w+lpiAlm6Ay9aWBTASXCQ7MlzD6v+15R6RcG4jwgQ5GKe2Uxnew9EhQseDArYUF6N3isSoI; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mjf2n-0001FJ-Bp; Fri, 04 Sep 2009 14:06:01 -0600 From: "Richard Shockey" To: , Date: Fri, 4 Sep 2009 16:05:53 -0400 Message-ID: <01a201ca2d9b$1c05bf80$54113e80$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcotmxrGGabvJ0eaS8WejQ+OiCHZZQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [dispatch] Results of a SIPforum effort to understand problems with Fax and SIP 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: Fri, 04 Sep 2009 20:12:20 -0000 The SIPforum has recently issued a report on ongoing issues with SIP and Fax that may be of interest to the larger SIP community. Work on understanding the problems with FAX and SIP are continuing and members of the IETF SIP community are invited to participate in future discussions. SIPforum FoIP Task Group Charter The proposed charter of the SIP Forum FoIP task group is to investigate ongoing issues with the deployment of fax services, specifically ITU T.38, in SIP networks. SIP networks cannot adequately replace analog PSTN in enterprises unless essential services such as FAX are accommodated. The use of ITU T.37 email based store and forward has not been successful due to the specific legal status fax enjoys in law and that fax communications has 3rd party confirmation of transmission and/or delivery in carrier billing records (non repudiation). Classic FAX (T.30) over G.711 has not proved to be reliable and SIP communications , in the future, may use other codecs that have been proven to break T.30 such as G.729 and other high compression codecs like SPEEDEX etc. The SIP Forum FoIP task group is chartered to accomplish the following tasks: 1. Fully document what the current issues are surrounding ITU T.38 in SIP networks. a. What interoperability testing procedures currently exist. b. What are the common factors in T.38 failure such as page length or lack of ECM support in carrier gateways and ATA's. c. Network packet loss considerations. 2. Determine what solutions are currently available to address the problem. 3. Determine if the problem can be solved within the scope of existing IETF SIP and ITU T.38 Recommendations. 4. If the problems can be solved using existing standards by tightening requirements, document the procedures vendors and carriers need to implement in an appropriate SIP Forum Technical Recommendation. 5. If, in the judgment of the SIP Forum FoIP WG, existing IETF and or ITU standards need to be modified, develop a strongly worded recommendation to the appropriate Standards Development Organization (SDO) on what the SIP Forum FoIP WG has discovered and recommend appropriate action by the SDO to remedy the issue. Information about the FoIP Task Group http://www.sipforum.org/content/view/310/252/ The Fax Problem Statement Report. http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,30 3/Itemid,75/ Richard Shockey Member Board of Directors SIPforum Co-Chair SIPforum Technical Task Groups PSTN Mobile: +1 703.593.2683 skype/AIM: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 From aallen@rim.com Mon Sep 7 03:37:06 2009 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 AD11D3A6781 for ; Mon, 7 Sep 2009 03:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_QP_LONG_LINE=1.396, 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 WHMt4yI3Lwqs for ; Mon, 7 Sep 2009 03:37:05 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id C2A0F3A6767 for ; Mon, 7 Sep 2009 03:37:05 -0700 (PDT) X-AuditID: 0a666446-b7b3fae000004aa1-12-4aa4e26b507e Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 16.2F.19105.B62E4AA4; Mon, 7 Sep 2009 06:37:31 -0400 (EDT) Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 06:37:30 -0400 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: Mon, 7 Sep 2009 06:37:29 -0400 Message-ID: <61968779B8AC4C4BAB421D4C12F008C01DF9F6FE@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-boucadair-dispatch-ipv6-atypes Thread-Index: AcovpzN93BXaDHlmQCWI1E0jnX/wAA== From: "Andrew Allen" To: , , X-OriginalArrivalTime: 07 Sep 2009 10:37:30.0899 (UTC) FILETIME=[33D2FE30:01CA2FA7] X-Brightmail-Tracker: AAAAAgAAAZEQnfst Subject: [dispatch] draft-boucadair-dispatch-ipv6-atypes 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, 07 Sep 2009 10:37:06 -0000 Can we request agenda time in Dispatch to discuss how to proceed with draft-= boucadair-dispatch-ipv6-atypes? Thanks Andrew ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From salvatore.loreto@ericsson.com Mon Sep 7 04:26:45 2009 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 3A0C928C0DE for ; Mon, 7 Sep 2009 04:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.387 X-Spam-Level: X-Spam-Status: No, score=-5.387 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, HELO_EQ_SE=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 o1Tney629HlG for ; Mon, 7 Sep 2009 04:26:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A3EB928C116 for ; Mon, 7 Sep 2009 04:26:43 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-cd-4aa4ee0da00d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 74.1E.06532.D0EE4AA4; Mon, 7 Sep 2009 13:27:09 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 13:27:07 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 13:27:07 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EDBEA24C9; Mon, 7 Sep 2009 14:27:06 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B21B421A17; Mon, 7 Sep 2009 14:27:06 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 59476219CB; Mon, 7 Sep 2009 14:27:06 +0300 (EEST) Message-ID: <4AA4EE09.50108@ericsson.com> Date: Mon, 07 Sep 2009 14:27:05 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 07 Sep 2009 11:27:07.0257 (UTC) FILETIME=[21DF2E90:01CA2FAE] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines 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, 07 Sep 2009 11:26:45 -0000 Hi, We would like to propose a new DISPATCH topic on "Disaggregated media": the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. The analysis of what types of disaggregated media can be implemented using existing protocol mechanisms, the pros and cons of using each of those mechanisms and also the scenarios that are not covered by current mechanisms are all described in : http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-media-00.txt This topic has been discussed on the mailing receiving quite high interest So we would like to hear you thoughts on DISPATCH or a new "dispatched" mini-WG as the home for such work. Charter proposal and problem statement is to follow. best regards Salvatore Loreto Mary Barnes wrote: > > Hi all, > > As was done for IETF-75, we are setting earlier deadlines for > discussing topics in DISPATCH prior to the WG session at IETF-76. > > We will again follow the deadlines for BoFs: > _http://www.ietf.org/meeting/cutoff-dates.html#76_ > > This provides enough time to dispatch topics prior to the meeting as > appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs, > mailing lists, etc. Thus, allowing us to have more focused and > constructive discussions on a smaller set of topics prior to the WG > session. > > Please note that the dates are much sooner than you might expect as > the time between IETF-75 and IETF-76 is 3 weeks less than the time > between IETF-74 and IETF-75. The document deadlines are 9 and 10 weeks > away from next Monday (August 24th). > > > Thus, the following are the proposed deadlines: > > Sept 7th - Cutoff date to notify the chairs and DISPATCH WG mailing > list of plans to submit a proposal. > -------------------------------------------------------------------------------------------------------- > > > This will help folks with similar topics to work together before the > meeting. If a preliminary charter proposal is available at this point, > please include it. > > > September 21st - Cutoff for charter proposals for topics. > -------------------------------------------------------- > > A charter proposal must consist of a minimum of a problem statement > and at least one milestone/deliverable. This deadline will allow time > for consideration of proposals that could potentially be "dispatched" > prior to the WG session. > > > September 28th - Topics that are to be the focus of IETF-76 are > announced. > --------------------------------------------------------------------------- > > > The idea here is to focus the discussion over the weeks preceding > IETF-76 on these main topics, noting that any new or updates to any > documents are due 3-4 weeks later. This will ensure we have > constructive discussions before the meeting and are actually able to > determine consensus as to where work should be progressed (e.g., > separate BoF, a new WG, an existing WG, individual document, etc.) at > IETF-76. Note, that the exact disposition for a topic may (per the > usual process) require follow-up and confirmation by the ADS and/or > IESG (e.g., for a new WG, Bof, individually sponsored document, etc.) > or with another WG to ensure agreement with the DISPATCH WG consensus > for the topic. > > > As discussed previously, the intention is not necessarily to preclude > folks submitting documents on other topics, however, it is very > unlikely there would be agenda time allocated to documents/topics > submitted after the deadlines. We can include one or two slides on > these topics in the DISPATCH WG chair charts so that the authors can > gather other interested parties to contribute to the work. > > Regards, > Mary and Gonzalo > DISPATCH WG co-chairs > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From kumiko@cs.columbia.edu Mon Sep 7 07:17:43 2009 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 801783A69BB for ; Mon, 7 Sep 2009 07:17:43 -0700 (PDT) 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 8pc-byfc0G-D for ; Mon, 7 Sep 2009 07:17:42 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 7957C3A6949 for ; Mon, 7 Sep 2009 07:17:42 -0700 (PDT) Received: from dyn-160-39-54-78.dyn.columbia.edu (dyn-160-39-54-78.dyn.columbia.edu [160.39.54.78]) (user=ko2155 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n87EI69C020825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Sep 2009 10:18:06 -0400 (EDT) Message-Id: From: Kumiko Ono To: mary.barnes@nortel.com, Gonzalo.Camarillo@ericsson.com, dispatch@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-4--852020538 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Sep 2009 10:18:06 -0400 X-Mailer: Apple Mail (2.936) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.7 Subject: [dispatch] a new proposal for reference to an earlier communication 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, 07 Sep 2009 14:17:43 -0000 --Apple-Mail-4--852020538 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, We are going to submit a proposal for reference to an earlier communication. This is to reduce false positives during SPIT filtering. Even if caller IDs are not part of the recipient's white lists, the recipients could label incoming calls using the reference, e.g., the Message-ID of an email sent from the caller to the recipient. Although the objectives are different, similar proposals in terms of references to another communication (mostly limited to a dialog) have been discussed like in "draft-worley-references-04." We would like to hear your thoughts of our proposal. Thanks, Kumiko --Apple-Mail-4--852020538 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello,

We = are going to submit a proposal for reference to an earlier = communication.

This is to reduce false = positives during SPIT filtering. Even if caller IDs are not part of the = recipient's white lists,
the recipients could label incoming = calls using the reference, e.g., the Message-ID of an email sent from = the caller to the recipient.

Although the = objectives are different, similar proposals in terms of references = to another communication (mostly limited to a dialog) have been = discussed 
like in "draft-worley-references-04."<= /div>

We would like to hear your thoughts of our = proposal.

Thanks,
Kumiko

=





= --Apple-Mail-4--852020538-- From mary.barnes@nortel.com Mon Sep 7 08:45:53 2009 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 99E833A6869 for ; Mon, 7 Sep 2009 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 QJzx4933BVcn for ; Mon, 7 Sep 2009 08:45:52 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6E4EB3A6ABA for ; Mon, 7 Sep 2009 08:45:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n87FkCG13751; Mon, 7 Sep 2009 15:46:13 GMT 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, 7 Sep 2009 10:48:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FCF70A5@zrc2hxm0.corp.nortel.com> In-Reply-To: <61968779B8AC4C4BAB421D4C12F008C01DF9F6FE@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-boucadair-dispatch-ipv6-atypes Thread-Index: AcovpzN93BXaDHlmQCWI1E0jnX/wAAAKkRVg References: <61968779B8AC4C4BAB421D4C12F008C01DF9F6FE@XCH47YKF.rim.net> From: "Mary Barnes" To: "Andrew Allen" , , Subject: Re: [dispatch] draft-boucadair-dispatch-ipv6-atypes 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, 07 Sep 2009 15:45:53 -0000 Hi Andrew, At this point in time, we're not handling agenda requests per se. Right now, we want to know the topics for which folks want feedback PRIOR to IETF-76 so that we can use the agenda time to discuss issues that can't be resolved on the mailing list before then. We can take this as a placeholder for this topic and thus, we would expect to see a detailed problem statement, etc. on or before Sept. 21st., per the IETF-76 DISPATCH deadlines: http://www.ietf.org/mail-archive/web/dispatch/current/msg00500.html Just a note that when I summarized the status of the post-IETF-75 topics, this one had received no ML discussion nor indication of interest in working on this problem: http://www.ietf.org/mail-archive/web/dispatch/current/msg00501.html So, you really need to get some WG feedback on this proposal if you want it to move forward. =20 Thanks, Mary.=20 -----Original Message----- From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Monday, September 07, 2009 5:37 AM To: Barnes, Mary (RICH2:AR00); Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org Cc: mohamed.boucadair@orange-ftgroup.com Subject: draft-boucadair-dispatch-ipv6-atypes Can we request agenda time in Dispatch to discuss how to proceed with draft-boucadair-dispatch-ipv6-atypes? Thanks Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From volkerh@bell-labs.com Tue Sep 8 19:00:04 2009 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 7F13B28C1E3; Tue, 8 Sep 2009 19:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 Idkc3sHd42HG; Tue, 8 Sep 2009 19:00:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6808728C1DE; Tue, 8 Sep 2009 19:00:01 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n8920UZx000280; Tue, 8 Sep 2009 21:00:30 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n8920UvP021112; Tue, 8 Sep 2009 21:00:30 -0500 (CDT) Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 8 Sep 2009 21:00:30 -0500 Message-ID: <4AA70C29.8020804@bell-labs.com> Date: Tue, 8 Sep 2009 22:00:09 -0400 From: Volker Hilt User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "JOHNSON, CAROLYN R, ATTLABS" References: <4A8D551B.7060308@alcatel-lucent.com> <9DE31798099D044DA5F3C0DEAB107C5A03C451E4@misout7msgusr7d.ugd.att.com> In-Reply-To: <9DE31798099D044DA5F3C0DEAB107C5A03C451E4@misout7msgusr7d.ugd.att.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.39 Cc: "NOEL, ERIC C, ATTLABS" , DISPATCH , SIP-OVERLOAD Subject: Re: [dispatch] [sip-overload] Revised Charter Proposal for SIP Overload 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, 09 Sep 2009 02:00:05 -0000 Carolyn, thanks for your feedback! I'll update the charter proposal to address the comment. Thanks, Volker JOHNSON, CAROLYN R, ATTLABS wrote: > Volker, > Sorry for the delay, this got stuck in my drafts folder while I was out > on vacation. > > One comment on the last dashed item: > - The second mechanism aims at preventing overload in SIP servers by > distributing load control filters to SIP servers that throttle calls > based on their destination domain, telephone number prefix or for a > specific user. Such filters can be used, for example, to throttle calls > to a hotline during a ticket-giveaway event. > > I suggest replacing "telephone number" with "destination routing" so as > not to limit to applications that use telephone prefixes. I believe it > will be more general without losing the applicability to telephone IDs. > > The charter is clearly laid out. > Regards, > > Carolyn > > > -----Original Message----- > From: sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt > Sent: Thursday, August 20, 2009 9:52 AM > To: DISPATCH; SIP-OVERLOAD > Subject: [sip-overload] Revised Charter Proposal for SIP Overload > > All, > > below is an revised SIP Overload Control charter proposal. I have > received a few comments that are reflected in the new proposal. > > All comments, thoughts, feedback is very welcome! > > Thanks, > > Volker > > > > SIP Overload Control WG Charter > ------------------------------- > > As with any network element, a Session Initiation Protocol (SIP) server > can suffer from overload when the number of SIP messages it receives > exceeds the number of messages it can process. Overload is said to occur > when a SIP server does not have sufficient resources to process all > incoming SIP messages. These resources can include CPU, memory, network > bandwidth, input/output, or disk resources. > > Overload can pose a serious problem for a network of SIP servers. During > periods of overload, the throughput of a network of SIP servers can be > significantly degraded. In fact, overload may lead to a situation in > which the throughput drops down to zero or a small fraction of the > original processing capacity. This is often called congestion collapse. > > The objective of a SIP overload control mechanism is to enable SIP > servers to operate close to their capacity limit during times of > overload. > > The SIP protocol provides a limited mechanism for overload control > through its 503 (Service Unavailable) response code and the Retry-After > header. However, this mechanism cannot fully prevent overload of a SIP > server and it cannot prevent congestion collapse. In fact, its on/off > behavior may cause traffic to oscillate and shift between SIP servers > and thereby worsen an overload condition. A detailed discussion of the > SIP overload problem, the problems with the 503 (Service Unavailable) > response code and the Retry-After header and the requirements for a SIP > overload control mechanism can be found in RFC5390. > > The objective of the proposed working group is to develop mechanisms for > SIP overload control. Two complementary approaches exist for handling > overload situations: > - The first mechanism aims at preventing overload in SIP servers by > adjusting the incoming load to a level that is acceptable for this > server. This mechanism uses implicit and/or explicit feedback to > determine when an overload condition occurs in a SIP server and a > reduction in load is required. > - The second mechanism aims at preventing overload in SIP servers by > distributing load control filters to SIP servers that throttle calls > based on their destination domain, telephone number prefix or for a > specific user. Such filters can be used, for example, to throttle calls > to a hotline during a ticket-giveaway event. > > Specifically, the proposed working group will develop the following > deliverables: > 1. A document describing key design considerations for a SIP overload > control mechanism. > 2. A specification for an SIP overload control mechanism based on > implicit/explicit feedback. > 3. A specification for a SIP load filtering mechanism. > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From dean.willis@softarmor.com Tue Sep 8 19:48:44 2009 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 92E0A3A6808 for ; Tue, 8 Sep 2009 19:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 vL3I1Ttbsfil for ; Tue, 8 Sep 2009 19:48:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CA3ED3A6802 for ; Tue, 8 Sep 2009 19:48:43 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n892n8f3031915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Sep 2009 21:49:10 -0500 Message-Id: <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <019d01ca2d99$67f0a1f0$37d1e5d0$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 21:49:02 -0500 References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, 'Hadriel Kaplan' , 'Gonzalo Camarillo' Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic Domain Registration 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, 09 Sep 2009 02:48:44 -0000 On Sep 4, 2009, at 2:53 PM, Richard Shockey wrote: > Dispatch Chairs: We would like to reserve some time during DISPATCH > to > discuss the topic of domain registration in SIP. It seems like you're proposing a deep and fundamental rewrite of the Internet's name architecture, replacing RFC 3263 and its use of DNS with some sort of SIP REGISTER technique. Or maybe I'm missing it entirely, and what you're proposing is a way to use SIP REGISTER messages to populate a DNS SRV record within a registry? This raises the question of delegation to that registry -- the registry has to be authoritative for all of example.com in order to be able to host an srv record for example.com. So your mythical SMB is still going to require a DNS service provider that has to be meaningfully provisioned. It's just a question of the outsourcing contract, and I fail to see a need for protocol work here. After all, we have dynamic DNS, and it works pretty darned well for me today. So what you talking 'bout, Shockey? -- Dean From Simo.Veikkolainen@nokia.com Wed Sep 9 01:09:58 2009 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 9E42F3A6938 for ; Wed, 9 Sep 2009 01:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 oQuPn3n276JR for ; Wed, 9 Sep 2009 01:09:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6B8993A68BE for ; Wed, 9 Sep 2009 01:09:57 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8989qtb003519; Wed, 9 Sep 2009 11:10:10 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 11:10:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 11:09:57 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 9 Sep 2009 10:09:57 +0200 From: To: Date: Wed, 9 Sep 2009 10:09:51 +0200 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: AcotWT2FbUxPta4cRAGZsbLF5v6+tgDyqLYg Message-ID: References: <1D405AF2-4211-4F39-A2AB-26C1DD0AE1AF@edvina.net> In-Reply-To: <1D405AF2-4211-4F39-A2AB-26C1DD0AE1AF@edvina.net> 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-OriginalArrivalTime: 09 Sep 2009 08:09:57.0150 (UTC) FILETIME=[EB679BE0:01CA3124] Cc: dispatch@ietf.org, Markus.Isomaki@nokia.com, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 09 Sep 2009 08:09:58 -0000 =20 >-----Original Message----- >From: ext Olle E. Johansson [mailto:oej@edvina.net]=20 >Sent: 04 September, 2009 15:14 >To: Veikkolainen Simo (Nokia-D/Helsinki) >Cc: dispatch@ietf.org; Mary Barnes; Camarillo Gonzalo; Isomaki=20 >Markus (Nokia-CIC/Espoo); Saint-Andre Peter >Subject: Re: [dispatch] New topic proposal for DISPATCH > > >4 sep 2009 kl. 14.09 skrev : > >> Hi, >> >> We would like to propose a new DISPATCH topic on how SIP and=20 >XMPP can=20 >> be used together in a complementary fashion. >> >> We have been working on a solution which combines SIP based VoIP and=20 >> XMPP based IM and Presence. The requirements and a proposed solution=20 >> is outlined in=20 >> http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 >> . >> >> The motivation for this work comes from experience which shows that=20 >> most standards based VoIP deployments use SIP. At the same time, the=20 >> Extensible Messaging and Presence Protocol (XMPP) is widely used in=20 >> instant messaging and presence services. An interesting scenario=20 >> arises when a SIP based voice (and video) service is=20 >combined together=20 >> with an XMPP based instant messaging and presence service. >> >> Note that the goal in this work is not SIP-XMPP protocol=20 >translation,=20 >> but to define protocol extensions and best practises such that SIP=20 >> based VoIP and XMPP based IM and presence could be=20 >seamlessly combined=20 >> and offered to the end user. For rapid deployment, we assume no=20 >> changes in the server infrastructure, and instead impose new=20 >> requirements and protocol extensions only to the endpoints. >> >> Exact charter proposal and problem statemen is to follow. > >The XMPP forum has a few drafts on this, so we should=20 >coordinate with them. There are a lot of issues to sort out.=20 >We had a workshop on this topic with Asterisk, Kamailio and a=20 >few other products at Inria in France and saw a lot of issues=20 >to sort out both in regards to IM and presence. We have presented the above draft in the XMPP WG BoF in San Francisco earli= er this year. I agree both the IETF and the XSF would need to be aware, but= preferably there should be one place where the concepting happens. We thou= ght DISPATCH might be the right place for this.=20 >For Asterisk we have both SIP and XMPP telephony, for Kamailio=20 >we have modules that try to bridge presence updates and IM. > >I think it's hard to separate protocol translation. It's all=20 >about making it work together seamlessly. Our idea was to specify a solution which admittedly leaves some aspects unt= ouched, but - on the other hand - would offer a solution to an issue we see= is relevant and which would be rapidly deployable. There are already quite= a few drafts available on protocol interworking (draft-saintandre-sip-xmpp= -*). Simo >/O >= From ranjit@motorola.com Wed Sep 9 02:34:49 2009 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 45BA23A68F0; Wed, 9 Sep 2009 02:34:49 -0700 (PDT) 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 l-IsSdh4DVSD; Wed, 9 Sep 2009 02:34:43 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 018293A67FF; Wed, 9 Sep 2009 02:34:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1252488913!9042588!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18198 invoked from network); 9 Sep 2009 09:35:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2009 09:35:14 -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 n899ZBvq025280; Wed, 9 Sep 2009 02:35:13 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n899ZBon024409; Wed, 9 Sep 2009 04:35:11 -0500 (CDT) 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 n899Z9l4024399; Wed, 9 Sep 2009 04:35:10 -0500 (CDT) 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_01CA3130.C421AE9C" Date: Wed, 9 Sep 2009 17:34:43 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B09167F54@ZMY16EXM66.ds.mot.com> In-Reply-To: <0E48B768805E4D44A70709C8AE09209003AFC6A4@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted Thread-Index: AcoPSGlfXjMN39SUTDiDCIozl/Ik3gPv+k6AACM0FAAEZq/OIA== References: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> <0E48B768805E4D44A70709C8AE09209003AFC6A4@EMAILEMEA3.jnpr.net> From: "Avasarala Ranjit-A20990" To: "Gilad Shaham" X-CFilter-Loop: Reflected Cc: sip@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] [Sip] New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted 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, 09 Sep 2009 09:34:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3130.C421AE9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gilad =20 Thanks for reviewing the document. Here my comments with Regards=20 Ranjit=20 =20 ________________________________ From: Gilad Shaham [mailto:gshaham@juniper.net]=20 Sent: Tuesday, August 18, 2009 5:50 AM To: Avasarala Ranjit-A20990; dispatch@ietf.org; sip@ietf.org Subject: RE: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted Hi, =20 See some comments =20 Page 5: "... For e.g. the subscriber wanted to diverted all incoming calls to voice-mail, between 3.00 p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration as 3.00 to 4.00 p.m" Some of the sentence needs restructuring and I also don't fully understand the example. Is it AM-PM or wrong field was configured?=20 Agreed. Will correct the sentence.=20 =20 Page 12: What if time-range is missing? What should be the default? Sounds to me the default should be the current time with no end date.=20 if time-range is missing, then notifications for all communication diversions are sent.=20 =20 Page 14: In Comm-div-info-selection-criteria there are several disable-* subsections, yet their text describes these element gives the subscriber option of adding information. Shouldn't this be for omitting information or alternatively, call these elements "enable-*" or did I misunderstand the purpose.=20 E.g disable-originating-user-info -> this element gives the subscriber the option of adding originating-user-info element to the notification information. The default value is false which means that the subscriber wants the originating-user-info element to be present as part of the notification information. If the value is set to TRUE, then originating-user-info element is removed from the notification information document.=20 =20 Page 16: Boss Should be Boss=20 Corrected. =20 It might be also useful to see an example of periodic request.=20 Will see if I can add one.=20 =20 Page 21: 503 is there, but I don't see 500. Some implementations will avoid 503 and use 500 due to discussion related to this http://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now expired, but still affected some vendor decisions). I might be able to think of some scenario that involves 502, but I assume this is a result of the diversion implementation itself so maybe that's the context of this discussion.=20 Will add 500 also.=20 =20 Thanks =20 Thanks Gilad =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Monday, August 17, 2009 10:07 AM To: dispatch@ietf.org; sip@ietf.org Subject: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted =20 Hi All=20 We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info=20 It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-no tification-01.txt =20 This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604.=20 Please review and comment Regards=20 Ranjit=20 ------_=_NextPart_001_01CA3130.C421AE9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of = "draft-avasasarala-dispatch-comm-diversion-info" draft submitted
Hi Gilad
 
Thanks for reviewing the document. Here my = comments with=20 <Ranjit>
Regards
Ranjit
 

From: Gilad Shaham = [mailto:gshaham@juniper.net]=20
Sent: Tuesday, August 18, 2009 5:50 AM
To: = Avasarala=20 Ranjit-A20990; dispatch@ietf.org; sip@ietf.org
Subject: RE: = [Sip] New=20 version of"draft-avasasarala-dispatch-comm-diversion-info" draft=20 submitted

Hi,

 

See some=20 comments

 

Page=20 5:

   “... For =
e.g. the subscriber wanted to diverted all incoming calls to =
voice-mail,
   between 3.00 =
p.m. to 4.00 p.m.  Yet, by mistake she configures =
the
   time-duration as =
3.00 to 4.00 p.m”

Some of the = sentence=20 needs restructuring and I also don’t fully understand the example. = Is it AM-PM=20 or wrong field was configured? 

<Ranjit>=20 Agreed.  Will correct the=20 sentence. 

 

Page=20 12:

What if = time-range is=20 missing? What should be the default? Sounds to me the default should be = the=20 current time with no end date. 

<Ranjit> = if=20 time-range is missing, then notifications for all communication = diversions=20 are sent. 

 

Page=20 14:

In=20 Comm-div-info-selection-criteria there are several disable-* = subsections, yet=20 their text describes these element gives the subscriber option of adding = information. Shouldn’t this be for omitting information or = alternatively, call=20 these elements “enable-*” or did I misunderstand the = purpose. 

<Ranjit>  E.g=20 disable-originating-user-info -> this element gives the = subscriber the=20 option of adding originating-user-info element to the notification=20 information. The default value is false which means that the = subscriber=20 wants the originating-user-info element to be present as part of the=20 notification information. If the value is set to TRUE, then=20 originating-user-info element is removed from the notification = information=20 document. 

 

Page=20 16:

           &=
nbsp; =
<user-name>Boss</originating-user-name>

Should=20 be

           &=
nbsp; <user-name>Boss</user-name> 
<Ranjit> =
Corrected.
 <=
/FONT>


It might be =
also useful=20
to see an example of periodic request. 


<Ranjit> Will see if =
I can add=20
one. <=
/FONT>


 


Page=20
21:


503 is there, =
but I=20
don’t see 500. Some implementations will avoid 503 and use 500 due =
to discussion=20
related to this http=
://tools.ietf.org/html/draft-hilt-sip-correction-503-01=20
(now expired, but still affected some vendor decisions). I might be able =
to=20
think of some scenario that involves 502, but I assume this is a result =
of the=20
diversion implementation itself so maybe that’s the context of =
this=20
discussion. 


<Ranjit> Will=20
add 500=20
also. 
=


&=
nbsp;


Thanks


 


Thanks


Gilad


 










From:=20
sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avasarala=20
Ranjit-A20990
Sent: =
Monday,=20
August 17, 2009 10:07 AM
To:=20
dispatch@ietf.org; sip@ietf.org
Subject: [Sip] New version=20
of"draft-avasasarala-dispatch-comm-diversion-info" draft=20
submitted


 


Hi =
All=20



We have =
submitted an=20
updated version of draft-avasasarala-dispatch-comm-diversion-info=20



It can be =
accessed at:=20
http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm=
-div-notification-01.txt


This draft =
proposes a=20
SIP Event package for Communication Diversions Notification Information =
and=20
conforms to procedures and schema described in 3GPP TS=20
24.604. 


Please review =
and=20
comment


Regards=20

Ranjit=20
------_=_NextPart_001_01CA3130.C421AE9C-- From vkg@alcatel-lucent.com Wed Sep 9 09:09:20 2009 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 A945F3A6A1C for ; Wed, 9 Sep 2009 09:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=-0.585, 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 SJkb8zjfGUEv for ; Wed, 9 Sep 2009 09:09:19 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 371FC3A69C1 for ; Wed, 9 Sep 2009 09:09:18 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n89G9oms014868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Sep 2009 11:09:50 -0500 (CDT) 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 n89G9mqX003958; Wed, 9 Sep 2009 11:09:48 -0500 (CDT) Message-ID: <4AA7D34C.2030804@alcatel-lucent.com> Date: Wed, 09 Sep 2009 11:09:48 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "dispatch@ietf.org" 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: "Jain, Rajnish" , Hadriel Kaplan Subject: [dispatch] TCP and SCTP connection reuse 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: Wed, 09 Sep 2009 16:09:20 -0000 Folks: Before the summer, we had released a new TCP/SCTP connection reuse draft in the (now defunct) SIP WG. With the formation of dispatch, we were advised to submit it to dispatch for a decision on where to handle this work. Essentially, the draft documents the practice of reusing TCP (and SCTP) connections that is employed by some SIP implementations today. TCP and SCTP transport reuse were originally a part of the draft-ietf-sip-connect-reuse draft, but were taken out before we progressed that draft to the IESG. Can we kindly ask the dispatch WG to review and comment on the the TCP and SCTP connection reuse draft? All comments received from the first iteration of the draft in the SIP WG have been duly addressed in this version. It will also be helpful if the WG and chairs could provide some guidance on how to move this work forward (i.e., AD-sponsored individual draft, take it to sipcore, etc.) The draft can be retrieved from: http://tools.ietf.org/html/draft-jain-dispatch-sip-transport-connection-reuse-00 Thank you, - 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 L.Liess@telekom.de Thu Sep 10 07:52:17 2009 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 B784F28C123 for ; Thu, 10 Sep 2009 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=0.284, 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 p2SHz6l2dL5t for ; Thu, 10 Sep 2009 07:52:17 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 7CC8E28C121 for ; Thu, 10 Sep 2009 07:52:16 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 10 Sep 2009 16:52:45 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 16:52:45 +0200 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, 10 Sep 2009 16:52:45 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00363D958@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Topic for DISPATCH: Alert-Info URNs thread-index: AcoyJltvVmOzX1/dQmST6hgnSUPT5w== From: To: , , X-OriginalArrivalTime: 10 Sep 2009 14:52:45.0560 (UTC) FILETIME=[5B500F80:01CA3226] Cc: Martin.Huelsemann@telekom.de, R.Jesske@telekom.de Subject: [dispatch] Topic for DISPATCH: Alert-Info URNs 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, 10 Sep 2009 14:52:17 -0000 Mary, Gonzalo, At the IETF-75 we had a presentation and a discussion in BLISS on the = "Alert-Info URNs" proposal, described in = http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt. = During the discussion, it was recommended to submit the work to DISPATCH = and to document the interop problems.=20 So, we would like to propose this as a new topic for DISPATCH.=20 The motivation for this work comes from interoperability problems when = SIP services require the semantic for a ring- / ringback-tone to be = transmitted in in a SIP-message. =20 The RFC 3261 allows an UAS or proxy to provide a specific ring- = /ringback-tone as a reference (e.g. HTTP URI) which can be played to the = user in the Alert-Info header. This mechanism does not ensure = interoperability when there is no common understanding of the referenced = content (different countries or vendors, hearing impaired) or when the = user has his own tones configured in the end device.=20 For interoperability of services as call waiting, call forwarding, blind = transfer, automatic callback, call hold or emergency annoncements sent = over PBX systems, a mechanism is needed which allows the UAs and proxies = to transmit an indication which contains the semantic of the rendering = instead of the rendering itself and allows the receiving UA to decide = about the concrete rendering.=20 The charter proposal and the updated draft are to follow.=20 Kind regards Laura From jmpolk@cisco.com Thu Sep 10 13:13:37 2009 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 BE1543A6B7C for ; Thu, 10 Sep 2009 13:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 RHWqUu9KqfoT for ; Thu, 10 Sep 2009 13:13:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 887853A686B for ; Thu, 10 Sep 2009 13:13:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwGAF/7qEqrR7PD/2dsb2JhbACIV71hiEYBkDYFhBg X-IronPort-AV: E=Sophos;i="4.44,366,1249257600"; d="scan'208";a="203541449" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Sep 2009 20:14:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n8AKEAjl026430; Thu, 10 Sep 2009 13:14:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8AKEADl020544; Thu, 10 Sep 2009 20:14:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 13:14:10 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.10.99]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 13:14:10 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Sep 2009 15:14:10 -0500 To: "Vijay K. Gurbani" , "dispatch@ietf.org" From: "James M. Polk" In-Reply-To: <4AA7D34C.2030804@alcatel-lucent.com> References: <4AA7D34C.2030804@alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 10 Sep 2009 20:14:10.0375 (UTC) FILETIME=[41F54D70:01CA3253] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1743; t=1252613650; x=1253477650; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20TCP=20and=20SCTP=20connect ion=20reuse=20draft |Sender:=20; bh=/diYGfXjuWaakz8Brcvc4eq2uvmptMUJmypM+hQlCjk=; b=MSUQ7r7dU/6Na7Qm5GDEaJnGxzYoZQitaWW1xx4Xr/s5j2ypTHy02NLcnM lRqtmW2+eICnHtAwcLkTF+4GOA79GyhI2lQN+3ZE9yOPrmmiKPNGjiuevhyu Ty4ANIQUzJ; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse 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: Thu, 10 Sep 2009 20:13:37 -0000 Vijay wrt the transport aspects of this ID, shouldn't the folks in the transport area be contacted? TCPM WG currently controls any TCP related efforts, and TSVWG controls all SCTP related efforts. James At 11:09 AM 9/9/2009, Vijay K. Gurbani wrote: >Folks: Before the summer, we had released a new >TCP/SCTP connection reuse draft in the (now defunct) SIP >WG. With the formation of dispatch, we were advised to >submit it to dispatch for a decision on where to handle >this work. > >Essentially, the draft documents the practice of reusing TCP >(and SCTP) connections that is employed by some SIP >implementations today. TCP and SCTP transport reuse were >originally a part of the draft-ietf-sip-connect-reuse draft, >but were taken out before we progressed that draft to the IESG. > >Can we kindly ask the dispatch WG to review and comment on >the the TCP and SCTP connection reuse draft? All comments >received from the first iteration of the draft in the SIP WG >have been duly addressed in this version. > >It will also be helpful if the WG and chairs could provide >some guidance on how to move this work forward (i.e., >AD-sponsored individual draft, take it to sipcore, etc.) > >The draft can be retrieved from: > >http://tools.ietf.org/html/draft-jain-dispatch-sip-transport-connection-reuse-00 > >Thank you, > >- 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 vkg@alcatel-lucent.com Thu Sep 10 14:52:55 2009 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 5D9C828C227 for ; Thu, 10 Sep 2009 14:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 7am8R5wuSKew for ; Thu, 10 Sep 2009 14:52:53 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 35D4328C21E for ; Thu, 10 Sep 2009 14:52:53 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n8ALrPK5024082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 16:53:26 -0500 (CDT) 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 n8ALrPEN022386; Thu, 10 Sep 2009 16:53:25 -0500 (CDT) Message-ID: <4AA97555.6010304@alcatel-lucent.com> Date: Thu, 10 Sep 2009 16:53:25 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "James M. Polk" References: <4AA7D34C.2030804@alcatel-lucent.com> In-Reply-To: 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@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse 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: Thu, 10 Sep 2009 21:52:55 -0000 James M. Polk wrote: > Vijay > > wrt the transport aspects of this ID, shouldn't the folks in the > transport area be contacted? > TCPM WG currently controls any TCP related efforts, and TSVWG controls > all SCTP related efforts. James: That's an interesting comment. However, we are not proposing any changes to TCP or SCTP, so I am not sure that TCPM and TSVWG will be interested in this particular work. That said, I think TSVWG may be interested in eye-balling this document since SCTP is (still) relatively new and not many SIP implementations exist that do SCTP connection reuse today. Maybe this draft could be expert reviewed by someone from TSVWG to make sure that our use of SCTP is indeed within the norm? I think this may be a good idea. Thank you for your time and comment. - 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 Sep 10 23:05:35 2009 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 71C073A6783 for ; Thu, 10 Sep 2009 23:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 2fRLBKaw08-G for ; Thu, 10 Sep 2009 23:05:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 623863A672F for ; Thu, 10 Sep 2009 23:05:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFAD2FqUqrR7PD/2dsb2JhbACIV7twiEYBkC8FhBg X-IronPort-AV: E=Sophos;i="4.44,369,1249257600"; d="scan'208";a="188942570" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 11 Sep 2009 06:06:05 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n8B665it013831; Thu, 10 Sep 2009 23:06:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n8B665ji014776; Fri, 11 Sep 2009 06:06:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 23:06:04 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.10.99]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 23:06:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Sep 2009 01:05:40 -0500 To: "Vijay K. Gurbani" From: "James M. Polk" In-Reply-To: <4AA97555.6010304@alcatel-lucent.com> References: <4AA7D34C.2030804@alcatel-lucent.com> <4AA97555.6010304@alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Sep 2009 06:06:04.0259 (UTC) FILETIME=[F1E1F330:01CA32A5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1229; t=1252649165; x=1253513165; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20TCP=20and=20SCTP=20connect ion=20reuse=20draft |Sender:=20; bh=8VP9V3uss4fPPaJ7VE5UUQZ3Ucu/OC5ZQ+N93xesIfQ=; b=nMvpBwHfewg/6RvalwBEoennxHlGx3W2I1HBkOCrsH3xt3nr6wL5MSB9jF 9JF1+GZI4o1ggqXuMnmf3dHdlZuJboRgYLdTH4Lu2AMWa2PIpWftxH/F5xrP uJMXNlZoGN; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse 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: Fri, 11 Sep 2009 06:05:35 -0000 At 04:53 PM 9/10/2009, Vijay K. Gurbani wrote: >James M. Polk wrote: >>Vijay >>wrt the transport aspects of this ID, shouldn't the folks in the >>transport area be contacted? >>TCPM WG currently controls any TCP related efforts, and TSVWG >>controls all SCTP related efforts. > >James: That's an interesting comment. However, we are not >proposing any changes to TCP or SCTP, so I am not sure that >TCPM and TSVWG will be interested in this particular work. > >That said, I think TSVWG may be interested in eye-balling >this document since SCTP is (still) relatively new and >not many SIP implementations exist that do SCTP connection reuse >today. Maybe this draft could be expert reviewed by someone >from TSVWG to make sure that our use of SCTP is indeed >within the norm? I think this may be a good idea. I think this may be a good idea too... I wonder who you can get to ask for volunteers in TSVWG? ;-) James >Thank you for your time and comment. > >- 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 Markus.Isomaki@nokia.com Fri Sep 11 06:11:40 2009 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 ABB603A682E for ; Fri, 11 Sep 2009 06:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.071 X-Spam-Level: X-Spam-Status: No, score=-5.071 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 XJkffibeBbmv for ; Fri, 11 Sep 2009 06:11:28 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D568D28C0F9 for ; Fri, 11 Sep 2009 06:11:27 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8BDBHNe017422; Fri, 11 Sep 2009 16:11:32 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 16:11:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 16:11:22 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 11 Sep 2009 15:11:21 +0200 From: To: , , , , Date: Fri, 11 Sep 2009 15:11:20 +0200 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgAHb1p/AVb60MA= Message-ID: References: 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_B3F72E5548B10A4A8E6F4795430F8418125E6740DFNOKEUMSG02mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Sep 2009 13:11:22.0319 (UTC) FILETIME=[5BD4E5F0:01CA32E1] X-Nokia-AV: Clean Subject: Re: [dispatch] New topic proposal for DISPATCH 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: Fri, 11 Sep 2009 13:11:40 -0000 --_000_B3F72E5548B10A4A8E6F4795430F8418125E6740DFNOKEUMSG02mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Henry, Thanks for your feedback :) Let me answer to the excellent points you raise= . First of all, I would encourage you and everyone to carefully read the Intr= oduction chapter of the draft (http://tools.ietf.org/html/draft-veikkolaine= n-sip-voip-xmpp-im-01) to be clear on what the proposal is about. That is, = we are not trying to boil the ocean and define all possible ways how SIP an= d XMPP infrastructures could be combined, but instead try to define a minim= alistic approach whereby a client can use both SIP and XMPP in an integrate= d manner WITHOUT requiring ANY changes on the servers that are already depl= oyed. See further comments below with [Markus]: ________________________________ From: ext Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 04 September, 2009 18:42 To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; mary.barnes@no= rtel.com; gonzalo.camarillo@ericsson.com Cc: Isomaki Markus (Nokia-CIC/Espoo); Olle E. Johansson Subject: Re: [dispatch] New topic proposal for DISPATCH I would like to second such work, but a far deeper look under the hood is n= ecessary, so we don't do another Elbonia project. http://dilbert.com/strips/comic/2009-09-01/ Here are some not very mature thoughts on the scope of the work. The most interesting, ROI estimate and REST architecture support are at the= end. Servers Fundamentally, we need a registrar, a proxy and a presence server: Three in= total * What will be the duplication of servers and where specifically? * How does the SIP registrar communicate with the XMPP server(s)? * What may be the routing protocol(s) inside a SIP+XMMP network? Think o= f IMS as a stressing use case. [Markus] Our starting point is that we already have quite many SIP VoIP dep= loyments out there, as long as quite many XMPP presence & IM deployments. S= o, the servers you mention already exist. If one now wants to develop a cli= ent that does VoIP, IM and presence together, it should be possible to util= ize these existing infrastrcutures and not have to wait for new ones to be = deployed (as for instance we have waited quite many years for SIMPLE-based = Presence servers to get deployed but compared to XMPP there's very little i= n use). The idea is to define a couple of E2E (as in nothing that SIP proxi= es or XMPP servers would have to support) protocol extensions which would a= llow the client to nicely combine SIP VoIP and XMPP presence & IM. There is no need for SIP and XMPP servers to know about each other or route= protocol messages between each other. All the logic is put into the endpoi= nts. No need to worry about IMS either, except that in theory the client ca= n use IMS for its VoIP service (similar to any other SIP infra). User Agents * Same as with servers: How many and what protocol RFCs are there in the= combination? * Which of the "services" can be placed in the applications in the endpo= ints or in the network application protocols, such as SIP and XMPP. This is= the topic on infrastructure vs. endpoint applications. [Markus] Just take any current SIP VoIP UA implementation, XMPP client impl= ementation and glue them together and you're already pretty far. Add a coup= le of extensions as proposed and it's done. From there onwards you have a p= retty powerful machinery to add applications by using SIP session setup and= XMPP message delivery capabilities. Application Protocol Stacks * How many protocol stacks does this involve and more to the point, how = many RFCs? * For SIP alone, see http://rfc3261.net/. What will be the total combine= d RFC count? [Markus] All what we expect is already pretty widely supported and even ava= ilable as open source: basic SIP VoIP and XMPP IM and presence is enough to= start with. NAT Traversal * Will STUN/TURN/ICE work the same for SIP and for XMPP? [Markus] In our proposal SIP would be used for setting up voice & video se= ssions. So, you would need NAT traversal for that. How that's done is outsi= de the scope but either B2BUA or ICE based mechanisms would work as far as = they work in general. For XMPP we would not need to worry about NAT travers= al beyond how its done in that protocol by default. For a client there is a= caveat that it has to keepalive the TCP connections with BOTH SIP and XMPP= servers so it would be recommended to synchronize those (send them at the = same time) for instance in a battery powered device. Return on Investment (ROI): Cost and effort by developers. More network inf= rastructure, not even counting B2B NEs. * What is the additional time/money required for developers that know SI= P to also learn XMPP and vice versa? This is all about return on investment= . [Markus] This is a problem for sure, even more so for the people writing st= andard specs than code :) Hopefully the developer would just have add a co= uple of simple extensions to existing SIP and XMPP implementations. Support for a REST-full architecture The WWW has a REST architecture was formulated in 2000, after the emergence= of SIP and XMMP. As a result of its architecture, the WWW has had a trans= formational effect on the following (this is not a complete list). Some SIP= work recommends already recommends REST, such as in RFC 4240 and in http:/= /tools.ietf.org/html/draft-griffin-bliss-rest-00 * Web applications from mail to office apps * Internet applications previously served by dedicated network applicati= ons protocols * Many other industries, from banking to newsprint to travel. And Oh, so= cial networks, they also have registrars... Now please keep in mind the WWW architecture uses basically only 3 componen= ts*: The URI for addressing, HTTP for transport and HTML for data rendering= , augmented by some other languages (XML) and namespaces. Can we benefit so= mething from the WWW architecture? If yes what specifically? Heresy: If the web developers could use HTTP only, what other application l= evel protocols do we really need except RTP/UDP? This includes in my mind TLS and DTLS for secure transport or even better I= MO: HIP for many reasons. [Markus] Personally I agree that REST+HTTP+Javascript is a superior toolset= compared to SIP, XMPP, IMAP and so on to develop many applications. Howeve= r, there are still plenty of SIP based VoIP and XMPP based IM and presence = deployments out there and I don't expect the web apps to replace all of the= m in the near future :) * T.V. Raman: "Toward 2W, Beyond Web 2.0", Communications of the ACM, Febru= ary 2009 Many or most of these points may be moot or make no sense, but maybe should= be cleared up, in case there are more naive people like me that may be int= erested. My strict personal 2 cents. FRANK comments are most welcome. Henry On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" wrote: Hi, We would like to propose a new DISPATCH topic on how SIP and XMPP can be us= ed together in a complementary fashion. We have been working on a solution which combines SIP based VoIP and XMPP b= ased IM and Presence. The requirements and a proposed solution is outlined = in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 . The motivation for this work comes from experience which shows that most st= andards based VoIP deployments use SIP. At the same time, the Extensible Me= ssaging and Presence Protocol (XMPP) is widely used in instant messaging an= d presence services. An interesting scenario arises when a SIP based voice = (and video) service is combined together with an XMPP based instant messagi= ng and presence service. Note that the goal in this work is not SIP-XMPP protocol translation, but t= o define protocol extensions and best practises such that SIP based VoIP an= d XMPP based IM and presence could be seamlessly combined and offered to th= e end user. For rapid deployment, we assume no changes in the server infras= tructure, and instead impose new requirements and protocol extensions only = to the endpoints. We would like to get some discussion going on the use case itself as well a= s on the solution. Also, we would like to hear you thoughts on DISPATCH or = a new "dispatched" mini-WG as the home for such work. Exact charter proposal and problem statemen is to follow. Regards, Simo and Markus --_000_B3F72E5548B10A4A8E6F4795430F8418125E6740DFNOKEUMSG02mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] New topic proposal for DISPATCH
Hi Henry,
 
Thanks for your feedback :) Let me answer to the e= xcellent=20 points you raise.
 
First of all, I would encourage you and ever= yone to=20 carefully read the Introduction chapter of the draft (= http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01<= /FONT>) to be clear on what the proposal is about. That is, we are not t= rying=20 to boil the ocean and define all possible ways how SIP and XMPP infrastruct= ures=20 could be combined, but instead try to define a minimalistic approach whereb= y a=20 client can use both SIP and XMPP in an integrated manner WITHOUT requiring = ANY=20 changes on the servers that are already deployed.
 
See further comments below with=20 [Markus]:

From: ext Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: 04 September, 2009=20 18:42
To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.o= rg;=20 mary.barnes@nortel.com; gonzalo.camarillo@ericsson.com
Cc: Isom= aki=20 Markus (Nokia-CIC/Espoo); Olle E. Johansson
Subject: Re: [dispa= tch]=20 New topic proposal for DISPATCH

I would like to second such work, but a far dee= per=20 look under the hood is necessary, so we don’t do another Elbonia=20 project.
http://dilbert.com/s= trips/comic/2009-09-01/

Here=20 are some not very mature thoughts on the scope of the work.
The most= =20 interesting, ROI estimate and REST architecture support are at the=20 end.

Servers

Fundamentally, we need a registrar, a proxy an= d a=20 presence server: Three in total
  • What will be the duplication of servers and w= here=20 specifically?
  • How does the SIP registrar communicate with t= he XMPP=20 server(s)?
  • What may be the routing protocol(s) inside a= =20 SIP+XMMP network? Think of IMS as a stressing use=20 case.
[Markus] Our starting point is that we already h= ave quite=20 many SIP VoIP deployments out there, as long as quite many XMPP presence = &=20 IM deployments. So, the servers you mention already exist. If one no= w=20 wants to develop a client that does VoIP, IM and presence together, it sh= ould=20 be possible to utilize these existing infrastrcutures and not have to wai= t for=20 new ones to be deployed (as for instance we have waited quite many years = for=20 SIMPLE-based Presence servers to get deployed but compared to XMPP there'= s=20 very little in use). The idea is to define a couple of E2E (as = in=20 nothing that SIP proxies or XMPP servers would have to support) protocol= =20 extensions which would allow the client to nicely combine SIP VoIP and XM= PP=20 presence & IM. 
 
There is no need for SIP and XMPP servers to kno= w about=20 each other or route protocol messages between each other. All the logic i= s put=20 into the endpoints. No need to worry about IMS either, except=20 that in theory the client can use IMS for its VoIP service= =20 (similar to any other SIP=20 infra). 
 <= BR>User=20 Agents
  • Same as with servers: How many and what proto= col=20 RFCs are there in the combination?
  • Which of the “services” can be pl= aced in the=20 applications in the endpoints or in the network application protocols, = such=20 as SIP and XMPP. This is the topic on infrastructure vs. endpoint=20 applications.
[Markus] Just take any current SIP VoIP=20 UA implementation, XMPP client implementation and glue them tog= ether=20 and you're already pretty far. Add a couple of extensions as proposed and= it's=20 done. From there onwards you have a pretty powerful machinery to add=20 applications by using SIP session setup and XMPP message delivery=20 capabilities.
 
Application Protocol=20 Stacks
  • How many protocol stacks does this involve an= d more=20 to the point, how many RFCs?
  • For SIP alone, see http://rfc3261.net/. What will be the = total=20 combined RFC count?
[Markus] All what we expect is already pret= ty widely=20 supported and even available as open source: basic SIP VoIP and XMPP IM a= nd=20 presence is enough to start with.=20  
 <= BR>NAT=20 Traversal
  • Will STUN/TURN/ICE work the same for SIP and = for=20 XMPP?
 [Markus] In our proposal SIP would be used for s= etting up=20 voice & video sessions. So, you would need NAT traversal for that. Ho= w=20 that's done is outside the scope but either B2BUA or ICE based mechanisms= =20 would work as far as they work in general. For XMPP we would not need to = worry=20 about NAT traversal beyond how its done in that protocol by default. For = a=20 client there is a caveat that it has to keepalive the TCP connections wit= h=20 BOTH SIP and XMPP servers so it would be recommended to synchronize those= =20 (send them at the same time) for instance in a battery powered=20 device.
 <= BR>Return=20 on Investment (ROI): Cost and effort by developers. More network=20 infrastructure, not even counting B2B NEs.
  • What is the additional time/money required fo= r=20 developers that know SIP to also learn XMPP and vice versa? This is all= =20 about return on investment.
[Markus] This is a problem for sure, even m= ore so=20 for the people writing standard specs than code :)  Hopefully the=20 developer would just have add a couple of simple extensions to exist= ing=20 SIP and XMPP implementations. 
 
Support for a REST-full=20 architecture

The WWW has a REST architecture was formulated in 200= 0,=20 after the emergence of SIP and XMMP.  As a result of its architectur= e,=20 the WWW has had a transformational effect on the following (this is not a= =20 complete list). Some SIP work recommends already recommends REST, such as= in=20 RFC 4240 and in http://to= ols.ietf.org/html/draft-griffin-bliss-rest-00
  • Web applications from mail to office apps=20
  • Internet applications previously served by de= dicated=20 network applications protocols
  • Many other industries, from banking to newspr= int to=20 travel. And Oh, social networks, they also have=20 registrars...

Now please keep in mind the WWW architecture uses bas= ically=20 only 3 components*: The URI for addressing, HTTP for transport and HTML f= or=20 data rendering, augmented by some other languages (XML) and namespaces. C= an we=20 benefit something from the WWW architecture? If yes what=20 specifically?

Heresy: If the web developers could use HTTP only, w= hat=20 other application level protocols do we really need except RTP/UDP?
Th= is=20 includes in my mind TLS and DTLS for secure transport or even better IMO:= HIP=20 for many reasons.
 
[Markus] Personally I agree that REST+HTTP+Javascript is a super= ior=20 toolset compared to SIP, XMPP, IMAP and so on to develop many application= s.=20 However, there are still plenty of SIP based VoIP and XMPP based IM and=20 presence deployments out there and I don't expect the web apps to replace= all=20 of them in the near future :)
 
* T.V. Raman: R= 20;Toward 2W,=20 Beyond Web 2.0”, Communications of the ACM, February 2009

Ma= ny or most=20 of these points may be moot or make no sense, but maybe should be cleared= up,=20 in case there are more naive people like me that may be interested.
My=20 strict personal 2 cents.

FRANK comments are most=20 welcome.

Henry



On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" <= ;Simo.Veikkolainen@nokia.com>= =20 wrote:

Hi,
 
We would like to propose a new DISPATCH t= opic on=20 how SIP and XMPP can be used together in a complementary=20 fashion.
 
We have been working on a solution which combines= SIP=20 based VoIP and XMPP based IM and Presence. The requirements and a propo= sed=20 solution is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01=20 <http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01&g= t;=20 .
 
The motivation for this work comes from experience which= =20 shows that most standards based VoIP deployments use SIP. At the same t= ime,=20 the Extensible Messaging and Presence Protocol (XMPP) is widely used in= =20 instant messaging and presence services. An interesting scenario arises= when=20 a SIP based voice (and video) service is combined together with an XMPP= =20 based instant messaging and presence service.
 
Note that t= he=20 goal in this work is not SIP-XMPP protocol translation, but to define=20 protocol extensions and best practises such that SIP based VoIP and XMP= P=20 based IM and presence could be seamlessly combined and offered to the e= nd=20 user. For rapid deployment, we assume no changes in the server=20 infrastructure, and instead impose new requirements and protocol extens= ions=20 only to the endpoints.
 
We would like to get some discussio= n=20 going on the use case itself as well as on the solution. Also, we would= like=20 to hear you thoughts on DISPATCH or a new "dispatched" mini-WG as the h= ome=20 for such work.
 
Exact charter proposal and problem statemen= is=20 to follow.
 
Regards,
Simo and=20 Markus
 
 

--_000_B3F72E5548B10A4A8E6F4795430F8418125E6740DFNOKEUMSG02mgd_-- From alan@sipstation.com Fri Sep 11 07:19:37 2009 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 EA95428C132 for ; Fri, 11 Sep 2009 07:19:37 -0700 (PDT) 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 E7lsVc3AkHXl for ; Fri, 11 Sep 2009 07:19:37 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id EAC0228C133 for ; Fri, 11 Sep 2009 07:19:36 -0700 (PDT) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mm6yy-000Enc-2R; Fri, 11 Sep 2009 14:20:12 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+g3ZkRZSu/sVhJEI6+N/T1uCf+JZA1dfs= Message-ID: <4AAA5C98.1080502@sipstation.com> Date: Fri, 11 Sep 2009 09:20:08 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dean Willis References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> In-Reply-To: <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, 'Gonzalo Camarillo' , 'Hadriel Kaplan' Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic Domain Registration 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: Fri, 11 Sep 2009 14:19:38 -0000 Dean, The plan is not to rewrite the Internet's name architecture nor replace RFC 3263. The plan is to standardize a function that has been shown to be needed in the marketplace for the deployment of SIP in certain applications. And yes, dynamic DNS is an alternative, it does work, but again, there are reasons why it is not being used in this certain application. Anyway, lets start this conversation properly when we have a draft. Thanks, Alan Dean Willis wrote: > > On Sep 4, 2009, at 2:53 PM, Richard Shockey wrote: > >> Dispatch Chairs: We would like to reserve some time during DISPATCH to >> discuss the topic of domain registration in SIP. > > It seems like you're proposing a deep and fundamental rewrite of the > Internet's name architecture, replacing RFC 3263 and its use of DNS > with some sort of SIP REGISTER technique. > > Or maybe I'm missing it entirely, and what you're proposing is a way > to use SIP REGISTER messages to populate a DNS SRV record within a > registry? > > This raises the question of delegation to that registry -- the > registry has to be authoritative for all of example.com in order to > be able to host an srv record for example.com. So your mythical SMB is > still going to require a DNS service provider that has to be > meaningfully provisioned. It's just a question of the outsourcing > contract, and I fail to see a need for protocol work here. After all, > we have dynamic DNS, and it works pretty darned well for me today. > > So what you talking 'bout, Shockey? > > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jbakker@rim.com Fri Sep 11 08:38:31 2009 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 CADBA3A6876 for ; Fri, 11 Sep 2009 08:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 jbl7wLYXxkCT for ; Fri, 11 Sep 2009 08:38:24 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 5456E3A694C for ; Fri, 11 Sep 2009 08:38:24 -0700 (PDT) X-AuditID: 0a666446-b7b3fae000004aa1-cb-4aaa6f13b572 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 0C.19.19105.31F6AAA4; Fri, 11 Sep 2009 11:38:59 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 11:38:58 -0400 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_01CA32F5.DCDE9A8D" Date: Fri, 11 Sep 2009 10:38:07 -0500 Message-ID: In-Reply-To: <0E48B768805E4D44A70709C8AE09209003AFC6A4@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New versionof"draft-avasasarala-dispatch-comm-diversion-info" draft submitted thread-index: AcoPSGlfXjMN39SUTDiDCIozl/Ik3gPv+k6AACM0FAAE2CpPUA== References: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> <0E48B768805E4D44A70709C8AE09209003AFC6A4@EMAILEMEA3.jnpr.net> From: "John-Luc Bakker" To: "Gilad Shaham" , "Avasarala Ranjit-A20990" , X-OriginalArrivalTime: 11 Sep 2009 15:38:58.0853 (UTC) FILETIME=[FABCBD50:01CA32F5] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [dispatch] [Sip] New versionof"draft-avasasarala-dispatch-comm-diversion-info" draft submitted 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: Fri, 11 Sep 2009 15:38:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA32F5.DCDE9A8D Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi Gilad, Regarding: > Page 21: > 503 is there, but I don't see 500. Some implementations will avoid 503 and use 500 due to > discussion related to this http://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now expired, > but still affected some vendor decisions). I might be able to think of some scenario that > involves 502, but I assume this is a result of the diversion implementation itself so maybe > that's the context of this discussion. The referenced expired draft mentions overload situations. 503 (Service Unavailable) response code is provided as a remedy for servers under Overload, the draft says. The 503 code in this document is to be interpreted as "subscriber not reachable" (e.g. see RFC 4458). Moreover, sending a NOTIFY with an XML document indicating a diversion (re-directions or forwarding) of an incoming communication session request due to a server in a overload situation, may even amplify the overload condition. Regards, John-Luc ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Gilad Shaham Sent: Monday, August 17, 2009 7:20 PM To: Avasarala Ranjit-A20990; dispatch@ietf.org; sip@ietf.org Subject: Re: [Sip] New versionof"draft-avasasarala-dispatch-comm-diversion-info" draft submitted Hi, See some comments Page 5: "... For e.g. the subscriber wanted to diverted all incoming calls to voice-mail, between 3.00 p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration as 3.00 to 4.00 p.m" Some of the sentence needs restructuring and I also don't fully understand the example. Is it AM-PM or wrong field was configured? Page 12: What if time-range is missing? What should be the default? Sounds to me the default should be the current time with no end date. Page 14: In Comm-div-info-selection-criteria there are several disable-* subsections, yet their text describes these element gives the subscriber option of adding information. Shouldn't this be for omitting information or alternatively, call these elements "enable-*" or did I misunderstand the purpose. Page 16: Boss Should be Boss It might be also useful to see an example of periodic request. Page 21: 503 is there, but I don't see 500. Some implementations will avoid 503 and use 500 due to discussion related to this http://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now expired, but still affected some vendor decisions). I might be able to think of some scenario that involves 502, but I assume this is a result of the diversion implementation itself so maybe that's the context of this discussion. Thanks Gilad ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Monday, August 17, 2009 10:07 AM To: dispatch@ietf.org; sip@ietf.org Subject: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted Hi All We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-no tification-01.txt This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604. Please review and comment Regards Ranjit ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CA32F5.DCDE9A8D Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted</= title> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} pre {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.EmailStyle19 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dblue> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Hi Gilad,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Regarding:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>> Page 21:<o:p></o:p></span></font><= /p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>> 503 is there, but I don’t se= e 500. Some implementations will avoid 503 and use 500 due to <o:p></o:p></spa= n></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>> discussion related to this <a href=3D"http://tools.ietf.org/html/draft-hilt-sip-correction-503-01" title=3D"blocked::http://tools.ietf.org/html/draft-hilt-sip-correction-503-0= 1">http://tools.ietf.org/html/draft-hilt-sip-correction-503-01</a> (now expired,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>>  but still affected some vend= or decisions). I might be able to think of some scenario that <o:p></o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>> involves 502, but I assume this is= a result of the diversion implementation itself so maybe <o:p></o:p></span></f= ont></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>> that’s the context of this discussion.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>The referenced expired draft mentions overload situations. 503<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>(Service Unavailable) response code is provided as a remedy for servers under<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Overload, the draft says.  <o:p></= o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>The 503 code in this document is to be= interpreted as “subscriber not reachable” (e.g. see RFC 4458).<o:p></o:p></s= pan></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Moreover, sending a NOTIFY with an XML document indicating a diversion (re-directions or forwarding) <o:p></o:p></s= pan></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>of an incoming communication session re= quest due to a server in a overload situation, may even amplify <o:p></o:p></span>= </font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>the overload condition.<o:p></o:p></spa= n></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>      &nb= sp;     John-Luc<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font size= =3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-siz= e:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] <b><span style=3D'font-we= ight: bold'>On Behalf Of </span></b>Gilad Shaham<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, August 17, 2009= 7:20 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Avasarala Ranjit-A20990; dispatch@ietf.org; sip@ietf.org<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Sip] New versionof"draft-avasasarala-dispatch-comm-diversion-info" draft submitted</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D'= font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>See some comments<o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Page 5:<o:p></o:p></span></font></p> <pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&n= bsp;  “... For e.g. the subscriber wanted to diverted all incomin= g calls to voice-mail,<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>  = between 3.00 p.m. to 4.00 p.m.  Yet, by mistake she configures the<o:p= ></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>  = time-duration as 3.00 to 4.00 p.m”<o:p></o:p></span></font></pre> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Some of the sentence needs restructurin= g and I also don’t fully understand the example. Is it AM-PM or wrong fi= eld was configured?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Page 12:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>What if time-range is missing? What sho= uld be the default? Sounds to me the default should be the current time with no= end date.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Page 14:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>In Comm-div-info-selection-criteria the= re are several disable-* subsections, yet their text describes these element gi= ves the subscriber option of adding information. Shouldn’t this be for omitting information or alternatively, call these elements “enable-*” or did I misunderstand the purpose.<o:p></o:p></span>= </font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Page 16:<o:p></o:p></span></font></p> <pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&n= bsp;            <u= ser-name>Boss</originating-user-name><o:p></o:p></span></font></pre= > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Should be<o:p></o:p></span></font></p> <pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&n= bsp;            <u= ser-name>Boss</user-name><o:p></o:p></span></font></pre> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>It might be also useful to see an examp= le of periodic request.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Page 21:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>503 is there, but I don’t see 500= . Some implementations will avoid 503 and use 500 due to discussion related to this <a href=3D"http://tools.ietf.org/html/draft-hilt-sip-correction-503-01"= >http://tools.ietf.org/html/draft-hilt-sip-correction-503-01</a> (now expired, but still affected some vendor decisions). I might be able to think of some scenario that involves 502, but I assume this is a result of t= he diversion implementation itself so maybe that’s the context of this discussion.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'>Gilad<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font size= =3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-siz= e:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> sip-bounc= es@ietf.org [mailto:sip-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behalf= Of </span></b>Avasarala Ranjit-A20990<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, August 17, 2009 10:07 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> dispatch@ietf.org; sip@ietf.org<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted= </span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D'= font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=3D= 'font-size: 10.0pt;font-family:Arial;color:blue'>Hi All</span></font> <o:p></o:p></p> <p><font size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;= font-family: Arial;color:blue'>We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info </span></font><o:p></o:p></p> <p><font size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;= font-family: Arial;color:blue'>It can be accessed at: </span></font><font size=3D2 face= =3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-di= v-notification-01.txt" target=3D"_top" jQuery1250492662043=3D3><font size=3D3 face=3D"Times New Rom= an"><span style=3D'font-size:12.0pt;font-family:"Times New Roman"'>http://www.ietf.org= /internet-drafts/draft-avasarala-dispatch-comm-div-notification-01.txt</span= ></font></a></span></font><o:p></o:p></p> <p><font size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;= font-family: Arial;color:blue'>This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604. </span></font><o:p></o:p></p> <p><font size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;= font-family: Arial;color:blue'>Please review and comment</span></font><o:p></o:p></p> <p><font size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;= font-family: Arial;color:blue'>Regards</span></font> <br> <font size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;fon= t-family: Arial;color:blue'>Ranjit</span></font> <o:p></o:p></p> </div> --------------------------------------------------------------------- <br>= =0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. </body> </html> ------_=_NextPart_001_01CA32F5.DCDE9A8D-- From hsinnrei@adobe.com Fri Sep 11 10:41:16 2009 Return-Path: <hsinnrei@adobe.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 77B793A69F7 for <dispatch@core3.amsl.com>; Fri, 11 Sep 2009 10:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.825 X-Spam-Level: X-Spam-Status: No, score=-4.825 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 taa3p3tl4suv for <dispatch@core3.amsl.com>; Fri, 11 Sep 2009 10:41:02 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id 58CA728C188 for <dispatch@ietf.org>; Fri, 11 Sep 2009 10:40:35 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSqqLtfQyShLb76k1OjrWgz77wr4gRE7m@postini.com; Fri, 11 Sep 2009 10:41:39 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8BHYIao006435; Fri, 11 Sep 2009 10:34:18 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8BHf7iq001875; Fri, 11 Sep 2009 10:41:07 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Fri, 11 Sep 2009 10:41:07 -0700 From: Henry Sinnreich <hsinnrei@adobe.com> To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "dispatch@ietf.org" <dispatch@ietf.org>, "mary.barnes@nortel.com" <mary.barnes@nortel.com>, "gonzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com> Date: Fri, 11 Sep 2009 10:41:02 -0700 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgAHb1p/AVb60MAADTfzjQ== Message-ID: <C6CFF5DE.5C9E%hsinnrei@adobe.com> In-Reply-To: <B3F72E5548B10A4A8E6F4795430F8418125E6740DF@NOK-EUMSG-02.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6CFF5DE5C9Ehsinnreiadobecom_" MIME-Version: 1.0 Cc: "avshalom@il.ibm.com" <avshalom@il.ibm.com> Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 11 Sep 2009 17:41:16 -0000 --_000_C6CFF5DE5C9Ehsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Markus, Thanks for your thoughtful reply and I agree there are some scenarios where= it makes sense. More important, doing this in the endpoints is the right approach IMO and a= s you know, I will always defend the Internet end-to-end principle :-) This distributed approach is also IMO a good answer to the Interdomain Scal= ing problem for IM ( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I have copied one= of its authors here. This raises the questions: 1. Why stop at SIP and XMPP, and not add other popular IM protocols, as i= s already done by quite a few products in the market? 2. Can your approach be generalized in a more generic way? If endpoints are accommodating several IM protocols, an IETF, Dispatch reco= mmended GENERIC approach would make many people feel more comfortable about= it. Your I-D could be used as a tested example for a generic approach. Ranting on preferring endpoint applications to more application protocols I still believe creative application developers face the choice of either i= nventing new applications or dedicating their time to learning application = protocols and they cannot do both. Learning and following both SIP and XMPP= to write and update code is quite a challenge. Is there a better way? For this reason, one single application protocol for IM and voice is enough= . Proof: Almost all the applications that make people buy smart phones, use o= nline office apps and enterprise apps run on HTTP(S) and their application = developers don't have to worry about knowing how HTTP works. As a result, H= TTP has been also used to even carry streaming media, web conferencing and = IM. Just to avoid spending a lifetime to learn and follow application proto= cols. But HTTP based apps dominate the application space. This is however f= or another discussion elsewhere. My strictly personal 2 cents. Thanks again, Henry On 9/11/09 8:11 AM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> w= rote: Hi Henry, Thanks for your feedback :) Let me answer to the excellent points you raise= . First of all, I would encourage you and everyone to carefully read the Intr= oduction chapter of the draft (http://tools.ietf.org/html/draft-veikkolaine= n-sip-voip-xmpp-im-01 <http://tools.ietf.org/html/draft-veikkolainen-sip-vo= ip-xmpp-im-01> ) to be clear on what the proposal is about. That is, we are= not trying to boil the ocean and define all possible ways how SIP and XMPP= infrastructures could be combined, but instead try to define a minimalisti= c approach whereby a client can use both SIP and XMPP in an integrated mann= er WITHOUT requiring ANY changes on the servers that are already deployed. See further comments below with [Markus]: ________________________________ From: ext Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 04 September, 2009 18:42 To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; mary.barnes@n= ortel.com; gonzalo.camarillo@ericsson.com Cc: Isomaki Markus (Nokia-CIC/Espoo); Olle E. Johansson Subject: Re: [dispatch] New topic proposal for DISPATCH I would like to second such work, but a far deeper look under the hood is = necessary, so we don't do another Elbonia project. http://dilbert.com/strips/comic/2009-09-01/ Here are some not very mature thoughts on the scope of the work. The most interesting, ROI estimate and REST architecture support are at th= e end. Servers Fundamentally, we need a registrar, a proxy and a presence server: Three i= n total * What will be the duplication of servers and where specifically? * How does the SIP registrar communicate with the XMPP server(s)? * What may be the routing protocol(s) inside a SIP+XMMP network? Think = of IMS as a stressing use case. [Markus] Our starting point is that we already have quite many SIP VoIP de= ployments out there, as long as quite many XMPP presence & IM deployments.= So, the servers you mention already exist. If one now wants to develop a = client that does VoIP, IM and presence together, it should be possible to = utilize these existing infrastrcutures and not have to wait for new ones t= o be deployed (as for instance we have waited quite many years for SIMPLE-= based Presence servers to get deployed but compared to XMPP there's very l= ittle in use). The idea is to define a couple of E2E (as in nothing that S= IP proxies or XMPP servers would have to support) protocol extensions whic= h would allow the client to nicely combine SIP VoIP and XMPP presence & IM= . There is no need for SIP and XMPP servers to know about each other or rout= e protocol messages between each other. All the logic is put into the endp= oints. No need to worry about IMS either, except that in theory the client= can use IMS for its VoIP service (similar to any other SIP infra). User Agents * Same as with servers: How many and what protocol RFCs are there in th= e combination? * Which of the "services" can be placed in the applications in the endp= oints or in the network application protocols, such as SIP and XMPP. This = is the topic on infrastructure vs. endpoint applications. [Markus] Just take any current SIP VoIP UA implementation, XMPP client imp= lementation and glue them together and you're already pretty far. Add a co= uple of extensions as proposed and it's done. From there onwards you have = a pretty powerful machinery to add applications by using SIP session setup= and XMPP message delivery capabilities. Application Protocol Stacks * How many protocol stacks does this involve and more to the point, how= many RFCs? * For SIP alone, see http://rfc3261.net/. What will be the total combin= ed RFC count? [Markus] All what we expect is already pretty widely supported and even av= ailable as open source: basic SIP VoIP and XMPP IM and presence is enough = to start with. NAT Traversal * Will STUN/TURN/ICE work the same for SIP and for XMPP? [Markus] In our proposal SIP would be used for setting up voice & video se= ssions. So, you would need NAT traversal for that. How that's done is outs= ide the scope but either B2BUA or ICE based mechanisms would work as far a= s they work in general. For XMPP we would not need to worry about NAT trav= ersal beyond how its done in that protocol by default. For a client there = is a caveat that it has to keepalive the TCP connections with BOTH SIP and= XMPP servers so it would be recommended to synchronize those (send them a= t the same time) for instance in a battery powered device. Return on Investment (ROI): Cost and effort by developers. More network i= nfrastructure, not even counting B2B NEs. * What is the additional time/money required for developers that know S= IP to also learn XMPP and vice versa? This is all about return on investme= nt. [Markus] This is a problem for sure, even more so for the people writing s= tandard specs than code :) Hopefully the developer would just have add a = couple of simple extensions to existing SIP and XMPP implementations. Support for a REST-full architecture The WWW has a REST architecture was formulated in 2000, after the emergenc= e of SIP and XMMP. As a result of its architecture, the WWW has had a tra= nsformational effect on the following (this is not a complete list). Some = SIP work recommends already recommends REST, such as in RFC 4240 and in ht= tp://tools.ietf.org/html/draft-griffin-bliss-rest-00 * Web applications from mail to office apps * Internet applications previously served by dedicated network applicat= ions protocols * Many other industries, from banking to newsprint to travel. And Oh, s= ocial networks, they also have registrars... Now please keep in mind the WWW architecture uses basically only 3 compone= nts*: The URI for addressing, HTTP for transport and HTML for data renderi= ng, augmented by some other languages (XML) and namespaces. Can we benefit= something from the WWW architecture? If yes what specifically? Heresy: If the web developers could use HTTP only, what other application = level protocols do we really need except RTP/UDP? This includes in my mind TLS and DTLS for secure transport or even better = IMO: HIP for many reasons. [Markus] Personally I agree that REST+HTTP+Javascript is a superior toolse= t compared to SIP, XMPP, IMAP and so on to develop many applications. Howe= ver, there are still plenty of SIP based VoIP and XMPP based IM and presen= ce deployments out there and I don't expect the web apps to replace all of= them in the near future :) * T.V. Raman: "Toward 2W, Beyond Web 2.0", Communications of the ACM, Febr= uary 2009 Many or most of these points may be moot or make no sense, but maybe shoul= d be cleared up, in case there are more naive people like me that may be i= nterested. My strict personal 2 cents. FRANK comments are most welcome. Henry On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.c= om> wrote: Hi, We would like to propose a new DISPATCH topic on how SIP and XMPP can be u= sed together in a complementary fashion. We have been working on a solution which combines SIP based VoIP and XMPP = based IM and Presence. The requirements and a proposed solution is outline= d in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 <ht= tp://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> . The motivation for this work comes from experience which shows that most s= tandards based VoIP deployments use SIP. At the same time, the Extensible = Messaging and Presence Protocol (XMPP) is widely used in instant messaging= and presence services. An interesting scenario arises when a SIP based vo= ice (and video) service is combined together with an XMPP based instant me= ssaging and presence service. Note that the goal in this work is not SIP-XMPP protocol translation, but = to define protocol extensions and best practises such that SIP based VoIP = and XMPP based IM and presence could be seamlessly combined and offered to= the end user. For rapid deployment, we assume no changes in the server i= nfrastructure, and instead impose new requirements and protocol extensions = only to the endpoints. We would like to get some discussion going on the use case itself as well = as on the solution. Also, we would like to hear you thoughts on DISPATCH o= r a new "dispatched" mini-WG as the home for such work. Exact charter proposal and problem statemen is to follow. Regards, Simo and Markus --_000_C6CFF5DE5C9Ehsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [dispatch] New topic proposal for DISPATCH Hi Markus,

Thanks for your thoughtful reply and I agree there are some scenarios where= it makes sense.
More important, doing this in the endpoints is the right approach IMO and a= s you know, I will always defend the Internet end-to-end principle :-)

This distributed approach is also IMO a good answer to the Interdomain Scal= ing problem for IM
( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I have copied one= of its authors here.

This raises the questions:

  1. Why stop at SIP and XMPP, and not add other pop= ular IM protocols, as is already done by quite a few products in the market= ?
  2. Can your approach be generalized in a more generic = way?

If endpoints are accommodating several IM protocols, an IETF, Dispatch reco= mmended GENERIC approach would make many people feel more comfortable about= it. Your I-D could be used as a tested example for a generic approach.

Ranting on preferring endpoint applications to more application protocols
I still believe creative application developers face the choice of either i= nventing new applications or dedicating their time to learning application = protocols and they cannot do both. Learning and following both SIP and XMPP= to write and update code is quite a challenge.
Is there a better way?
For this reason, one single application protocol for IM and voice is enough= .
Proof: Almost all the applications that make people buy smart phones, use o= nline office apps and enterprise apps run on HTTP(S) and their application = developers don’t have to worry about knowing how HTTP works. As a res= ult, HTTP has been also used to even carry streaming media, web conferencin= g and IM. Just to avoid spending a lifetime to learn and follow application= protocols. But HTTP based apps dominate the application space. This is how= ever for another discussion elsewhere.

My strictly personal 2 cents.

Thanks again,

Henry


On 9/11/09 8:11 AM, "Markus.Isoma= ki@nokia.com" <Markus.Isom= aki@nokia.com> wrote:

Hi Henry,
Thanks for your feedbac= k :) Let me answer to the excellent points you raise.
First of all, I would e= ncourage you and everyone to carefully read the Introduction chapter of the= draft (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-0= 1 <http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im= -01> ) to be clear on what the proposal is about. That is, we are no= t trying to boil the ocean and define all possible ways how SIP and XMPP in= frastructures could be combined, but instead try to define a minimalistic a= pproach whereby a client can use both SIP and XMPP in an integrated manner = WITHOUT requiring ANY changes on the servers that are already deployed.
See further comments be= low with [Markus]:


 
From: ext Henry Sinnreich  [mailto:hsinnrei@adobe.com]
Sent: 04 September, 2009  18:42
To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org;  mary.ba= rnes@nortel.com; gonzalo.cam= arillo@ericsson.com
Cc: Isomaki  Markus (Nokia-CIC/Espoo); Olle E. Johansson
Subject: Re: [dispatch]  New topic proposal for DISPATCH

 
I would like to second such work, but= a far deeper  look under the hood is necessary, so we don’t do = another Elbonia  project.
http://dilbert.com/= strips/comic/2009-09-01/

Here  are some not very mature thoughts on the scope of the work.
The most  interesting, ROI estimate and REST architecture support are = at the  end.

Servers

Fundamentally, we need a registrar, a proxy and a  presence server: Th= ree in total
  • What will be the duplication o= f servers and where  specifically? =20
  • How does the SIP registrar communi= cate with the XMPP  server(s)? =20
  • What may be the routing protocol(s= ) inside a  SIP+XMMP network? Think of IMS as a stressing use  ca= se.

[Markus] Our starting point is that we already have quite &n= bsp;many SIP VoIP deployments out there, as long as quite many XMPP presenc= e &  IM deployments. So, the servers you mention already exist. If= one now  wants to develop a client that does VoIP, IM and presence to= gether, it should  be possible to utilize these existing infrastrcutur= es and not have to wait for  new ones to be deployed (as for instance = we have waited quite many years for  SIMPLE-based Presence servers to = get deployed but compared to XMPP there's  very little in use). The id= ea is to define a couple of E2E (as in  nothing that SIP proxies or XM= PP servers would have to support) protocol  extensions which would all= ow the client to nicely combine SIP VoIP and XMPP  presence & IM. =

 
 
There is no need for SI= P and XMPP servers to know about  each other or route protocol message= s between each other. All the logic is put  into the endpoints. No nee= d to worry about IMS either, except  that in theory the client can use= IMS for its VoIP service  (similar to any other SIP  infra).


User  Agents
  • Same as with servers: How many= and what protocol  RFCs are there in the combination? <= SPAN STYLE=3D'font-size:18pt'>=20
  • Which of the “services”= ; can be placed in the  applications in the endpoints or in the networ= k application protocols, such  as SIP and XMPP. This is the topic on i= nfrastructure vs. endpoint  applications.

[Markus] Just take any current SIP VoIP  UA implementat= ion, XMPP client implementation and glue them together  and you're alr= eady pretty far. Add a couple of extensions as proposed and it's  done= . From there onwards you have a pretty powerful machinery to add  appl= ications by using SIP session setup and XMPP message delivery  capabil= ities.


Application Protocol  Stacks
  • How many protocol stacks does = this involve and more  to the point, how many RFCs? =20
  • For SIP alone, see http://rfc3261.net/. What will be the total  comb= ined RFC count?

[Markus] All what we expect is already pretty widely  s= upported and even available as open source: basic SIP VoIP and XMPP IM and =  presence is enough to start with.   

NAT  Traversal
  • Will STUN/TURN/ICE work the sa= me for SIP and for  XMPP?

 [Markus] In our proposal SIP would be used for setting up  voice &a= mp; video sessions. So, you would need NAT traversal for that. How  th= at's done is outside the scope but either B2BUA or ICE based mechanisms &nb= sp;would work as far as they work in general. For XMPP we would not need to= worry  about NAT traversal beyond how its done in that protocol by de= fault. For a  client there is a caveat that it has to keepalive the TC= P connections with  BOTH SIP and XMPP servers so it would be recommend= ed to synchronize those  (send them at the same time) for instance in = a battery powered  device.

Return  on Investment (ROI): Cost and effort by developers. More netwo= rk  infrastructure, not even counting B2B NEs.
  • What is the additional time/mo= ney required for  developers that know SIP to also learn XMPP and vice= versa? This is all  about return on investment.

[Markus] This is a problem for sure, even more so  for = the people writing standard specs than code :)  Hopefully the  de= veloper would just have add a couple of simple extensions to existing  = ;SIP and XMPP implementations.


Support for a REST-full  architecture

The WWW has a REST architecture was formulated in 2000,  after the eme= rgence of SIP and XMMP.  As a result of its architecture,  the WW= W has had a transformational effect on the following (this is not a  c= omplete list). Some SIP work recommends already recommends REST, such as in=  RFC 4240 and in http://tools.ietf.org/html/draft-griffin-bliss-rest-00
  • Web applications from mail to = office apps  =20
  • Internet applications previously s= erved by dedicated  network applications protocols =20
  • Many other industries, from bankin= g to newsprint to  travel. And Oh, social networks, they also have &nb= sp;registrars...


Now please keep in mind the WWW architecture uses basically  only 3 co= mponents*: The URI for addressing, HTTP for transport and HTML for  da= ta rendering, augmented by some other languages (XML) and namespaces. Can w= e  benefit something from the WWW architecture? If yes what  spec= ifically?

Heresy: If the web developers could use HTTP only, what  other applica= tion level protocols do we really need except RTP/UDP?
This  includes in my mind TLS and DTLS for secure transport or even be= tter IMO: HIP  for many reasons.

[Markus] Personally I agree that REST+HTTP+Javascript= is a superior  toolset compared to SIP, XMPP, IMAP and so on to devel= op many applications.  However, there are still plenty of SIP based Vo= IP and XMPP based IM and  presence deployments out there and I don't e= xpect the web apps to replace all  of them in the near future :)
 
* T.V. Raman: “Toward 2W,  Beyond Web 2.0”, Communications= of the ACM, February 2009

Many or most  of these points may be moot or make no sense, but maybe = should be cleared up,  in case there are more naive people like me tha= t may be interested.

My  strict personal 2 cents.

FRANK comments are most  welcome.

Henry



On 9/4/09 7:09 AM, "Simo.Veikk= olainen@nokia.com" <Sim= o.Veikkolainen@nokia.com>  wrote:

 
Hi,
 
We would like to propose a new DISPATCH topic on  how SIP and XMPP can= be used together in a complementary  fashion.
 
We have been working on a solution which combines SIP  based VoIP and = XMPP based IM and Presence. The requirements and a proposed  solution = is outlined in http://tools.ietf.org/html/dra= ft-veikkolainen-sip-voip-xmpp-im-01  <http://tool= s.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01>  .
 
The motivation for this work comes from experience which  shows that m= ost standards based VoIP deployments use SIP. At the same time,  the E= xtensible Messaging and Presence Protocol (XMPP) is widely used in  in= stant messaging and presence services. An interesting scenario arises when =  a SIP based voice (and video) service is combined together with an XM= PP  based instant messaging and presence service.
 
Note that the  goal in this work is not SIP-XMPP protocol translation,= but to define  protocol extensions and best practises such that SIP b= ased VoIP and XMPP  based IM and presence could be seamlessly combined= and offered to the end  user. For rapid deployment, we assume no chan= ges in the server  infrastructure, and instead impose new requirements= and protocol extensions  only to the endpoints.
 
We would like to get some discussion  going on the use case itself as = well as on the solution. Also, we would like  to hear you thoughts on = DISPATCH or a new "dispatched" mini-WG as the home  for such= work.
 
Exact charter proposal and problem statemen is  to follow.
 
Regards,
Simo and  Markus
 
 


--_000_C6CFF5DE5C9Ehsinnreiadobecom_-- From pkyzivat@cisco.com Fri Sep 11 12:55:28 2009 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 5AF1028C12B for ; Fri, 11 Sep 2009 12:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.071 X-Spam-Level: X-Spam-Status: No, score=-5.071 tagged_above=-999 required=5 tests=[AWL=-1.527, BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_34=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 UOZhq6faLgoZ for ; Fri, 11 Sep 2009 12:55:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 25B2228C0F0 for ; Fri, 11 Sep 2009 12:55:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPRHqkpAZnme/2dsb2JhbADEXohIAZASBYIzgWU X-IronPort-AV: E=Sophos;i="4.44,372,1249257600"; d="scan'208";a="57786661" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Sep 2009 19:56:03 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8BJu30w030647; Fri, 11 Sep 2009 15:56:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8BJu3qm011661; Fri, 11 Sep 2009 19:56:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 15:56:03 -0400 Received: from [10.86.252.180] ([10.86.252.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 15:56:02 -0400 Message-ID: <4AAAAB49.8020206@cisco.com> Date: Fri, 11 Sep 2009 15:55:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Sep 2009 19:56:02.0730 (UTC) FILETIME=[E41598A0:01CA3319] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13887; t=1252698963; x=1253562963; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20New=20topic=20proposal=20f or=20DISPATCH |Sender:=20 |To:=20Henry=20Sinnreich=20; bh=+Jkb9motsxXtiK1/pnh6iHQuo0ibVsPYpFofFsAi4x4=; b=il1uHcH9009ql9fwMzgDAda4tEsaAZTOwqjBdaLs/bX3c9BnRkqr5VeEUD lNCz6GTPKFhj35eSNqQgzdXJZUvDFnNIeS5dqKrhXimRmP4N+0jGLosuJeSD Uv0eSQC0N4; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "dispatch@ietf.org" , "avshalom@il.ibm.com" , "gonzalo.camarillo@ericsson.com" , "Markus.Isomaki@nokia.com" , "Simo.Veikkolainen@nokia.com" Subject: Re: [dispatch] New topic proposal for DISPATCH 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: Fri, 11 Sep 2009 19:55:28 -0000 I agree that there are pragmatic reasons to pursue the coordination/coexistence of sip and xmpp. And pushing responsibility to the endpoints remains desirable. One thing that remains of concern to me in such work is that we end up with disjoint address spaces without any straightforward way to correlate them. So if I want a single "session" involving both voice via SIP and IM via xmpp, then I have great difficulty in discovering URIs for the "subordinate" session that correlate with those for the "primary" session. (No pejorative intended here - one or the other must go first.) Somehow this problem needs to be resolved. Thanks, Paul Henry Sinnreich wrote: > Hi Markus, > > Thanks for your thoughtful reply and I agree there are some scenarios > where it makes sense. > More important, doing this in the endpoints is the right approach IMO > and as you know, I will always defend the Internet end-to-end principle :-) > > This distributed approach is also IMO a good answer to the Interdomain > Scaling problem for IM > ( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I have copied > one of its authors here. > > This raises the questions: > > 1. Why stop at SIP and XMPP, and not add other popular IM protocols, > as is already done by quite a few products in the market? > 2. Can your approach be generalized in a more generic way? > > > If endpoints are accommodating several IM protocols, an IETF, Dispatch > recommended GENERIC approach would make many people feel more > comfortable about it. Your I-D could be used as a tested example for a > generic approach. > > Ranting on preferring endpoint applications to more application protocols > > I still believe creative application developers face the choice of > either inventing new applications or dedicating their time to learning > application protocols and they cannot do both. Learning and following > both SIP and XMPP to write and update code is quite a challenge. > Is there a better way? > For this reason, one single application protocol for IM and voice is enough. > Proof: Almost all the applications that make people buy smart phones, > use online office apps and enterprise apps run on HTTP(S) and their > application developers don’t have to worry about knowing how HTTP works. > As a result, HTTP has been also used to even carry streaming media, web > conferencing and IM. Just to avoid spending a lifetime to learn and > follow application protocols. But HTTP based apps dominate the > application space. This is however for another discussion elsewhere. > > My strictly personal 2 cents. > > Thanks again, > > Henry > > > On 9/11/09 8:11 AM, "Markus.Isomaki@nokia.com" > wrote: > > Hi Henry, > > Thanks for your feedback :) Let me answer to the excellent points > you raise. > > First of all, I would encourage you and everyone to carefully read > the Introduction chapter of the draft > (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 > > ) to be clear on what the proposal is about. That is, we are not > trying to boil the ocean and define all possible ways how SIP and > XMPP infrastructures could be combined, but instead try to define a > minimalistic approach whereby a client can use both SIP and XMPP in > an integrated manner WITHOUT requiring ANY changes on the servers > that are already deployed. > > See further comments below with [Markus]: > > > > ------------------------------------------------------------------------ > *From:* ext Henry Sinnreich [mailto:hsinnrei@adobe.com] > *Sent:* 04 September, 2009 18:42 > *To:* Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; > mary.barnes@nortel.com; gonzalo.camarillo@ericsson.com > *Cc:* Isomaki Markus (Nokia-CIC/Espoo); Olle E. Johansson > *Subject:* Re: [dispatch] New topic proposal for DISPATCH > > > I would like to second such work, but a far deeper look under > the hood is necessary, so we don’t do another Elbonia project. > http://dilbert.com/strips/comic/2009-09-01/ > > Here are some not very mature thoughts on the scope of the work. > The most interesting, ROI estimate and REST architecture > support are at the end. > > Servers > > Fundamentally, we need a registrar, a proxy and a presence > server: Three in total > > * What will be the duplication of servers and where > specifically? > * How does the SIP registrar communicate with the XMPP > server(s)? > * What may be the routing protocol(s) inside a SIP+XMMP > network? Think of IMS as a stressing use case. > > > [Markus] Our starting point is that we already have quite many > SIP VoIP deployments out there, as long as quite many XMPP > presence & IM deployments. So, the servers you mention already > exist. If one now wants to develop a client that does VoIP, IM > and presence together, it should be possible to utilize these > existing infrastrcutures and not have to wait for new ones to > be deployed (as for instance we have waited quite many years for > SIMPLE-based Presence servers to get deployed but compared to > XMPP there's very little in use). The idea is to define a > couple of E2E (as in nothing that SIP proxies or XMPP servers > would have to support) protocol extensions which would allow > the client to nicely combine SIP VoIP and XMPP presence & IM. > > > > There is no need for SIP and XMPP servers to know about each > other or route protocol messages between each other. All the > logic is put into the endpoints. No need to worry about IMS > either, except that in theory the client can use IMS for its > VoIP service (similar to any other SIP infra). > > > User Agents > > * Same as with servers: How many and what protocol RFCs are > there in the combination? > * Which of the “services” can be placed in the applications > in the endpoints or in the network application protocols, > such as SIP and XMPP. This is the topic on infrastructure > vs. endpoint applications. > > > [Markus] Just take any current SIP VoIP UA implementation, XMPP > client implementation and glue them together and you're already > pretty far. Add a couple of extensions as proposed and it's > done. From there onwards you have a pretty powerful machinery > to add applications by using SIP session setup and XMPP message > delivery capabilities. > > > Application Protocol Stacks > > * How many protocol stacks does this involve and more to > the point, how many RFCs? > * For SIP alone, see http://rfc3261.net/. What will be the > total combined RFC count? > > > [Markus] All what we expect is already pretty widely supported > and even available as open source: basic SIP VoIP and XMPP IM > and presence is enough to start with. > > > NAT Traversal > > * Will STUN/TURN/ICE work the same for SIP and for XMPP? > > > [Markus] In our proposal SIP would be used for setting up voice > & video sessions. So, you would need NAT traversal for that. How > that's done is outside the scope but either B2BUA or ICE based > mechanisms would work as far as they work in general. For XMPP > we would not need to worry about NAT traversal beyond how its > done in that protocol by default. For a client there is a > caveat that it has to keepalive the TCP connections with BOTH > SIP and XMPP servers so it would be recommended to synchronize > those (send them at the same time) for instance in a battery > powered device. > > > Return on Investment (ROI): Cost and effort by developers. More > network infrastructure, not even counting B2B NEs. > > * What is the additional time/money required for developers > that know SIP to also learn XMPP and vice versa? This is > all about return on investment. > > > [Markus] This is a problem for sure, even more so for the > people writing standard specs than code :) Hopefully the > developer would just have add a couple of simple extensions to > existing SIP and XMPP implementations. > > > Support for a REST-full architecture > > The WWW has a REST architecture was formulated in 2000, after > the emergence of SIP and XMMP. As a result of its architecture, > the WWW has had a transformational effect on the following > (this is not a complete list). Some SIP work recommends already > recommends REST, such as in RFC 4240 and in > http://tools.ietf.org/html/draft-griffin-bliss-rest-00 > > * Web applications from mail to office apps > * Internet applications previously served by dedicated > network applications protocols > * Many other industries, from banking to newsprint to > travel. And Oh, social networks, they also have > registrars... > > > > Now please keep in mind the WWW architecture uses basically > only 3 components*: The URI for addressing, HTTP for transport > and HTML for data rendering, augmented by some other languages > (XML) and namespaces. Can we benefit something from the WWW > architecture? If yes what specifically? > > Heresy: If the web developers could use HTTP only, what other > application level protocols do we really need except RTP/UDP? > This includes in my mind TLS and DTLS for secure transport or > even better IMO: HIP for many reasons. > > > [Markus] Personally I agree that REST+HTTP+Javascript is a > superior toolset compared to SIP, XMPP, IMAP and so on to > develop many applications. However, there are still plenty of > SIP based VoIP and XMPP based IM and presence deployments out > there and I don't expect the web apps to replace all of them in > the near future :) > > > * T.V. Raman: “Toward 2W, Beyond Web 2.0”, Communications of > the ACM, February 2009 > > Many or most of these points may be moot or make no sense, but > maybe should be cleared up, in case there are more naive people > like me that may be interested. > > My strict personal 2 cents. > > FRANK comments are most welcome. > > Henry > > > > On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" > wrote: > > > > Hi, > > We would like to propose a new DISPATCH topic on how SIP > and XMPP can be used together in a complementary fashion. > > We have been working on a solution which combines SIP based > VoIP and XMPP based IM and Presence. The requirements and a > proposed solution is outlined in > _http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01_ > > . > > The motivation for this work comes from experience which > shows that most standards based VoIP deployments use SIP. > At the same time, the Extensible Messaging and Presence > Protocol (XMPP) is widely used in instant messaging and > presence services. An interesting scenario arises when a > SIP based voice (and video) service is combined together > with an XMPP based instant messaging and presence service. > > Note that the goal in this work is not SIP-XMPP protocol > translation, but to define protocol extensions and best > practises such that SIP based VoIP and XMPP based IM and > presence could be seamlessly combined and offered to the end > user. For rapid deployment, we assume no changes in the > server infrastructure, and instead impose new requirements > and protocol extensions only to the endpoints. > > We would like to get some discussion going on the use case > itself as well as on the solution. Also, we would like to > hear you thoughts on DISPATCH or a new "dispatched" mini-WG > as the home for such work. > > Exact charter proposal and problem statemen is to follow. > > Regards, > Simo and Markus > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mohamed.boucadair@orange-ftgroup.com Mon Sep 14 00:30:50 2009 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 9701228C124 for ; Mon, 14 Sep 2009 00:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 k1kWo813potJ for ; Mon, 14 Sep 2009 00:30:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 85FAB28C10E for ; Mon, 14 Sep 2009 00:30:49 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7638B248234; Mon, 14 Sep 2009 09:31:32 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5BDC527C057; Mon, 14 Sep 2009 09:31:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 14 Sep 2009 09:31:32 +0200 From: To: Mary Barnes , Andrew Allen , "Gonzalo.Camarillo@ericsson.com" , "dispatch@ietf.org" Date: Mon, 14 Sep 2009 09:31:30 +0200 Thread-Topic: SIP, IPv6 and IPv4-IPv6 interworking (was RE: draft-boucadair-dispatch-ipv6-atypes) Thread-Index: AcovpzN93BXaDHlmQCWI1E0jnX/wAAAKkRVgAU6pQCA= Message-ID: <10411_1252913492_4AADF154_10411_7906_1_94C682931C08B048B7A8645303FDC9F307476894E7@PUEXCB1B.nanterre.francetelecom.fr> References: <61968779B8AC4C4BAB421D4C12F008C01DF9F6FE@XCH47YKF.rim.net> <1ECE0EB50388174790F9694F77522CCF1FCF70A5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FCF70A5@zrc2hxm0.corp.nortel.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-tm-as-product-ver: SMEX-8.0.0.1259-5.500.1027-16048.005 x-tm-as-result: No--31.038000-8.000000-31 x-tm-as-user-approved-sender: No 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-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.9.14.64821 Subject: [dispatch] SIP, IPv6 and IPv4-IPv6 interworking (was RE: draft-boucadair-dispatch-ipv6-atypes) 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, 14 Sep 2009 07:30:50 -0000 =20 Dear Mary, all, We are definitely aware that unlike sipping ML (http://www.ietf.org/mail-ar= chive/web/sipping/current/msg16718.html) this draft hasn't been discussed i= n the DIPATCH mailing list.=20 The topic we are proposing is not restricted to the atypes attribute but co= vers also issues related to the migration of SIP services to IPv6 and IPv4-= IPv6 interworking. This is a timely valid topic since IPv4 address exhausti= on is a real concern. Therefore, the impact on SIP-based services need to b= e identified and solution proposed.=20 Cheers, Med -----Message d'origine----- De : Mary Barnes [mailto:mary.barnes@nortel.com]=20 Envoy=E9 : lundi 7 septembre 2009 17:48 =C0 : Andrew Allen; Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org Cc : BOUCADAIR Mohamed NCPI/NAD/TIP Objet : RE: draft-boucadair-dispatch-ipv6-atypes Hi Andrew, At this point in time, we're not handling agenda requests per se. Right now= , we want to know the topics for which folks want feedback PRIOR to IETF-76 so that we can use the agenda time to discuss issues that can't be = resolved on the mailing list before then. We can take this as a placeholder= for this topic and thus, we would expect to see a detailed problem stateme= nt, etc. on or before Sept. 21st., per the IETF-76 DISPATCH deadlines: http://www.ietf.org/mail-archive/web/dispatch/current/msg00500.html Just a note that when I summarized the status of the post-IETF-75 topics, t= his one had received no ML discussion nor indication of interest in working= on this problem: http://www.ietf.org/mail-archive/web/dispatch/current/msg00501.html So, you really need to get some WG feedback on this proposal if you want it= to move forward.=20=20 Thanks, Mary.=20 -----Original Message----- From: Andrew Allen [mailto:aallen@rim.com] Sent: Monday, September 07, 2009 5:37 AM To: Barnes, Mary (RICH2:AR00); Gonzalo.Camarillo@ericsson.com; dispatch@iet= f.org Cc: mohamed.boucadair@orange-ftgroup.com Subject: draft-boucadair-dispatch-ipv6-atypes Can we request agenda time in Dispatch to discuss how to proceed with draft-boucadair-dispatch-ipv6-atypes? Thanks Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From christer.holmberg@ericsson.com Mon Sep 14 01:59:47 2009 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 D27993A67F9 for ; Mon, 14 Sep 2009 01:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.464 X-Spam-Level: X-Spam-Status: No, score=-5.464 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, HELO_EQ_SE=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 14NTy3ViQlSM for ; Mon, 14 Sep 2009 01:59:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 75E2D3A6877 for ; Mon, 14 Sep 2009 01:59:41 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2cae000005a8f-bf-4aae06285561 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 62.D2.23183.8260EAA4; Mon, 14 Sep 2009 11:00:24 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 11:00:23 +0200 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: Mon, 14 Sep 2009 10:58:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-76 DISPATCH WG deadlines : CBUS Thread-Index: Acoy6v86HwZmglQBSaK2ur/X8fpuPwCLowhZ References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> <4AAA5C98.1080502@sipstation.com> From: "Christer Holmberg" To: X-OriginalArrivalTime: 14 Sep 2009 09:00:23.0898 (UTC) FILETIME=[CB8D73A0:01CA3519] X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : CBUS 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, 14 Sep 2009 08:59:47 -0000 Hi, =20 Some time ago I submitted a requirement draft for the OMA work on CBUS. =20 In short, the idea of CBUS is that a client provides a set of conditions = (which can be related to presence, location etc etc) to a CBUS server. = Based on the conditions, the CBUS server communicates with presence = servers, locations servers etc in order to figure out which users = fulfill the conditions. The CBUS server then provides the client with a = list of the URIs which fulfilled the conditions. The CBUS can do that on = a one-time bases, a time-based basis, or whenever the information = changes (called evaluation parameters). In addition, the client can = provide a set or URIs, or a reference to URIs, which the CBUS chooses = from (called candidate URIs).=20 =20 The idea is to provide the URIs in a subscription event package, and the = associated SUBSCRIBE would contain the conditions (most likely using an = XML document). =20 Dean raised a question whether it would be enough to define the new = event package, and re-use RFC4660/1 to provide the conditions. =20 Due to summer vacations etc it took a while to look into this, but me = and some OMA people have now looked into this. =20 Our initial conclusion is that it is NOT very feasible to re-use RFC = 4660/1.=20 =20 RFC4660/1 provides a filtering mechanism, where the client specifies = what type of information he wants to receive. However, in CBUS the type = of information is always the same: the URI list. Instead, the CLIENT = provides the type of information (conditions) on which the URIs shall be = selected (and, in addition to that, the evaluation parameter(s) and = candidate URI(s)). =20 We did look at whether it would be possible to somehow re-use 4660/1, = but we thought it would be rather hacky. Some of the 4660/1 XML elements = would probably be unused, and there would be a need to define new = extensions - so we thought it would be nicer to define a new XML schema = instead. =20 So, I would like to request DISPATCH time to discuss this. We plan to = provide an updated version of the draft, with clarifications and more = details etc. =20 Regards, =20 Christer From L.Liess@telekom.de Mon Sep 14 02:02:43 2009 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 0C00B3A6951 for ; Mon, 14 Sep 2009 02:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.943, BAYES_40=-0.185, 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 8oQQrCNymPwY for ; Mon, 14 Sep 2009 02:02:42 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id BD9EF3A68AE for ; Mon, 14 Sep 2009 02:02:41 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 14 Sep 2009 11:03:20 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 11:03:20 +0200 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: Mon, 14 Sep 2009 11:03:19 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00366C935@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Topic for DISPATCH: Alert-Info URNs thread-index: AcoyJltvVmOzX1/dQmST6hgnSUPT5w== From: To: X-OriginalArrivalTime: 14 Sep 2009 09:03:20.0502 (UTC) FILETIME=[34D11560:01CA351A] Subject: [dispatch] Topic for DISPATCH: Alert-Info URNs 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, 14 Sep 2009 09:02:43 -0000 Mary, Gonzalo, At the IETF-75 we had a presentation and a discussion in BLISS on the = "Alert-Info URNs" proposal, described in = http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt. = During the discussion, it was recommended to submit the work to DISPATCH = and to document the interop problems.=20 So, we would like to propose this as a new topic for DISPATCH.=20 The motivation for this work comes from interoperability problems when = SIP services require the semantic for a ring- / ringback-tone to be = transmitted in in a SIP-message. =20 The RFC 3261 allows an UAS or proxy to provide a specific ring- = /ringback-tone as a reference (e.g. HTTP URI) which can be played to the = user in the Alert-Info header. This mechanism does not ensure = interoperability when there is no common understanding of the referenced = content (different countries or vendors, hearing impaired) or when the = user has his own tones configured in the end device.=20 For interoperability of services as call waiting, call forwarding, blind = transfer, automatic callback, call hold or emergency annoncements sent = over PBX systems, a mechanism is needed which allows the UAs and proxies = to transmit an indication which contains the semantic of the rendering = instead of the rendering itself and allows the receiving UA to decide = about the concrete rendering.=20 The charter proposal and the updated draft are to follow.=20 Kind regards Laura From L.Liess@telekom.de Mon Sep 14 02:17:23 2009 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 608193A69E7 for ; Mon, 14 Sep 2009 02:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=0.202, 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 aJ-Y-zLJMU3D for ; Mon, 14 Sep 2009 02:17:22 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 0B9DB3A69E4 for ; Mon, 14 Sep 2009 02:17:21 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 14 Sep 2009 11:16:53 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 11:16:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 Sep 2009 11:16:51 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00366C95D@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Topic for DISPATCH: Alert-Info URNs thread-index: Aco1HBhGrdy8ZGAhT9qG5G0xRoQBIQ== From: To: X-OriginalArrivalTime: 14 Sep 2009 09:16:52.0935 (UTC) FILETIME=[19108570:01CA351C] Subject: [dispatch] Topic for DISPATCH: Alert-Info URNs 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, 14 Sep 2009 09:17:23 -0000 Mary, Gonzalo, At the IETF-75 we had a presentation and a discussion in BLISS on the "Alert-Info URNs" proposal, described in http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt. During the discussion, it was recommended to submit the work to DISPATCH and to document the interop problems.=20 So, we would like to propose this as a new topic for DISPATCH.=20 The motivation for this work comes from interoperability problems when SIP services require the semantic for a ring- / ringback-tone to be transmitted in in a SIP-message. =20 The RFC 3261 allows an UAS or proxy to provide a specific ring- /ringback-tone as a reference (e.g. HTTP URI) which can be played to the user in the Alert-Info header. This mechanism does not ensure interoperability when there is no common understanding of the referenced content (different countries or vendors, hearing impaired) or when the user has his own tones configured in the end device.=20 For interoperability of services as call waiting, call forwarding, blind transfer, automatic callback, call hold or emergency annoncements sent over PBX systems, a mechanism is needed which allows the UAs and proxies to transmit an indication which contains the semantic of the rendering instead of the rendering itself and allows the receiving UA to decide about the concrete rendering.=20 The charter proposal and the updated draft are to follow.=20 Kind regards Laura From R.Jesske@telekom.de Mon Sep 14 04:09:42 2009 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 C13CA28C135 for ; Mon, 14 Sep 2009 04:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 TpSU0zriQwpr for ; Mon, 14 Sep 2009 04:09:41 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 20F123A69FF for ; Mon, 14 Sep 2009 04:09:40 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 14 Sep 2009 13:10:17 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 13:10:16 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA352B.F01DE98C" x-mimeole: Produced By Microsoft Exchange V6.5 Date: Mon, 14 Sep 2009 13:10:15 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404EE1E67@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft version of draft-jesske-dispatch-reason-in-responses-00 Thread-Index: Aco1K+7KV0UFjyNlROyP6QfYx+RWpw== From: To: X-OriginalArrivalTime: 14 Sep 2009 11:10:16.0385 (UTC) FILETIME=[F03C9B10:01CA352B] Subject: [dispatch] New draft version of draft-jesske-dispatch-reason-in-responses-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, 14 Sep 2009 11:09:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA352B.F01DE98C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, A since a couple of weeks a new version of the Reason in Responses draft = is now available. http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-00 I have incorporated all comments and the discussion conclusions received = for this draft. Comments are welcome. Best Regards Roland Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Roland Jesske=20 Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,=20 Postfach, 64307 Darmstadt (Postanschrift)=20 +496151 628 2766 (Tel) +491718618445 (Mobile)=20 E-Mail: r.jesske@telekom.de=20 http://www.telekom.de =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (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 ------_=_NextPart_001_01CA352B.F01DE98C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New draft version of = draft-jesske-dispatch-reason-in-responses-00

Dear all,
A since a couple of weeks a new = version of the Reason in Responses draft is now available.

http://tools.ietf.org/html/draft-jesske-dispatch-reason-in= -responses-00

I have incorporated all comments and = the discussion conclusions received for this draft.

Comments are welcome.

Best Regards

Roland

Deutsche Telekom = Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Gateways, Protokolle, Konvergenz, = TE32-1
Heinrich-Hertz-Str. 3-7, 64295 = Darmstadt,
Postfach, 64307 Darmstadt = (Postanschrift)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de=20



Registerrechtliche = Unternehmensangaben:
Deutsche Telekom Netzproduktion (DT NP) = GmbH
Aufsichtsrat: Timotheus H=F6ttges (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


------_=_NextPart_001_01CA352B.F01DE98C-- From AVSHALOM@il.ibm.com Mon Sep 14 10:35:48 2009 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 533CE3A68B2 for ; Mon, 14 Sep 2009 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=-1.561, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=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 vJwrNmmB2Qk0 for ; Mon, 14 Sep 2009 10:35:34 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id 391B43A6A6A for ; Mon, 14 Sep 2009 10:35:32 -0700 (PDT) Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n8EHaCUi026832 for ; Mon, 14 Sep 2009 17:36:12 GMT Received: from d12av05.megacenter.de.ibm.com (d12av05.megacenter.de.ibm.com [9.149.165.216]) by d12nrmr1507.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8EHaCWr3686636 for ; Mon, 14 Sep 2009 19:36:12 +0200 Received: from d12av05.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n8EHaBbr007095 for ; Mon, 14 Sep 2009 19:36:11 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n8EHaBb5007092; Mon, 14 Sep 2009 19:36:11 +0200 In-Reply-To: References: To: Henry Sinnreich , Markus.Isomaki@nokia.com, Simo.Veikkolainen@nokia.com MIME-Version: 1.0 X-KeepSent: ABF2FC91:F646C962-C2257631:005FDAB0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Mon, 14 Sep 2009 20:36:10 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 14/09/2009 20:36:10, Serialize complete at 14/09/2009 20:36:10 Content-Type: multipart/alternative; boundary="=_alternative 006042C7C2257631_=" Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 14 Sep 2009 17:35:48 -0000 This is a multipart message in MIME format. --=_alternative 006042C7C2257631_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I think that this draft is an important start for an important work item=20 that the IETF should do. --Avshalom From: Henry Sinnreich To: "Markus.Isomaki@nokia.com" ,=20 "Simo.Veikkolainen@nokia.com" ,=20 "dispatch@ietf.org" , "mary.barnes@nortel.com"=20 , "gonzalo.camarillo@ericsson.com"=20 Cc: Avshalom Houri/Haifa/IBM@IBMIL Date: 11/09/2009 08:41 PM Subject: Re: [dispatch] New topic proposal for DISPATCH Hi Markus, Thanks for your thoughtful reply and I agree there are some scenarios=20 where it makes sense. More important, doing this in the endpoints is the right approach IMO and=20 as you know, I will always defend the Internet end-to-end principle :-) This distributed approach is also IMO a good answer to the Interdomain=20 Scaling problem for IM=20 ( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I have copied=20 one of its authors here. This raises the questions:=20 1. Why stop at SIP and XMPP, and not add other popular IM protocols,=20 as is already done by quite a few products in the market?=20 2. Can your approach be generalized in a more generic way? If endpoints are accommodating several IM protocols, an IETF, Dispatch=20 recommended GENERIC approach would make many people feel more comfortable=20 about it. Your I-D could be used as a tested example for a generic=20 approach. Ranting on preferring endpoint applications to more application protocols I still believe creative application developers face the choice of either=20 inventing new applications or dedicating their time to learning=20 application protocols and they cannot do both. Learning and following both = SIP and XMPP to write and update code is quite a challenge.=20 Is there a better way?=20 For this reason, one single application protocol for IM and voice is=20 enough. Proof: Almost all the applications that make people buy smart phones, use=20 online office apps and enterprise apps run on HTTP(S) and their=20 application developers don?t have to worry about knowing how HTTP works.=20 As a result, HTTP has been also used to even carry streaming media, web=20 conferencing and IM. Just to avoid spending a lifetime to learn and follow = application protocols. But HTTP based apps dominate the application space. = This is however for another discussion elsewhere.=20 My strictly personal 2 cents. Thanks again, Henry=20 On 9/11/09 8:11 AM, "Markus.Isomaki@nokia.com" =20 wrote: Hi Henry, Thanks for your feedback :) Let me answer to the excellent points you=20 raise. First of all, I would encourage you and everyone to carefully read the=20 Introduction chapter of the draft ( http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 < http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> ) to be = clear on what the proposal is about. That is, we are not trying to boil=20 the ocean and define all possible ways how SIP and XMPP infrastructures=20 could be combined, but instead try to define a minimalistic approach=20 whereby a client can use both SIP and XMPP in an integrated manner WITHOUT = requiring ANY changes on the servers that are already deployed. See further comments below with [Markus]: =20 From: ext Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: 04 September, 2009 18:42 To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; =20 mary.barnes@nortel.com; gonzalo.camarillo@ericsson.com Cc: Isomaki Markus (Nokia-CIC/Espoo); Olle E. Johansson Subject: Re: [dispatch] New topic proposal for DISPATCH =20 I would like to second such work, but a far deeper look under the hood is = necessary, so we don?t do another Elbonia project. http://dilbert.com/strips/comic/2009-09-01/ Here are some not very mature thoughts on the scope of the work.=20 The most interesting, ROI estimate and REST architecture support are at=20 the end. Servers Fundamentally, we need a registrar, a proxy and a presence server: Three=20 in total What will be the duplication of servers and where specifically?=20 How does the SIP registrar communicate with the XMPP server(s)?=20 What may be the routing protocol(s) inside a SIP+XMMP network? Think of=20 IMS as a stressing use case. [Markus] Our starting point is that we already have quite many SIP VoIP=20 deployments out there, as long as quite many XMPP presence & IM=20 deployments. So, the servers you mention already exist. If one now wants=20 to develop a client that does VoIP, IM and presence together, it should be = possible to utilize these existing infrastrcutures and not have to wait=20 for new ones to be deployed (as for instance we have waited quite many=20 years for SIMPLE-based Presence servers to get deployed but compared to=20 XMPP there's very little in use). The idea is to define a couple of E2E=20 (as in nothing that SIP proxies or XMPP servers would have to support)=20 protocol extensions which would allow the client to nicely combine SIP=20 VoIP and XMPP presence & IM.=20 =20 =20 There is no need for SIP and XMPP servers to know about each other or=20 route protocol messages between each other. All the logic is put into the = endpoints. No need to worry about IMS either, except that in theory the=20 client can use IMS for its VoIP service (similar to any other SIP infra). = User Agents Same as with servers: How many and what protocol RFCs are there in the=20 combination?=20 Which of the ?services? can be placed in the applications in the=20 endpoints or in the network application protocols, such as SIP and XMPP.=20 This is the topic on infrastructure vs. endpoint applications. [Markus] Just take any current SIP VoIP UA implementation, XMPP client=20 implementation and glue them together and you're already pretty far. Add=20 a couple of extensions as proposed and it's done. From there onwards you=20 have a pretty powerful machinery to add applications by using SIP session = setup and XMPP message delivery capabilities.=20 Application Protocol Stacks How many protocol stacks does this involve and more to the point, how=20 many RFCs?=20 For SIP alone, see http://rfc3261.net/. What will be the total combined=20 RFC count? [Markus] All what we expect is already pretty widely supported and even=20 available as open source: basic SIP VoIP and XMPP IM and presence is=20 enough to start with. =20 NAT Traversal Will STUN/TURN/ICE work the same for SIP and for XMPP? [Markus] In our proposal SIP would be used for setting up voice & video=20 sessions. So, you would need NAT traversal for that. How that's done is=20 outside the scope but either B2BUA or ICE based mechanisms would work as=20 far as they work in general. For XMPP we would not need to worry about=20 NAT traversal beyond how its done in that protocol by default. For a=20 client there is a caveat that it has to keepalive the TCP connections with = BOTH SIP and XMPP servers so it would be recommended to synchronize those = (send them at the same time) for instance in a battery powered device. Return on Investment (ROI): Cost and effort by developers. More network=20 infrastructure, not even counting B2B NEs. What is the additional time/money required for developers that know SIP=20 to also learn XMPP and vice versa? This is all about return on=20 investment. [Markus] This is a problem for sure, even more so for the people writing=20 standard specs than code :) Hopefully the developer would just have add=20 a couple of simple extensions to existing SIP and XMPP implementations.=20 Support for a REST-full architecture The WWW has a REST architecture was formulated in 2000, after the=20 emergence of SIP and XMMP. As a result of its architecture, the WWW has=20 had a transformational effect on the following (this is not a complete=20 list). Some SIP work recommends already recommends REST, such as in RFC=20 4240 and in http://tools.ietf.org/html/draft-griffin-bliss-rest-00 Web applications from mail to office apps =20 Internet applications previously served by dedicated network applications = protocols=20 Many other industries, from banking to newsprint to travel. And Oh,=20 social networks, they also have registrars... Now please keep in mind the WWW architecture uses basically only 3=20 components*: The URI for addressing, HTTP for transport and HTML for data = rendering, augmented by some other languages (XML) and namespaces. Can we=20 benefit something from the WWW architecture? If yes what specifically? Heresy: If the web developers could use HTTP only, what other application = level protocols do we really need except RTP/UDP? This includes in my mind TLS and DTLS for secure transport or even better = IMO: HIP for many reasons. [Markus] Personally I agree that REST+HTTP+Javascript is a superior=20 toolset compared to SIP, XMPP, IMAP and so on to develop many=20 applications. However, there are still plenty of SIP based VoIP and XMPP=20 based IM and presence deployments out there and I don't expect the web=20 apps to replace all of them in the near future :) =20 * T.V. Raman: ?Toward 2W, Beyond Web 2.0?, Communications of the ACM,=20 February 2009 Many or most of these points may be moot or make no sense, but maybe=20 should be cleared up, in case there are more naive people like me that=20 may be interested. My strict personal 2 cents. FRANK comments are most welcome. Henry On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" < Simo.Veikkolainen@nokia.com> wrote: =20 Hi, =20 We would like to propose a new DISPATCH topic on how SIP and XMPP can be=20 used together in a complementary fashion. =20 We have been working on a solution which combines SIP based VoIP and XMPP = based IM and Presence. The requirements and a proposed solution is=20 outlined in=20 http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 < http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> . =20 The motivation for this work comes from experience which shows that most=20 standards based VoIP deployments use SIP. At the same time, the=20 Extensible Messaging and Presence Protocol (XMPP) is widely used in=20 instant messaging and presence services. An interesting scenario arises=20 when a SIP based voice (and video) service is combined together with an=20 XMPP based instant messaging and presence service.=20 =20 Note that the goal in this work is not SIP-XMPP protocol translation, but = to define protocol extensions and best practises such that SIP based VoIP = and XMPP based IM and presence could be seamlessly combined and offered=20 to the end user. For rapid deployment, we assume no changes in the server = infrastructure, and instead impose new requirements and protocol=20 extensions only to the endpoints. =20 We would like to get some discussion going on the use case itself as well = as on the solution. Also, we would like to hear you thoughts on DISPATCH=20 or a new "dispatched" mini-WG as the home for such work. =20 Exact charter proposal and problem statemen is to follow.=20 =20 Regards, Simo and Markus =20 =20 --=_alternative 006042C7C2257631_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I think that this draft is an important start for an important work item that the IETF should do.

--Avshalom


From: Henry Sinnreich <hsinnrei@adobe.c= om>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "dispatch@ietf.org" <disp= atch@ietf.org>, "mary.barnes@nortel.com" <mary.barnes@nortel.com>, "go= nzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com>
Cc: Avshalom Houri/Haifa/IBM@IBMIL
Date: 11/09/2009 08:41 PM
Subject: Re: [dispatch] New topic proposal for DISPATCH




Hi Markus,

Thanks for your thoughtful reply and I agree there are some scenarios where it makes sense.
More important, doing this in the endpoints is the right approach IMO and as you know, I will always defend the Internet end-to-end principle :-)

This distributed approach is also IMO a good answer to the Interdomain Scaling problem for IM
( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I have copied one of its authors here.

This raises the questions:

1.        Why stop at SIP and XMPP, and not add other popular IM protocols, as is already done by quite a few products in the market?
2.        Can your approach be generalized in a more generic way?

If endpoints are accommodating several IM protocols, an IETF, Dispatch recommended GENERIC approach would make many people feel more comfortable about it. Your I-D could be used as a tested example for a generic approach= .

Ranting on preferring endpoint applications to more application protocols
I still believe creative application developers face the choice of either inventing new applications or dedicating their time to learning application protocols and they cannot do both. Learning and following both SIP and XMPP to write and update code is quite a challenge.
Is there a better way?
For this reason, one single application protocol for IM and voice is enough= .
Proof: Almost all the applications that make people buy smart phones, use online office apps and enterprise apps run on HTTP(S) and their application developers don’t have to worry about knowing how HTTP works. As a res= ult, HTTP has been also used to even carry streaming media, web conferencing and IM. Just to avoid spending a lifetime to learn and follow application protocols. But HTTP based apps dominate the application space. This is however for another discussion elsewhere.

My strictly personal 2 cents.

Thanks again,

Henry


On 9/11/09 8:11 AM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> wrote:
Hi Henry,

Thanks for your feedback :) Let me answer to the excellent points you raise= .

First of all, I would encourage you and everyone to carefully read the Introduction chapter of the draft (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp= -im-01 <http://tools.ie= tf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> ) to be clear on what the proposal is about. That is, we are not trying to boil the ocean and define all possible ways how SIP and XMPP infrastruct= ures could be combined, but instead try to define a minimalistic approach whereby a client can use both SIP and XMPP in an integrated manner WITHOUT requiring ANY changes on the servers that are already deployed.

See further comments below with [Markus]:


From: ext Henry Sinnreich  [= mailto:hsinnrei@adobe.com]
Sent: 04 September, 2009  18:42
To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org<= /font>;  mary.barnes@nortel.com; gonzalo.camarillo@ericsson.com
Cc: Isomaki  Markus (Nokia-CIC/Espoo); Olle E. Johansson
Subject: Re: [dispatch]  New topic proposal for DISPATCH


I would like to second such work, but a far deeper  look under the hood is necessary, so we don’t do another Elbonia  project.
http://dilbert.com/strips/comic/200= 9-09-01/

Here  are some not very mature thoughts on the scope of the work.
The most  interesting, ROI estimate and REST architecture support are at the  end.

Servers

Fundamentally, we need a registrar, a proxy and a  presence server: Three in total
  • What will be the duplication of servers and where  specifically?
  • How does the SIP registrar communicate with the XMPP  server(s)?
  • What may be the routing protocol(s) ins= ide a  SIP+XMMP network? Think of IMS as a stressing use  case.

[Markus] Our starting point is that we already have quite  many SIP VoIP deployments out there, as long as quite many XMPP presence &  = ;IM deployments. So, the servers you mention already exist. If one now  wa= nts to develop a client that does VoIP, IM and presence together, it should  be possible to utilize these existing infrastrcutures and not have to wait for  new ones to be deployed (as for instance we have waited quite many years for  SIMPLE-based Presence servers to get deployed but compared to XMPP there's  very little in use). The idea is to define a couple of E2E (as in  nothing that SIP proxies or XMPP servers would have to support) protocol  extensions which would allow the client to nicely combine SIP VoIP and XMPP  presence & IM. =



There is no need for SIP and XMPP servers to know about  each other or route protocol messages between each other. All the logic is put  i= nto the endpoints. No need to worry about IMS either, except  that in theory the client can use IMS for its VoIP service  (similar to any other SIP  infra).


User  Agents
  • Same as with servers: How many and what protocol  RFCs are there in the combination?
  • Which of the “services” can= be placed in the  applications in the endpoints or in the network application protocols, such  as SIP and XMPP. This is the topic on infrastructure vs. endpoint  applications.

[Markus] Just take any current SIP VoIP  UA implementation, XMPP client implementation and glue them together  and you're already pretty far. Add a couple of extensions as proposed and it's  done. From there onwards you have a pretty powerful machinery to add  applications by using SIP session setup and XMPP message delivery  capabilities.


Application Protocol  Stacks
  • How many protocol stacks does this invo= lve and more  to the point, how many RFCs?
  • For SIP alone, see http://rfc= 3261.net/. What will be the total  combined RFC count?

[Markus] All what we expect is already pretty widely  supported and even available as open source: basic SIP VoIP and XMPP IM and  presence is enough to start with.  


NAT  Traversal
  • Will STUN/TURN/ICE work the same for SIP and for  XMPP?
<= br> [Markus] In our proposal SIP would be used for setting up  voice & video sessions. So, you would need NAT traversal for that. How  that's done is outside the scope but either B2BUA or ICE based mechanisms  wo= uld work as far as they work in general. For XMPP we would not need to worry  about NAT traversal beyond how its done in that protocol by default. For a  client there is a caveat that it has to keepalive the TCP conne= ctions with  BOTH SIP and XMPP servers so it would be recommended to synchron= ize those  (send them at the same time) for instance in a battery powered  device.


Return  on Investment (ROI): Cost and effort by developers. More netwo= rk  infrastructure, not even counting B2B NEs.
  • What is the additional time/money requi= red for  developers that know SIP to also learn XMPP and vice versa? This is all  about return on investment.

[Markus] This is a problem for sure, even more so  for the people writing standard specs than code :)  Hopefully the  developer would just have add a couple of simple extensions to existing  SIP and XMPP implementations.


Support for a REST-full  architecture

The WWW has a REST architecture was formulated in 2000,  after the emergence of SIP and XMMP.  As a result of its architecture,  the WWW has had a transformational effect on the following (this is not a  = ;complete list). Some SIP work recommends already recommends REST, such as in  R= FC 4240 and in http://tools.iet= f.org/html/draft-griffin-bliss-rest-00
  • Web applications from mail to office ap= ps  
  • Internet applications previously served by dedicated  network applications protocols
  • Many other industries, from banking to newsprint to  travel. And Oh, social networks, they also have  re= gistrars...


Now please keep in mind the WWW architecture uses basically  only 3 components*: The URI for addressing, HTTP for transport and HTML for  data rendering, augmented by some other languages (XML) and namespace= s. Can we  benefit something from the WWW architecture? If yes what  = ;specifically?

Heresy: If the web developers could use HTTP only, what  other applica= tion level protocols do we really need except RTP/UDP?
This  includes in my mind TLS and DTLS for secure transport or even better IMO: HIP  for many reasons.


[Markus] Personally I agree that REST+HTTP+Javascript is a superior  t= oolset compared to SIP, XMPP, IMAP and so on to develop many applications.  H= owever, there are still plenty of SIP based VoIP and XMPP based IM and  presen= ce deployments out there and I don't expect the web apps to replace all  = of them in the near future :)


* T.V. Raman: “Toward 2W,  Beyond Web 2.0”, Communications= of the ACM, February 2009

Many or most  of these points may be moot or make no sense, but maybe should be cleared up,  in case there are more naive people like me that may be interested.

My  strict personal 2 cents.

FRANK comments are most  welcome.

Henry



On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com<= /font>" <Simo.Veikkolainen@nokia.com>  wrote:
Hi,

We would like to propose a new DISPATCH topic on  how SIP and XMPP can be used together in a complementary  fashion.

We have been working on a solution which combines SIP  based VoIP and XMPP based IM and Presence. The requirements and a proposed  solut= ion is outlined in http= ://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01  <http://to= ols.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01>  .

The motivation for this work comes from experience which  shows that most standards based VoIP deployments use SIP. At the same time,  the Extensible Messaging and Presence Protocol (XMPP) is widely used in  i= nstant messaging and presence services. An interesting scenario arises when  a SIP based voice (and video) service is combined together with an XMPP  = ;based instant messaging and presence service.

Note that the  goal in this work is not SIP-XMPP protocol translation, but to define  protocol extensions and best practises such that SIP based VoIP and XMPP  based IM and presence could be seamlessly combined and offered to the end  user. For rapid deployment, we assume no chang= es in the server  infrastructure, and instead impose new requirements and protocol extensions  only to the endpoints.

We would like to get some discussion  going on the use case itself as well as on the solution. Also, we would like  to hear you thoughts on DISPATCH or a new "dispatched" mini-WG as the home  for such work.

Exact charter proposal and problem statemen is  to follow.

Regards,
Simo and  Markus

--=_alternative 006042C7C2257631_=-- From stpeter@stpeter.im Mon Sep 14 10:41:55 2009 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 2366B28C1DC for ; Mon, 14 Sep 2009 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, 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 WxSGSmdyGky0 for ; Mon, 14 Sep 2009 10:41:53 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C94C228C1AB for ; Mon, 14 Sep 2009 10:41:52 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 30DC940D13; Mon, 14 Sep 2009 11:42:37 -0600 (MDT) Message-ID: <4AAE808C.7030306@stpeter.im> Date: Mon, 14 Sep 2009 11:42:36 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" , "Markus.Isomaki@nokia.com" , "Simo.Veikkolainen@nokia.com" Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 14 Sep 2009 17:41:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/11/09 11:41 AM, Henry Sinnreich wrote: > 1. Why stop at SIP and XMPP, and not add other popular IM protocols, > as is already done by quite a few products in the market? Because the IETF is a standards organization and it't not our job to define hackish gateways to things like MySpaceIM? If those people want to use standardized technologies, it's quite easy for them to do so. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqugIwACgkQNL8k5A2w/vzrmwCgyxh7zMm7+QITL7mTWN2rDNrR 0XYAnjlEYS/nfvriT9xWQ5jZ7RYHgJrI =Jzp8 -----END PGP SIGNATURE----- From hsinnrei@adobe.com Mon Sep 14 12:50:12 2009 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 763903A6AAA for ; Mon, 14 Sep 2009 12:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 EyMOw-0LCfGH for ; Mon, 14 Sep 2009 12:50:06 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id 17D9E3A6903 for ; Mon, 14 Sep 2009 12:50:00 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSq6ejO4B5597MfjQwVJ1ByBuXBeYDxpS@postini.com; Mon, 14 Sep 2009 12:50:51 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8EJhiao019752; Mon, 14 Sep 2009 12:43:44 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8EJoZlT021114; Mon, 14 Sep 2009 12:50:35 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 14 Sep 2009 12:50:35 -0700 From: Henry Sinnreich To: Peter Saint-Andre Date: Mon, 14 Sep 2009 12:50:33 -0700 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: Aco1YsLHsK8O+37/Tl+ovWC36mR1nQAEdwCd Message-ID: In-Reply-To: <4AAE808C.7030306@stpeter.im> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6D408B95D1Ahsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" , "Markus.Isomaki@nokia.com" , "Simo.Veikkolainen@nokia.com" Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 14 Sep 2009 19:50:12 -0000 --_000_C6D408B95D1Ahsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 9/14/09 12:42 PM, "Peter Saint-Andre" wrote: >Because the IETF is a standards organization and it't not our job to >define hackish gateways to things like MySpaceIM? It's in the eye of the beholder what is a hack, a successful innovation or = a future standard, de facto or from a standards organization. Presence and = IM started out as proprietary systems long time before standards emerged an= d unless I am mistaken, proprietary Presence and IM are still dominant or a= t least significant in the market. Does anyone have numbers on this? Today's "hack" may be the subject of tomorrow's standards. Henry --_000_C6D408B95D1Ahsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] New topic proposal for DISPATCH On 9/14/09 12:42 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:

>Because the IETF is a standards organiz= ation and it't not our job to
>define hackish gateways to things like MySpaceIM?

It’s in the eye of the beholder what is a hack, a successful innovati= on or a future standard, de facto or from a standards organization. Presenc= e and IM started out as proprietary systems long time before standards emer= ged and unless I am mistaken, proprietary Presence and IM are still dominan= t or at least significant in the market. Does anyone have numbers on this?<= BR>
Today’s “hack” may be the subject of tomorrow’s sta= ndards.

Henry
--_000_C6D408B95D1Ahsinnreiadobecom_-- From spencer@wonderhamster.org Tue Sep 15 05:41:52 2009 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 6CB653A6B0E for ; Tue, 15 Sep 2009 05:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.499, 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 CtHzQxJFK8oZ for ; Tue, 15 Sep 2009 05:41:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 410F43A6A0C for ; Tue, 15 Sep 2009 05:41:51 -0700 (PDT) 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 0MKpCa-1MnXMb2scu-000dHX; Tue, 15 Sep 2009 08:42:37 -0400 Message-ID: <38B61E3C2E94499C8BF075D19D8B38A1@china.huawei.com> From: "Spencer Dawkins" To: "Henry Sinnreich" , "Peter Saint-Andre" References: Date: Tue, 15 Sep 2009 07:42:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D8_01CA35D8.104E3790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX196wCpFUtZBSqaY5HmEdVOTBa52JRbCqCyKNbh hf25tILJ/Wcknx/XYKR/gygJi9E/uqOPO4TyB0MgLPP6l6hX3E FABAKbzfPd8aBk/x4qSUQT1AO5WoJMqXJbVGjLfeL8= Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com, Markus.Isomaki@nokia.com Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 15 Sep 2009 12:41:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01D8_01CA35D8.104E3790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] New topic proposal for DISPATCHHi, Henry, I don't disagree with your note below. I understood Peter's concern to = be that interworking with a proprietary protocol in an SDO is = problematic because the protocol we're interworking with can change at = any time.=20 There were certainly plenty of proprietary e-mail protocols when SMTP = was produced. My understanding (and I wasn't there) was that we defined = interworking with X.400, and encouraged people with proprietary = protocols to develop interworking with either SMTP directly, or with = X.400 (which we knew how to interwork with SMTP. That's what I understood Peter to be proposing. Sorry if I = misunderstand, of course. Spencer ----- Original Message -----=20 From: Henry Sinnreich=20 To: Peter Saint-Andre=20 Cc: dispatch@ietf.org ; gonzalo.camarillo@ericsson.com ; = Markus.Isomaki@nokia.com ; Simo.Veikkolainen@nokia.com=20 Sent: Monday, September 14, 2009 2:50 PM Subject: Re: [dispatch] New topic proposal for DISPATCH On 9/14/09 12:42 PM, "Peter Saint-Andre" wrote: >Because the IETF is a standards organization and it't not our job = to >define hackish gateways to things like MySpaceIM?=20 It's in the eye of the beholder what is a hack, a successful = innovation or a future standard, de facto or from a standards = organization. Presence and IM started out as proprietary systems long = time before standards emerged and unless I am mistaken, proprietary = Presence and IM are still dominant or at least significant in the = market. Does anyone have numbers on this? Today's "hack" may be the subject of tomorrow's standards. Henry -------------------------------------------------------------------------= ----- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_01D8_01CA35D8.104E3790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] New topic proposal for = DISPATCH
Hi, Henry,
 
I don't disagree with your note below. I understood = Peter's=20 concern to be that interworking with a proprietary protocol in an SDO is = problematic because the protocol we're interworking with can change at = any time.=20
 
There were certainly plenty of proprietary e-mail = protocols=20 when SMTP was produced. My understanding (and I wasn't there) was that = we=20 defined interworking with X.400, and encouraged people with proprietary=20 protocols to develop interworking with either SMTP directly, or with = X.400=20 (which we knew how to interwork with SMTP.
 
That's what I understood Peter to be proposing. = Sorry if I=20 misunderstand, of course.
 
Spencer
----- Original Message -----
From:=20 Henry = Sinnreich
Cc: dispatch@ietf.org ; gonzalo.camarillo@ericsson= .com=20 ; Markus.Isomaki@nokia.com = ; Simo.Veikkolainen@nokia.com=20
Sent: Monday, September 14, = 2009 2:50=20 PM
Subject: Re: [dispatch] New = topic=20 proposal for DISPATCH

On 9/14/09 12:42 PM, "Peter Saint-Andre" = <stpeter@stpeter.im>=20 wrote:
>Because the IETF is a standards = organization and=20 it't not our job to
>define hackish gateways to things like = MySpaceIM?=20

It=92s in the eye of the beholder what is a hack, a = successful=20 innovation or a future standard, de facto or from a standards = organization.=20 Presence and IM started out as proprietary systems long time before=20 standards emerged and unless I am mistaken, proprietary Presence and = IM are=20 still dominant or at least significant in the market. Does anyone = have=20 numbers on this?

Today=92s =93hack=94 may be the subject of = tomorrow=92s=20 standards.

Henry

_______________________________________________
dispatch = mailing=20 = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispat= ch
------=_NextPart_000_01D8_01CA35D8.104E3790-- From hsinnrei@adobe.com Tue Sep 15 05:49:20 2009 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 7F42C3A68BF for ; Tue, 15 Sep 2009 05:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.634 X-Spam-Level: X-Spam-Status: No, score=-4.634 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 PNMHsFd0KgIK for ; Tue, 15 Sep 2009 05:49:15 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by core3.amsl.com (Postfix) with ESMTP id 349413A6855 for ; Tue, 15 Sep 2009 05:49:15 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKSq+NdDr98VQwewLuOHqyPk1OqRd9SgbT@postini.com; Tue, 15 Sep 2009 05:50:02 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8FCh2ao005143; Tue, 15 Sep 2009 05:43:04 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8FCnriq018700; Tue, 15 Sep 2009 05:49:53 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 15 Sep 2009 05:49:53 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Tue, 15 Sep 2009 05:49:53 -0700 From: Henry Sinnreich To: Spencer Dawkins , Peter Saint-Andre Date: Tue, 15 Sep 2009 05:49:50 -0700 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: Aco2Agh4WFUpAj33R9qls60FznJctwAAPq4I Message-ID: In-Reply-To: <38B61E3C2E94499C8BF075D19D8B38A1@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6D4F79E5D3Chsinnreiadobecom_" MIME-Version: 1.0 Cc: "Simo.Veikkolainen@nokia.com" , "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" , "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 15 Sep 2009 12:49:20 -0000 --_000_C6D4F79E5D3Chsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Spencer, Our understanding seems to agree. Sure, this is worth a longer discussion, but at some other time and place. Henry On 9/15/09 7:42 AM, "Spencer Dawkins" wrote: Hi, Henry, I don't disagree with your note below. I understood Peter's concern to be t= hat interworking with a proprietary protocol in an SDO is problematic becau= se the protocol we're interworking with can change at any time. There were certainly plenty of proprietary e-mail protocols when SMTP was p= roduced. My understanding (and I wasn't there) was that we defined interwor= king with X.400, and encouraged people with proprietary protocols to develo= p interworking with either SMTP directly, or with X.400 (which we knew how = to interwork with SMTP. That's what I understood Peter to be proposing. Sorry if I misunderstand, o= f course. Spencer ----- Original Message ----- From: Henry Sinnreich To: Peter Saint-Andre Cc: dispatch@ietf.org ; gonzalo.camarillo@ericsson.com ; Markus.Isomaki@no= kia.com ; Simo.Veikkolainen@nokia.com Sent: Monday, September 14, 2009 2:50 PM Subject: Re: [dispatch] New topic proposal for DISPATCH On 9/14/09 12:42 PM, "Peter Saint-Andre" wrote: >Because the IETF is a standards organization and it't not our job to >define hackish gateways to things like MySpaceIM? It's in the eye of the beholder what is a hack, a successful innovation or= a future standard, de facto or from a standards organization. Presence an= d IM started out as proprietary systems long time before standards emerged= and unless I am mistaken, proprietary Presence and IM are still dominant = or at least significant in the market. Does anyone have numbers on this? Today's "hack" may be the subject of tomorrow's standards. Henry ________________________________ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C6D4F79E5D3Chsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] New topic proposal for DISPATCH Spencer,

Our understanding seems to agree.
Sure, this is worth a longer discussion, but at some other time and place.<= BR>
Henry


On 9/15/09 7:42 AM, "Spencer Dawkins" <spencer@wonderhamster.org> wrote:

Hi, Henry,
 
I don't disagree with your note below. I understood Peter's concern to be t= hat interworking with a proprietary protocol in an SDO is problematic becau= se the protocol we're interworking with can change at any time.
 
There were certainly plenty of proprietary e-mail protocols when SMTP was p= roduced. My understanding (and I wasn't there) was that we defined interwor= king with X.400, and encouraged people with proprietary protocols to develo= p interworking with either SMTP directly, or with X.400 (which we knew how = to interwork with SMTP.
 
That's what I understood Peter to be proposing. Sorry if I misunderstand, o= f course.
 
Spencer

----- Original Message -----
 
From:  Henry  Sinnreich <mailto:hsinnrei@adobe.com>  
 
To: Peter Saint-Andre <mail= to:stpeter@stpeter.im>  
 
Cc: dispatch@ietf.org ; gonzalo.camarillo@ericsson.com  ;= Markus.Isomaki@nokia.com ; Simo.Veikkolainen@nokia.com    
Sent: Monday, September 14, 2009 2:50  PM
 
Subject: Re: [dispatch] New topic  proposal for DISPATCH
 

On 9/14/09 12:42 PM, "Peter Saint-Andre" <stpeter@stpeter.im>  wrote:

 
>Because the IETF is a standards organiz= ation and  it't not our job to
>define hackish gateways to things like MySpaceIM?  

It’s in the eye of the beholder what is a hack, a successful  in= novation or a future standard, de facto or from a standards organization. &= nbsp;Presence and IM started out as proprietary systems long time before &n= bsp;standards emerged and unless I am mistaken, proprietary Presence and IM= are  still dominant or at least significant in the market. Does anyon= e have  numbers on this?

Today’s “hack” may be the subject of tomorrow’s &nb= sp;standards.

Henry


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

--_000_C6D4F79E5D3Chsinnreiadobecom_-- From mdolly@att.com Tue Sep 15 19:18:18 2009 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 73A903A6B69 for ; Tue, 15 Sep 2009 19:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 q-6t019QTqwD for ; Tue, 15 Sep 2009 19:18:17 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 924D93A6883 for ; Tue, 15 Sep 2009 19:18:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-146.messagelabs.com!1253067544!4093580!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 1223 invoked from network); 16 Sep 2009 02:19:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2009 02:19:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8G2J48W015716 for ; Tue, 15 Sep 2009 22:19:04 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8G2Ixr2015693 for ; Tue, 15 Sep 2009 22:19:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 15 Sep 2009 22:18:57 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0444833E@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <234AB975CD8EF04DAD28A520054E5F6CAABE29A5@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OMA- Push draft Thread-Index: AcoFe0EnQSQc9CKFRGGN/LiEtWtTiADwhZtwC02ITCA= References: <234AB975CD8EF04DAD28A520054E5F6CAABE29A5@gaalpa1msgusr7e.ugd.att.com> From: "DOLLY, MARTIN C, ATTLABS" To: "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , , "Adam Roach" , "Robert Sparks" , Cc: Kent Bogestam , "SULLIVAN, BRYAN L, ATTCINW" Subject: [dispatch] OMA- Push 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: Wed, 16 Sep 2009 02:18:18 -0000 R3JlZXRpbmdzLA0KDQpMaW5rIHRvIHRoZSBPTUEtUFVTSCBkcmFmdCBmb3IgaW5kaXZpZHVhbCBz dWJtaXNzaW9uOg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZG9sbHktZGlz cGF0Y2gtb21hLXB1c2gtMDAgDQoNCldlIHdvdWxkIGFwcHJlY2lhdGUgcmV2aWV3IGFuZCBjb21t ZW50cy4gT3VyIGludGVudGlvbiBpcyBmb3IgYW4gaW5kaXZpZHVhbCBJRCBmb3IgYSBwdWJsaXNo ZWQgU0lQIEV2ZW50IHBhY2thZ2UgaW4gc3VwcG9ydCBvZiBPTUEtUFVTSC4NCg0KVGhhbmsgeW91 LA0KDQpNYXJ0aW4NCg0K From gonzalo.camarillo@ericsson.com Wed Sep 16 07:12:09 2009 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 0A78728C0E4 for ; Wed, 16 Sep 2009 07:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.346 X-Spam-Level: X-Spam-Status: No, score=-5.346 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, HELO_EQ_SE=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 IIfFjdpVebTh for ; Wed, 16 Sep 2009 07:12:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E012E3A6950 for ; Wed, 16 Sep 2009 07:12:07 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2cae000005a8f-80-4ab0f267115c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 9C.85.23183.762F0BA4; Wed, 16 Sep 2009 16:12:56 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 16:12:55 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 16:12:55 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 58CAB251F; Wed, 16 Sep 2009 17:12:55 +0300 (EEST) Message-ID: <4AB0F267.8050903@ericsson.com> Date: Wed, 16 Sep 2009 17:12:55 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2009 14:12:55.0435 (UTC) FILETIME=[C92A6DB0:01CA36D7] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Cutoff for charter proposals on Monday 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, 16 Sep 2009 14:12:09 -0000 Folks, this is a reminder of our cutoff for charter proposals, which is on Monday (September 21st). Per our previous email: "A charter proposal must consist of a minimum of a problem statement and at least one milestone/deliverable. This deadline will allow time for consideration of proposals that could potentially be "dispatched" prior to the WG session." A few of the topics we received arrived after the previous deadline, which was September 7th. We will be considering even those topics that arrived a bit late because we realize the deadline was quite tough to meet (specially for people that returned from their vacation right before the deadline). We are expecting charter proposals for: o Third-party authorization o CBUS o Session recording o Identity o Disaggregated media o Domain registrations in SIP o SIP - XMPP o Alert-info URNs o Reference to an earlier communication Let the chairs know if there are topics missing from this list. Thanks, Gonzalo DISPATCH co-chair From victor.pascual.avila@gmail.com Fri Sep 18 10:13:02 2009 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 5AF0228C1CB for ; Fri, 18 Sep 2009 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 ZJVzGGh52quN for ; Fri, 18 Sep 2009 10:13:01 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 45E083A683A for ; Fri, 18 Sep 2009 10:13:01 -0700 (PDT) Received: by ewy3 with SMTP id 3so764694ewy.42 for ; Fri, 18 Sep 2009 10:13:52 -0700 (PDT) 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=Kc8m75psIPrm3gOYQ1QcRLkzhpMkJdNGzDm35DVc6cc=; b=tbbN41wSm9ViUaRW5GaYhy1G4Pfjc6rhNbb4hhVaXG/6p/60ANDxApgm72tdHAx6Ox 6kgoKyavHyB0fB9B+b41Qjo/rfSAX40ocSwqhDxrOKl8usMI/DA1WB+AnDtCcoo8Fq6x WajcoecvXIu5fkZDv5E4H/YLLZ0YLIx0MHdTc= 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=njXIu1W6utZVDwtqLbmu39KF1wbuX86tAzR4IDUhhNcl3h1NGWWK0LAec0our0T26D qZFk1TrYq4wOD2AMX1ReL5LZ0/MmxMJ5pGDIpHbrXEiiE57oUzOvpVz8JqgtRr6FJsoN JQCOzcM7DSkXj/vGF75EpIO4Us86sMZpUpeDE= MIME-Version: 1.0 Received: by 10.216.52.81 with SMTP id d59mr518825wec.205.1253294031493; Fri, 18 Sep 2009 10:13:51 -0700 (PDT) In-Reply-To: <4AB0F267.8050903@ericsson.com> References: <4AB0F267.8050903@ericsson.com> Date: Fri, 18 Sep 2009 19:13:51 +0200 Message-ID: <618e24240909181013q3c96ae69udc2c84c25f908ca1@mail.gmail.com> From: Victor Pascual Avila To: Gonzalo Camarillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Cutoff for charter proposals on Monday 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: Fri, 18 Sep 2009 17:13:02 -0000 Gonzalo, On Wed, Sep 16, 2009 at 4:12 PM, Gonzalo Camarillo wrote: > Folks, > > this is a reminder of our cutoff for charter proposals, which is on Monda= y > (September 21st). Per our previous email: "A charter proposal must consis= t > of a minimum of a problem statement and at least one milestone/deliverabl= e. > This deadline will allow time for consideration of proposals that could > potentially be "dispatched" prior to the WG session." > > A few of the topics we received arrived after the previous deadline, whic= h > was September 7th. We will be considering even those topics that arrived = a > bit late because we realize the deadline was quite tough to meet (special= ly > for people that returned from their vacation right before the deadline). > > We are expecting charter proposals for: > > o Third-party authorization > o CBUS > o Session recording > o Identity As John mentioned, we don't believe we are in a position yet to propose a charter. However, we hope to update http://tools.ietf.org/id/draft-elwell-dispatch-identity-reqs-00.txt before the meeting. Cheers, -Victor > o Disaggregated media > o Domain registrations in SIP > o SIP - XMPP > o Alert-info URNs > o Reference to an earlier communication > > Let the chairs know if there are topics missing from this list. > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Victor Pascual =C3=81vila From dwing@cisco.com Sun Sep 20 20:19:11 2009 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 088D43A6857 for ; Sun, 20 Sep 2009 20:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.233 X-Spam-Level: X-Spam-Status: No, score=-4.233 tagged_above=-999 required=5 tests=[AWL=-2.178, BAYES_05=-1.11, FRT_ADOBE2=2.455, J_CHICKENPOX_34=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 zwqP6YmBNN1j for ; Sun, 20 Sep 2009 20:19:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3A5993A6836 for ; Sun, 20 Sep 2009 20:19:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEADeOtkqrR7MV/2dsb2JhbACKba0piFABjWgFgjOBaA X-IronPort-AV: E=Sophos;i="4.44,422,1249257600"; d="scan'208";a="244391244" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 21 Sep 2009 03:20:09 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8L3K9sm032658; Sun, 20 Sep 2009 20:20:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8L3K9kq027521; Mon, 21 Sep 2009 03:20:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Sep 2009 20:20:09 -0700 Received: from dwingwxp01 ([10.32.240.194]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Sep 2009 20:20:08 -0700 From: "Dan Wing" To: "'Paul Kyzivat'" , "'Henry Sinnreich'" References: <4AAAAB49.8020206@cisco.com> Date: Sun, 20 Sep 2009 20:20:08 -0700 Message-ID: <030901ca3a6a$6bf5b690$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4AAAAB49.8020206@cisco.com> Thread-Index: AcozGfDDZEpu/TONTlGGI3+sS5A8hgHUBuWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 21 Sep 2009 03:20:08.0735 (UTC) FILETIME=[6C0F0AF0:01CA3A6A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15789; t=1253503209; x=1254367209; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[dispatch]=20New=20topic=20proposal=20f or=20DISPATCH |Sender:=20; bh=fDkHkXh2bN06oubxOLeNWHYTaYj2l7d+01SQxmtkHaI=; b=mZaY+uCsBSr7WtduwfYOqx2/4iagLPXOWN2if7NF0+wkgYjcWmS7Qbk+vT QbbAcxVEOfMT/SlZMcFzcz6Z5mxFqbJ4OA6Sw2mnxv/wVcN3OivAIpek7sv7 NXOUWNaToE50RM6JXJsYWtrqEbWZJ8A4s0UbyN5aG5dpq0Tw+d19g=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com, Markus.Isomaki@nokia.com Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 21 Sep 2009 03:19:11 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, September 11, 2009 12:56 PM > To: Henry Sinnreich > Cc: dispatch@ietf.org; avshalom@il.ibm.com; > gonzalo.camarillo@ericsson.com; Markus.Isomaki@nokia.com; > Simo.Veikkolainen@nokia.com > Subject: Re: [dispatch] New topic proposal for DISPATCH > > I agree that there are pragmatic reasons to pursue the > coordination/coexistence of sip and xmpp. And pushing > responsibility to > the endpoints remains desirable. > > One thing that remains of concern to me in such work is that > we end up > with disjoint address spaces without any straightforward way to > correlate them. So if I want a single "session" involving > both voice via > SIP and IM via xmpp, then I have great difficulty in discovering URIs > for the "subordinate" session that correlate with those for the > "primary" session. (No pejorative intended here - one or the > other must go first.) So XMPP has to use E.164's (like SIP deployments do), or SIP will have to switch to user@host. I don't forsee either happening. If this is deemed necessary then we will have to map between them -- somehow. Send an XMPP message asking "what is your phone number" (in a computer-parsable manner), perhaps? -d > Somehow this problem needs to be resolved. > > Thanks, > Paul > > Henry Sinnreich wrote: > > Hi Markus, > > > > Thanks for your thoughtful reply and I agree there are some > scenarios > > where it makes sense. > > More important, doing this in the endpoints is the right > approach IMO > > and as you know, I will always defend the Internet > end-to-end principle :-) > > > > This distributed approach is also IMO a good answer to the > Interdomain > > Scaling problem for IM > > ( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I > have copied > > one of its authors here. > > > > This raises the questions: > > > > 1. Why stop at SIP and XMPP, and not add other popular > IM protocols, > > as is already done by quite a few products in the market? > > 2. Can your approach be generalized in a more generic way? > > > > > > If endpoints are accommodating several IM protocols, an > IETF, Dispatch > > recommended GENERIC approach would make many people feel more > > comfortable about it. Your I-D could be used as a tested > example for a > > generic approach. > > > > Ranting on preferring endpoint applications to more > application protocols > > > > I still believe creative application developers face the choice of > > either inventing new applications or dedicating their time > to learning > > application protocols and they cannot do both. Learning and > following > > both SIP and XMPP to write and update code is quite a challenge. > > Is there a better way? > > For this reason, one single application protocol for IM and > voice is enough. > > Proof: Almost all the applications that make people buy > smart phones, > > use online office apps and enterprise apps run on HTTP(S) and their > > application developers don't have to worry about knowing > how HTTP works. > > As a result, HTTP has been also used to even carry > streaming media, web > > conferencing and IM. Just to avoid spending a lifetime to learn and > > follow application protocols. But HTTP based apps dominate the > > application space. This is however for another discussion elsewhere. > > > > My strictly personal 2 cents. > > > > Thanks again, > > > > Henry > > > > > > On 9/11/09 8:11 AM, "Markus.Isomaki@nokia.com" > > wrote: > > > > Hi Henry, > > > > Thanks for your feedback :) Let me answer to the > excellent points > > you raise. > > > > First of all, I would encourage you and everyone to > carefully read > > the Introduction chapter of the draft > > > (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 > > > > > ) to be clear on what the proposal is about. That is, we are not > > trying to boil the ocean and define all possible ways > how SIP and > > XMPP infrastructures could be combined, but instead try > to define a > > minimalistic approach whereby a client can use both SIP > and XMPP in > > an integrated manner WITHOUT requiring ANY changes on > the servers > > that are already deployed. > > > > See further comments below with [Markus]: > > > > > > > > > -------------------------------------------------------------- > ---------- > > *From:* ext Henry Sinnreich [mailto:hsinnrei@adobe.com] > > *Sent:* 04 September, 2009 18:42 > > *To:* Veikkolainen Simo (Nokia-D/Helsinki); > dispatch@ietf.org; > > mary.barnes@nortel.com; gonzalo.camarillo@ericsson.com > > *Cc:* Isomaki Markus (Nokia-CIC/Espoo); Olle E. Johansson > > *Subject:* Re: [dispatch] New topic proposal for DISPATCH > > > > > > I would like to second such work, but a far deeper > look under > > the hood is necessary, so we don't do another > Elbonia project. > > http://dilbert.com/strips/comic/2009-09-01/ > > > > Here are some not very mature thoughts on the > scope of the work. > > The most interesting, ROI estimate and REST architecture > > support are at the end. > > > > Servers > > > > Fundamentally, we need a registrar, a proxy and a presence > > server: Three in total > > > > * What will be the duplication of servers and where > > specifically? > > * How does the SIP registrar communicate with the XMPP > > server(s)? > > * What may be the routing protocol(s) inside a SIP+XMMP > > network? Think of IMS as a stressing use case. > > > > > > [Markus] Our starting point is that we already have > quite many > > SIP VoIP deployments out there, as long as quite many XMPP > > presence & IM deployments. So, the servers you > mention already > > exist. If one now wants to develop a client that > does VoIP, IM > > and presence together, it should be possible to > utilize these > > existing infrastrcutures and not have to wait for > new ones to > > be deployed (as for instance we have waited quite > many years for > > SIMPLE-based Presence servers to get deployed but > compared to > > XMPP there's very little in use). The idea is to define a > > couple of E2E (as in nothing that SIP proxies or > XMPP servers > > would have to support) protocol extensions which > would allow > > the client to nicely combine SIP VoIP and XMPP > presence & IM. > > > > > > > > There is no need for SIP and XMPP servers to know > about each > > other or route protocol messages between each other. All the > > logic is put into the endpoints. No need to worry about IMS > > either, except that in theory the client can use > IMS for its > > VoIP service (similar to any other SIP infra). > > > > > > User Agents > > > > * Same as with servers: How many and what > protocol RFCs are > > there in the combination? > > * Which of the "services" can be placed in the > applications > > in the endpoints or in the network > application protocols, > > such as SIP and XMPP. This is the topic on > infrastructure > > vs. endpoint applications. > > > > > > [Markus] Just take any current SIP VoIP UA > implementation, XMPP > > client implementation and glue them together and > you're already > > pretty far. Add a couple of extensions as proposed and it's > > done. From there onwards you have a pretty > powerful machinery > > to add applications by using SIP session setup and > XMPP message > > delivery capabilities. > > > > > > Application Protocol Stacks > > > > * How many protocol stacks does this involve > and more to > > the point, how many RFCs? > > * For SIP alone, see http://rfc3261.net/. What > will be the > > total combined RFC count? > > > > > > [Markus] All what we expect is already pretty > widely supported > > and even available as open source: basic SIP VoIP > and XMPP IM > > and presence is enough to start with. > > > > > > NAT Traversal > > > > * Will STUN/TURN/ICE work the same for SIP and > for XMPP? > > > > > > [Markus] In our proposal SIP would be used for > setting up voice > > & video sessions. So, you would need NAT traversal > for that. How > > that's done is outside the scope but either B2BUA > or ICE based > > mechanisms would work as far as they work in > general. For XMPP > > we would not need to worry about NAT traversal > beyond how its > > done in that protocol by default. For a client there is a > > caveat that it has to keepalive the TCP connections > with BOTH > > SIP and XMPP servers so it would be recommended to > synchronize > > those (send them at the same time) for instance in > a battery > > powered device. > > > > > > Return on Investment (ROI): Cost and effort by > developers. More > > network infrastructure, not even counting B2B NEs. > > > > * What is the additional time/money required > for developers > > that know SIP to also learn XMPP and vice > versa? This is > > all about return on investment. > > > > > > [Markus] This is a problem for sure, even more so for the > > people writing standard specs than code :) Hopefully the > > developer would just have add a couple of simple > extensions to > > existing SIP and XMPP implementations. > > > > > > Support for a REST-full architecture > > > > The WWW has a REST architecture was formulated in > 2000, after > > the emergence of SIP and XMMP. As a result of its > architecture, > > the WWW has had a transformational effect on the following > > (this is not a complete list). Some SIP work > recommends already > > recommends REST, such as in RFC 4240 and in > > http://tools.ietf.org/html/draft-griffin-bliss-rest-00 > > > > * Web applications from mail to office apps > > * Internet applications previously served by dedicated > > network applications protocols > > * Many other industries, from banking to newsprint to > > travel. And Oh, social networks, they also have > > registrars... > > > > > > > > Now please keep in mind the WWW architecture uses basically > > only 3 components*: The URI for addressing, HTTP > for transport > > and HTML for data rendering, augmented by some > other languages > > (XML) and namespaces. Can we benefit something from the WWW > > architecture? If yes what specifically? > > > > Heresy: If the web developers could use HTTP only, > what other > > application level protocols do we really need > except RTP/UDP? > > This includes in my mind TLS and DTLS for secure > transport or > > even better IMO: HIP for many reasons. > > > > > > [Markus] Personally I agree that REST+HTTP+Javascript is a > > superior toolset compared to SIP, XMPP, IMAP and so on to > > develop many applications. However, there are > still plenty of > > SIP based VoIP and XMPP based IM and presence > deployments out > > there and I don't expect the web apps to replace > all of them in > > the near future :) > > > > > > * T.V. Raman: "Toward 2W, Beyond Web 2.0", > Communications of > > the ACM, February 2009 > > > > Many or most of these points may be moot or make > no sense, but > > maybe should be cleared up, in case there are more > naive people > > like me that may be interested. > > > > My strict personal 2 cents. > > > > FRANK comments are most welcome. > > > > Henry > > > > > > > > On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" > > wrote: > > > > > > > > Hi, > > > > We would like to propose a new DISPATCH topic > on how SIP > > and XMPP can be used together in a > complementary fashion. > > > > We have been working on a solution which > combines SIP based > > VoIP and XMPP based IM and Presence. The > requirements and a > > proposed solution is outlined in > > > _http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01_ > > > > > . > > > > The motivation for this work comes from experience which > > shows that most standards based VoIP > deployments use SIP. > > At the same time, the Extensible Messaging and Presence > > Protocol (XMPP) is widely used in instant messaging and > > presence services. An interesting scenario > arises when a > > SIP based voice (and video) service is combined together > > with an XMPP based instant messaging and > presence service. > > > > Note that the goal in this work is not > SIP-XMPP protocol > > translation, but to define protocol extensions and best > > practises such that SIP based VoIP and XMPP > based IM and > > presence could be seamlessly combined and > offered to the end > > user. For rapid deployment, we assume no changes in the > > server infrastructure, and instead impose new > requirements > > and protocol extensions only to the endpoints. > > > > We would like to get some discussion going on > the use case > > itself as well as on the solution. Also, we > would like to > > hear you thoughts on DISPATCH or a new > "dispatched" mini-WG > > as the home for such work. > > > > Exact charter proposal and problem statemen is > to follow. > > > > Regards, > > Simo and Markus > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > 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 MILANPA@nortel.com Mon Sep 21 02:34:14 2009 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 A8F193A6A4D for ; Mon, 21 Sep 2009 02:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 gFWfH+9m6qpa for ; Mon, 21 Sep 2009 02:34:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5B72E3A69ED for ; Mon, 21 Sep 2009 02:34:13 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8L9Z8X24275; Mon, 21 Sep 2009 09:35:08 GMT 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, 21 Sep 2009 10:35:04 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E900AD34F4B@zharhxm1.corp.nortel.com> In-Reply-To: <4AB0F267.8050903@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Cutoff for charter proposals on Monday Thread-Index: Aco2183+F4+NRlXDQ3acsebFeOf6DQDxXh0w References: <4AB0F267.8050903@ericsson.com> From: "Milan Patel" To: "Gonzalo Camarillo" , "DISPATCH" Subject: Re: [dispatch] Cutoff for charter proposals on Monday 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, 21 Sep 2009 09:34:14 -0000 Hi, I would like to add an additional topic to the DISPATCH charter - URI parameters to describe the calling party category and toll class. Previously, Calling Party Category (CPC) URI parameter was defined in a draft by Rohan Mahy in the IPTEL group.=20 There is still a need by carriers for this parameter and it is currently also used within TISPAN and 3GPP.=20 The motivation for defining the CPC URI parameter is to provide a standardized method of providing information about the calling party and the station used to originate a call. Currently, a number of proprietary solutions are being used as a standardized solution is unavailable.=20 My intention is to revise Rohan's draft: http://tools.ietf.org/html/draft-mahy-iptel-cpc-06 And to take on board some of the comments received on the old IPTEL list.=20 My proposal is to provide a draft that defines 2 URI parameters: "cpc" and "oli" indicating the category and tolls class of the calling party, allowing mapping to parameters used in ISUP. Best regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: 16 September 2009 15:13 To: DISPATCH Subject: [dispatch] Cutoff for charter proposals on Monday Folks, this is a reminder of our cutoff for charter proposals, which is on=20 Monday (September 21st). Per our previous email: "A charter proposal=20 must consist of a minimum of a problem statement and at least one=20 milestone/deliverable. This deadline will allow time for consideration=20 of proposals that could potentially be "dispatched" prior to the WG=20 session." A few of the topics we received arrived after the previous deadline,=20 which was September 7th. We will be considering even those topics that=20 arrived a bit late because we realize the deadline was quite tough to=20 meet (specially for people that returned from their vacation right=20 before the deadline). We are expecting charter proposals for: o Third-party authorization o CBUS o Session recording o Identity o Disaggregated media o Domain registrations in SIP o SIP - XMPP o Alert-info URNs o Reference to an earlier communication Let the chairs know if there are topics missing from this list. Thanks, Gonzalo DISPATCH co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From salvatore.loreto@ericsson.com Mon Sep 21 03:50:59 2009 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 5D8153A6849 for ; Mon, 21 Sep 2009 03:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HELO_EQ_SE=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 pdf1nWn1Ev4o for ; Mon, 21 Sep 2009 03:50:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 998923A6881 for ; Mon, 21 Sep 2009 03:50:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-5d-4ab75acaf571 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BD.05.15624.ACA57BA4; Mon, 21 Sep 2009 12:51:54 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 12:51:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 12:51:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5225F25AA; Mon, 21 Sep 2009 13:51:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1E52121A17; Mon, 21 Sep 2009 13:51:53 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1A8DB219CB; Mon, 21 Sep 2009 13:51:51 +0300 (EEST) Message-ID: <4AB75AC7.6080509@ericsson.com> Date: Mon, 21 Sep 2009 13:51:51 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: IETF Dispatch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 21 Sep 2009 10:51:53.0511 (UTC) FILETIME=[87C3A370:01CA3AA9] X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: [dispatch] Charter Proposal for Disaggregated Media 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, 21 Sep 2009 10:50:59 -0000 Hi there, below is a charter proposal for a WG on Disaggregated Media. All comments, thoughts, feedbacks are very welcome! cheers Sal Disaggregated Media WG Charter ------------------------------- Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the media session. The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate the different devices under his control to involve them in the call. The different devices can communicate with one another using Mbus messages, and then let only one device, a call control engine, to initiate, manage and terminate call control relations to other SIP endpoints. All the different user's devices need to support the Mbus protocol. The Megaco [RFC3525] protocol can be used in a disaggregated media scenario to let one of the user's devices act as a Media Gateway Controller, coordinating all the other devices under the user's control, which in this case will act as Media Gateways. In this case all the different user's devices need to support the Megaco protocol. The SIP protocol provides 3pcc [RFC3725] as a possible mechanism to coordinate the exchange of media streams coming from different devices under the control of the same user, in the case at least one among the different devices under his control supports this mechanism and is able to become a Controller for the other in the call. All the existing mechanisms only cover a subset of the interesting scenarios that involve disaggregated media. Scenarios not covered by existing mechanisms include the loosely-coupled one where none of the nodes can act as a controller because it does not support the necessary functionality or because it will not participate in the whole session. The objective of the proposed working group is to develop a framework for Disaggregated Media that include both improvements on existing mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms like a loosely coupled mechanism that does not require the implementation of complex logic on any of the terminals. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key design considerations for Disaggregated mediamechanism. 2. A specification for a loosely couple mechanism. 3. One or more specifications to improve existing mechanism to coordinate disaggregated media. From christer.holmberg@ericsson.com Mon Sep 21 04:24:48 2009 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 A5DA73A6A7E for ; Mon, 21 Sep 2009 04:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ArbotTwspzRc for ; Mon, 21 Sep 2009 04:24:47 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 594F83A6A7D for ; Mon, 21 Sep 2009 04:24:43 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-d8-4ab762b45619 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B8.EC.22406.4B267BA4; Mon, 21 Sep 2009 13:25:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 13:24:45 +0200 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_01CA3AAE.1E3CA378" Date: Mon, 21 Sep 2009 13:24:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter proposed: CBUS Thread-Index: Aco6rh5qjal3WoCFQ0GOm+Aj+HKUWg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 21 Sep 2009 11:24:45.0099 (UTC) FILETIME=[1EEC17B0:01CA3AAE] X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: [dispatch] Charter proposed: CBUS 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, 21 Sep 2009 11:24:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3AAE.1E3CA378 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is the proposed charter for CBUS. Regards, Christer ----------------------------------------- CBUS Charter. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Introduction: ------------- Various OMA service enablers need to be able to retrieve a list of addresses (URIs), where the users associated with the URIs fulfil certain conditions. User information is evaluated against the conditions, and the matches form a URI list. The need for the functionality originates from the OMA PoC service. However, there is ongoing work in OMA to define a common mechanism, called CBUS enabler (OMA-RD-CBUS-V1_0-20090203-C), to provide the functionality, so that it can be used for various types of services (e.g. messaging, gaming, conferencing and advertisement). The CBUS enabler provides the following functions: - Support for requestor initiated condition-based URIs selection requests. - Administration of conditions for URI selection. - Interaction with other enablers for retrieval of individual user's information (e.g. presence information, location information). - Evaluation of conditions and selection of matching individual users based on one time evaluation. - Re-evaluation of conditions and re-selection of matching individual users based on monitoring. - Aggregation of one-time evaluation results and monitoring results from different information sources. - Notification of evaluation results to requestor. The conditions can be based on user information which changes over time (e.g. presence information or geographical location), but they can also be based on more static user information (e.g. hobbies or personal interests). The entity which acts as requester, and provides the conditions to be used for the user information evaluation, is called CBUS client. The CBUS client usually resides on the user equipment, or an application server, which supports the CBUS enabler. The selection of URIs, based on the provided conditions, may be performed by taking a snapshot, i.e. by making a one-time evaluation of the user information to find out whether the conditions are fulfilled or not. The URI selection may also be performed by continous monitoring of the user information. Work and deliverables: ---------------------- The purpose of the work is to, based on the OMA CBUS requirements (OMA- RD-CBUS-V1_0-20090203-C), procude the SIP protocol information elements which are needed to implement the interface between the CBUS client and CBUS server, using the SIP SUBSCRIBE/NOTIFY framework (RFC 3265). The primary task for the work is to: 1. Procude a mechanism for a subscriber (CBUS client) to, when subscribing to an event package which contains a list of URI, provide conditions, candidate URIs and evaluation parameters to the notifier (CBUS server).=20 The mechanism may be used on defining an XML based message body type, and SIP header field parameters. 2. Produce an event package, or possible re-use an existing event package, used to the notifier (CBUS server) to send URI lists (based on the conditions and candidate URIs) to the subscriber (CBUS client). The CBUS client actions triggered by the received URI list, and the interactions between the CBUS server and other enablers, are outside the scope of the work. The work is planned to take place in, or in co-operaton with, the SIPCORE WG. Goals and milestones: --------------------- Jan 2010 Working Group Last Call for the document which contains the mechanism for a subscriber to provide the needed CBUS information to the notifier, and contains the event package (if a new package is needed) for the=20 notifier to provide the URI list to the subscriber. Mar 2010 Submit document to IESG as Proposed Standard ------_=_NextPart_001_01CA3AAE.1E3CA378 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charter proposed: CBUS

Hi,

Below is the proposed charter for = CBUS.

Regards,

Christer

-----------------------------------------

CBUS Charter.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Introduction:
-------------

Various OMA service enablers need = to be able to retrieve a list of addresses (URIs), where the users = associated with the URIs fulfil certain conditions.  User = information is evaluated against the conditions, and the matches form a = URI list.

The need for the functionality = originates from the OMA PoC service.
However, there is ongoing work = in OMA to define a common mechanism, called CBUS enabler = (OMA-RD-CBUS-V1_0-20090203-C), to provide the functionality, so that it = can be used for various types of services (e.g. messaging, gaming, = conferencing and advertisement).

The CBUS enabler provides the = following functions:

- Support for requestor initiated = condition-based URIs selection requests.

- Administration of conditions = for URI selection.

- Interaction with other enablers = for retrieval of individual user's
  information (e.g. = presence information, location information).

- Evaluation of conditions and = selection of matching individual users
  based on one time = evaluation.

- Re-evaluation of conditions and = re-selection of matching individual
  users based on = monitoring.

- Aggregation of one-time = evaluation results and monitoring results
  from different = information sources.

- Notification of evaluation = results to requestor.

The conditions can be based on = user information which changes over time (e.g. presence information or = geographical location), but they can also be based on more static user = information (e.g. hobbies or personal interests).

The entity which acts as = requester, and provides the conditions to be used for the user = information evaluation, is called CBUS client.  The CBUS client = usually resides on the user equipment, or an application server, which = supports the CBUS enabler.

The selection of URIs, based on = the provided conditions, may be performed by taking a snapshot, i.e. by = making a one-time evaluation of the user information to find out whether = the conditions are fulfilled or not.  The URI selection may also be = performed by continous monitoring of the user information.


Work and deliverables:
----------------------

The purpose of the work is to, = based on the OMA CBUS requirements (OMA- RD-CBUS-V1_0-20090203-C), = procude the SIP protocol information elements which are needed to = implement the interface between the CBUS client and CBUS server, using = the SIP SUBSCRIBE/NOTIFY framework (RFC 3265).


The primary task for the work is = to:

1. Procude a mechanism for a = subscriber (CBUS client) to, when subscribing to an event package which = contains a list of URI, provide conditions, candidate URIs and = evaluation parameters to the notifier (CBUS server).

The mechanism may be used on = defining an XML based message body type, and SIP header field = parameters.

2. Produce an event package, or = possible re-use an existing event package, used to the notifier (CBUS = server) to send URI lists (based on the conditions and candidate URIs) = to the subscriber (CBUS client).

The CBUS client actions triggered = by the received URI list, and the interactions between the CBUS server = and other enablers, are outside the scope of the work.


The work is planned to take place = in, or in co-operaton with, the SIPCORE WG.


Goals and milestones:
---------------------

Jan = 2010        Working Group Last Call = for the document which contains the mechanism for a
            = subscriber to provide the needed CBUS information to the notifier, = and
            = contains the event package (if a new package is needed) for the
            = notifier to provide the URI list to the subscriber.

Mar 2010    Submit = document to IESG as Proposed Standard








------_=_NextPart_001_01CA3AAE.1E3CA378-- From Markus.Isomaki@nokia.com Mon Sep 21 04:42:27 2009 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 A47C13A69A3 for ; Mon, 21 Sep 2009 04:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.764, 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 R9FchrCyGita for ; Mon, 21 Sep 2009 04:42:26 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 627DC3A6784 for ; Mon, 21 Sep 2009 04:42:26 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8LBflZK027905; Mon, 21 Sep 2009 06:42:33 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 14:43:16 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 14:43:09 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 21 Sep 2009 13:43:09 +0200 From: To: , , Date: Mon, 21 Sep 2009 13:43:07 +0200 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: AcozGfDDZEpu/TONTlGGI3+sS5A8hgHUBuWgABE517A= Message-ID: References: <4AAAAB49.8020206@cisco.com> <030901ca3a6a$6bf5b690$c6f0200a@cisco.com> In-Reply-To: <030901ca3a6a$6bf5b690$c6f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Sep 2009 11:43:09.0661 (UTC) FILETIME=[B14AE0D0:01CA3AB0] X-Nokia-AV: Clean Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 21 Sep 2009 11:42:27 -0000 Hi Dan,=20 Dan Wing wrote: > >Paul Kyzivat wrote: >>=20 >> I agree that there are pragmatic reasons to pursue the=20 >> coordination/coexistence of sip and xmpp. And pushing responsibility=20 >> to the endpoints remains desirable. >>=20 >> One thing that remains of concern to me in such work is that=20 >we end up=20 >> with disjoint address spaces without any straightforward way to=20 >> correlate them. So if I want a single "session" involving both voice=20 >> via SIP and IM via xmpp, then I have great difficulty in discovering=20 >> URIs for the "subordinate" session that correlate with those for the=20 >> "primary" session. (No pejorative intended here - one or the other=20 >> must go first.) > >So XMPP has to use E.164's (like SIP deployments do), or SIP=20 >will have to switch to user@host. I don't forsee either happening. =20 >If this is deemed necessary then we will have to map between them >-- somehow. Send an XMPP message asking "what is your phone=20 >number" (in a computer-parsable manner), perhaps? > >-d > I agree. It will be imposible to require a direct or algorithmic mapping be= tween a SIP URI (in practice most cases a E.164 number as you point out) an= d a corresponding XMPP URI. However, if a user knows one of them for anothe= r user, it should be possible to discover the other. In our draft (http://t= ools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01) we propose a few= requirements and solution possibilities. It should be possible to discover= "permanent" URIs (SIP AoR, XMPP JID) as well as dynamic ones that only hav= e meaning in a given context: for instance, if I'm having an IM chat with y= ou with XMPP, I should be able to tell you a SIP URI you can send INVITE to= if you want to add a voice call specifically to that conversation context.= It should be enough to understand the semantics of these URIs in the endpo= ints only, i.e. the infrastructure should not need to know anything about t= hem beyond "routing". In SIP we could utilize GRUUs if they were available = (in practice we can't rely on them however), in XMPP we already have the fu= ll JIDs (xmpp:user@domain/resource) at our disposal. Markus From Simo.Veikkolainen@nokia.com Mon Sep 21 05:27:53 2009 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 10E5F28C13A for ; Mon, 21 Sep 2009 05:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 PfmVrFezN4gU for ; Mon, 21 Sep 2009 05:27:52 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E594D28C13F for ; Mon, 21 Sep 2009 05:27:51 -0700 (PDT) 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 n8LCSdNL020493 for ; Mon, 21 Sep 2009 15:28:43 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 15:28:50 +0300 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); Mon, 21 Sep 2009 15:28:44 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 21 Sep 2009 14:28:44 +0200 From: To: Date: Mon, 21 Sep 2009 14:28:43 +0200 Thread-Topic: Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco6tw6oxGz5jEN/RkOzR8EDleQxZw== Message-ID: 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-OriginalArrivalTime: 21 Sep 2009 12:28:44.0734 (UTC) FILETIME=[0F85E5E0:01CA3AB7] X-Nokia-AV: Clean Subject: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 21 Sep 2009 12:27:53 -0000 Hello, Below is the draft charter text for our proposal on combining SIP voice wit= h XMPP IM and presence. Comments are very welcome! Regards, Simo ----------------- Combining SIP VoIP and XMPP IM/Presence =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Currently most standards-based Voice over IP (VoIP) deployments use the Ses= sion Initiation Protocol (SIP). In addition to providing basic voice servi= ce SIP has an extensive support for more advanced telephony features includ= ing interworking with the traditional Public Switched Telephone Network (PS= TN). SIP is also gaining popularity in the field of video communication. A= t the same time, the Extensible Messaging and Presence Protocol (XMPP) is e= njoying widespread usage in instant messaging and presence services. =20 Both SIP and XMPP offer extensions for voice as well as IM and presence (XM= PP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols= ). However, widespread deployment of these extensions has not so far taken = place. In order to speed up deployment of integrated VoIP and IM systems, S= IP based voice and XMPP based IM/Presence could be combined in endpoints to= offer a voice, IM and presence service without any changes to existing SIP= and XMPP service infrastrucure.=20 The objective of this Working Group is to develop solutions for combining S= IP based voice with XMPP based IM and Presence such that a unified user exp= erience can be offered to end user. Specifically, solutions are needed on=20 - addressing; end users should be able to initiate sessions to a user ident= ity in either SIP or XMPP domain. The corresponding user identity in the ot= her protocol domain needs to be learned automatically. - session correlation; endpoints need to be able to correlate voice session= s with IM/Presence such that they can be presented to the end user in a sea= mless fashion - presence; it should be possible to change the XMPP presence status based = on the user's activity in the SIP domain. The goal is to rely on existing service infrastructre, and new requirements= should be imposed only to the endpoint.=20 Protocol interworking, that is, translation from one protocol to another, i= s out of scope of this WG. Milestones Feb 2010 Problem statement and use cases submitted to IESG as Informational Dec 2010 Specification on combining SIP based voice and XMPP based IM/Prese= nce in a seamless manner submitted to IESG as Proposed Standard. ----------------- From hsinnrei@adobe.com Mon Sep 21 06:20:34 2009 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 84FDB28C130 for ; Mon, 21 Sep 2009 06:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.573, 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 ZAjlW-wuMo30 for ; Mon, 21 Sep 2009 06:20:31 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id C21CE3A6903 for ; Mon, 21 Sep 2009 06:20:30 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSrd907I+Fi5y/PIecXBfmaQKM26KPOIs@postini.com; Mon, 21 Sep 2009 06:21:32 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8LDETao000487; Mon, 21 Sep 2009 06:14:29 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8LDLNlT004505; Mon, 21 Sep 2009 06:21:23 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 21 Sep 2009 06:21:22 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Mon, 21 Sep 2009 06:21:22 -0700 From: Henry Sinnreich To: Dan Wing , Paul Kyzivat Date: Mon, 21 Sep 2009 06:21:21 -0700 Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: AcozGfDDZEpu/TONTlGGI3+sS5A8hgHUBuWgABUXHZo= Message-ID: In-Reply-To: <030901ca3a6a$6bf5b690$c6f0200a@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6DCE8015E91hsinnreiadobecom_" MIME-Version: 1.0 Cc: "Simo.Veikkolainen@nokia.com" , "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" , "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 21 Sep 2009 13:20:34 -0000 --_000_C6DCE8015E91hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 9/20/09 10:20 PM, "Dan Wing" wrote: >So XMPP has to use E.164's (like SIP deployments do), or SIP >will have to switch to user@host. I don't forsee either happening. >If this is deemed necessary then we will have to map between them >-- somehow. Send an XMPP message asking "what is your phone >number" (in a computer-parsable manner), perhaps? Now why could not the application query the address book to get both the E.= 164 addresses and user@host addresses? This is not only of interest to na=EFve folks like me, but also illustrates= how some key functions are better done in the applications in the endpoint= s rather than in the network application protocols. The "old" e2e principle illustrated... Henry --_000_C6DCE8015E91hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] New topic proposal for DISPATCH On 9/20/09 10:20 PM, "Dan Wing" <dwing@Cisco.COM> wrote:

>So XMPP has to use E.164's (like SIP de= ployments do), or SIP
>will have to switch to user@host.  I don't forsee either happening= .
>If this is deemed necessary then we will have to map between them
>-- somehow.  Send an XMPP message asking "what is your phone<= BR> >number" (in a computer-parsable manner), perhaps?

Now why could not the application query the address book to get both the E.= 164 addresses and user@host addresses?

This is not only of interest to naïve folks like me, but also illustra= tes how some key functions are better done in the applications in the endpo= ints rather than in the network application protocols.
The “old” e2e principle illustrated...

Henry

--_000_C6DCE8015E91hsinnreiadobecom_-- From pkyzivat@cisco.com Mon Sep 21 06:25:04 2009 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 C3FE43A6A88 for ; Mon, 21 Sep 2009 06:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.755 X-Spam-Level: X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_34=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 Qgf8meBUcxbV for ; Mon, 21 Sep 2009 06:25:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 194323A67A4 for ; Mon, 21 Sep 2009 06:25:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMcbt0qrR7PE/2dsb2JhbAC6H4hQAY4lBYIzgWg X-IronPort-AV: E=Sophos;i="4.44,424,1249257600"; d="scan'208";a="190929439" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2009 13:26:00 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8LDQ0xj024167; Mon, 21 Sep 2009 06:26:00 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8LDPwKL028456; Mon, 21 Sep 2009 13:26:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 09:25:58 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 09:25:57 -0400 Message-ID: <4AB77EE5.6000008@cisco.com> Date: Mon, 21 Sep 2009 09:25:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Wing References: <4AAAAB49.8020206@cisco.com> <030901ca3a6a$6bf5b690$c6f0200a@cisco.com> In-Reply-To: <030901ca3a6a$6bf5b690$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2009 13:25:57.0730 (UTC) FILETIME=[0DBF8420:01CA3ABF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16560; t=1253539560; x=1254403560; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20New=20topic=20proposal=20f or=20DISPATCH |Sender:=20; bh=3GCltQIke5Bu9y+6myxiRPRx+0PK0Akuj2aOkhcOvfs=; b=CCjwM4tZvMMHPVvROT4oVFpoZUpy8EfFnU3AKDYM8UNHXULVmq0SDRP1h4 hVxaWYRZ8uBq7g982ELLZYJRcXzg1Xv5OYNltyhWXvpzjW4mC5SVuV0ZfpRn sIQQNgB4c9; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: dispatch@ietf.org, 'Henry Sinnreich' , gonzalo.camarillo@ericsson.com, Simo.Veikkolainen@nokia.com, Markus.Isomaki@nokia.com Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 21 Sep 2009 13:25:04 -0000 inline Dan Wing wrote: > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, September 11, 2009 12:56 PM >> To: Henry Sinnreich >> Cc: dispatch@ietf.org; avshalom@il.ibm.com; >> gonzalo.camarillo@ericsson.com; Markus.Isomaki@nokia.com; >> Simo.Veikkolainen@nokia.com >> Subject: Re: [dispatch] New topic proposal for DISPATCH >> >> I agree that there are pragmatic reasons to pursue the >> coordination/coexistence of sip and xmpp. And pushing >> responsibility to >> the endpoints remains desirable. >> >> One thing that remains of concern to me in such work is that >> we end up >> with disjoint address spaces without any straightforward way to >> correlate them. So if I want a single "session" involving >> both voice via >> SIP and IM via xmpp, then I have great difficulty in discovering URIs >> for the "subordinate" session that correlate with those for the >> "primary" session. (No pejorative intended here - one or the >> other must go first.) > > So XMPP has to use E.164's (like SIP deployments do), or SIP > will have to switch to user@host. I don't forsee either happening. > If this is deemed necessary then we will have to map between them > -- somehow. Send an XMPP message asking "what is your phone > number" (in a computer-parsable manner), perhaps? Well, there is nothing to prevent XMPP from using E.164+domain name (the way most of sip deployments do since nobody seems to like tel:.) BUT, as things currently stand there is no guarantee that sip:alice@atlanta.com and xmpp:alice@atlanta.com refer to the same persona. While it would often be a reasonable leap of faith to assume they do, the namespaces are typically administered independently. Having *some* automated way of determining an association seems necessary to a good integration. Of course that is exactly what a session initiation protocol is all about. Its also something that a presence protocol should also be able to do. Thanks, Paul > -d > > >> Somehow this problem needs to be resolved. >> >> Thanks, >> Paul >> >> Henry Sinnreich wrote: >>> Hi Markus, >>> >>> Thanks for your thoughtful reply and I agree there are some >> scenarios >>> where it makes sense. >>> More important, doing this in the endpoints is the right >> approach IMO >>> and as you know, I will always defend the Internet >> end-to-end principle :-) >>> This distributed approach is also IMO a good answer to the >> Interdomain >>> Scaling problem for IM >>> ( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I >> have copied >>> one of its authors here. >>> >>> This raises the questions: >>> >>> 1. Why stop at SIP and XMPP, and not add other popular >> IM protocols, >>> as is already done by quite a few products in the market? >>> 2. Can your approach be generalized in a more generic way? >>> >>> >>> If endpoints are accommodating several IM protocols, an >> IETF, Dispatch >>> recommended GENERIC approach would make many people feel more >>> comfortable about it. Your I-D could be used as a tested >> example for a >>> generic approach. >>> >>> Ranting on preferring endpoint applications to more >> application protocols >>> I still believe creative application developers face the choice of >>> either inventing new applications or dedicating their time >> to learning >>> application protocols and they cannot do both. Learning and >> following >>> both SIP and XMPP to write and update code is quite a challenge. >>> Is there a better way? >>> For this reason, one single application protocol for IM and >> voice is enough. >>> Proof: Almost all the applications that make people buy >> smart phones, >>> use online office apps and enterprise apps run on HTTP(S) and their >>> application developers don't have to worry about knowing >> how HTTP works. >>> As a result, HTTP has been also used to even carry >> streaming media, web >>> conferencing and IM. Just to avoid spending a lifetime to learn and >>> follow application protocols. But HTTP based apps dominate the >>> application space. This is however for another discussion elsewhere. >>> >>> My strictly personal 2 cents. >>> >>> Thanks again, >>> >>> Henry >>> >>> >>> On 9/11/09 8:11 AM, "Markus.Isomaki@nokia.com" >>> wrote: >>> >>> Hi Henry, >>> >>> Thanks for your feedback :) Let me answer to the >> excellent points >>> you raise. >>> >>> First of all, I would encourage you and everyone to >> carefully read >>> the Introduction chapter of the draft >>> >> (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 >>> >> >>> ) to be clear on what the proposal is about. That is, we are not >>> trying to boil the ocean and define all possible ways >> how SIP and >>> XMPP infrastructures could be combined, but instead try >> to define a >>> minimalistic approach whereby a client can use both SIP >> and XMPP in >>> an integrated manner WITHOUT requiring ANY changes on >> the servers >>> that are already deployed. >>> >>> See further comments below with [Markus]: >>> >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> *From:* ext Henry Sinnreich [mailto:hsinnrei@adobe.com] >>> *Sent:* 04 September, 2009 18:42 >>> *To:* Veikkolainen Simo (Nokia-D/Helsinki); >> dispatch@ietf.org; >>> mary.barnes@nortel.com; gonzalo.camarillo@ericsson.com >>> *Cc:* Isomaki Markus (Nokia-CIC/Espoo); Olle E. Johansson >>> *Subject:* Re: [dispatch] New topic proposal for DISPATCH >>> >>> >>> I would like to second such work, but a far deeper >> look under >>> the hood is necessary, so we don't do another >> Elbonia project. >>> http://dilbert.com/strips/comic/2009-09-01/ >>> >>> Here are some not very mature thoughts on the >> scope of the work. >>> The most interesting, ROI estimate and REST architecture >>> support are at the end. >>> >>> Servers >>> >>> Fundamentally, we need a registrar, a proxy and a presence >>> server: Three in total >>> >>> * What will be the duplication of servers and where >>> specifically? >>> * How does the SIP registrar communicate with the XMPP >>> server(s)? >>> * What may be the routing protocol(s) inside a SIP+XMMP >>> network? Think of IMS as a stressing use case. >>> >>> >>> [Markus] Our starting point is that we already have >> quite many >>> SIP VoIP deployments out there, as long as quite many XMPP >>> presence & IM deployments. So, the servers you >> mention already >>> exist. If one now wants to develop a client that >> does VoIP, IM >>> and presence together, it should be possible to >> utilize these >>> existing infrastrcutures and not have to wait for >> new ones to >>> be deployed (as for instance we have waited quite >> many years for >>> SIMPLE-based Presence servers to get deployed but >> compared to >>> XMPP there's very little in use). The idea is to define a >>> couple of E2E (as in nothing that SIP proxies or >> XMPP servers >>> would have to support) protocol extensions which >> would allow >>> the client to nicely combine SIP VoIP and XMPP >> presence & IM. >>> >>> >>> There is no need for SIP and XMPP servers to know >> about each >>> other or route protocol messages between each other. All the >>> logic is put into the endpoints. No need to worry about IMS >>> either, except that in theory the client can use >> IMS for its >>> VoIP service (similar to any other SIP infra). >>> >>> >>> User Agents >>> >>> * Same as with servers: How many and what >> protocol RFCs are >>> there in the combination? >>> * Which of the "services" can be placed in the >> applications >>> in the endpoints or in the network >> application protocols, >>> such as SIP and XMPP. This is the topic on >> infrastructure >>> vs. endpoint applications. >>> >>> >>> [Markus] Just take any current SIP VoIP UA >> implementation, XMPP >>> client implementation and glue them together and >> you're already >>> pretty far. Add a couple of extensions as proposed and it's >>> done. From there onwards you have a pretty >> powerful machinery >>> to add applications by using SIP session setup and >> XMPP message >>> delivery capabilities. >>> >>> >>> Application Protocol Stacks >>> >>> * How many protocol stacks does this involve >> and more to >>> the point, how many RFCs? >>> * For SIP alone, see http://rfc3261.net/. What >> will be the >>> total combined RFC count? >>> >>> >>> [Markus] All what we expect is already pretty >> widely supported >>> and even available as open source: basic SIP VoIP >> and XMPP IM >>> and presence is enough to start with. >>> >>> >>> NAT Traversal >>> >>> * Will STUN/TURN/ICE work the same for SIP and >> for XMPP? >>> >>> [Markus] In our proposal SIP would be used for >> setting up voice >>> & video sessions. So, you would need NAT traversal >> for that. How >>> that's done is outside the scope but either B2BUA >> or ICE based >>> mechanisms would work as far as they work in >> general. For XMPP >>> we would not need to worry about NAT traversal >> beyond how its >>> done in that protocol by default. For a client there is a >>> caveat that it has to keepalive the TCP connections >> with BOTH >>> SIP and XMPP servers so it would be recommended to >> synchronize >>> those (send them at the same time) for instance in >> a battery >>> powered device. >>> >>> >>> Return on Investment (ROI): Cost and effort by >> developers. More >>> network infrastructure, not even counting B2B NEs. >>> >>> * What is the additional time/money required >> for developers >>> that know SIP to also learn XMPP and vice >> versa? This is >>> all about return on investment. >>> >>> >>> [Markus] This is a problem for sure, even more so for the >>> people writing standard specs than code :) Hopefully the >>> developer would just have add a couple of simple >> extensions to >>> existing SIP and XMPP implementations. >>> >>> >>> Support for a REST-full architecture >>> >>> The WWW has a REST architecture was formulated in >> 2000, after >>> the emergence of SIP and XMMP. As a result of its >> architecture, >>> the WWW has had a transformational effect on the following >>> (this is not a complete list). Some SIP work >> recommends already >>> recommends REST, such as in RFC 4240 and in >>> http://tools.ietf.org/html/draft-griffin-bliss-rest-00 >>> >>> * Web applications from mail to office apps >>> * Internet applications previously served by dedicated >>> network applications protocols >>> * Many other industries, from banking to newsprint to >>> travel. And Oh, social networks, they also have >>> registrars... >>> >>> >>> >>> Now please keep in mind the WWW architecture uses basically >>> only 3 components*: The URI for addressing, HTTP >> for transport >>> and HTML for data rendering, augmented by some >> other languages >>> (XML) and namespaces. Can we benefit something from the WWW >>> architecture? If yes what specifically? >>> >>> Heresy: If the web developers could use HTTP only, >> what other >>> application level protocols do we really need >> except RTP/UDP? >>> This includes in my mind TLS and DTLS for secure >> transport or >>> even better IMO: HIP for many reasons. >>> >>> >>> [Markus] Personally I agree that REST+HTTP+Javascript is a >>> superior toolset compared to SIP, XMPP, IMAP and so on to >>> develop many applications. However, there are >> still plenty of >>> SIP based VoIP and XMPP based IM and presence >> deployments out >>> there and I don't expect the web apps to replace >> all of them in >>> the near future :) >>> >>> >>> * T.V. Raman: "Toward 2W, Beyond Web 2.0", >> Communications of >>> the ACM, February 2009 >>> >>> Many or most of these points may be moot or make >> no sense, but >>> maybe should be cleared up, in case there are more >> naive people >>> like me that may be interested. >>> >>> My strict personal 2 cents. >>> >>> FRANK comments are most welcome. >>> >>> Henry >>> >>> >>> >>> On 9/4/09 7:09 AM, "Simo.Veikkolainen@nokia.com" >>> wrote: >>> >>> >>> >>> Hi, >>> >>> We would like to propose a new DISPATCH topic >> on how SIP >>> and XMPP can be used together in a >> complementary fashion. >>> >>> We have been working on a solution which >> combines SIP based >>> VoIP and XMPP based IM and Presence. The >> requirements and a >>> proposed solution is outlined in >>> >> _http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01_ >>> >> >>> . >>> >>> The motivation for this work comes from experience which >>> shows that most standards based VoIP >> deployments use SIP. >>> At the same time, the Extensible Messaging and Presence >>> Protocol (XMPP) is widely used in instant messaging and >>> presence services. An interesting scenario >> arises when a >>> SIP based voice (and video) service is combined together >>> with an XMPP based instant messaging and >> presence service. >>> >>> Note that the goal in this work is not >> SIP-XMPP protocol >>> translation, but to define protocol extensions and best >>> practises such that SIP based VoIP and XMPP >> based IM and >>> presence could be seamlessly combined and >> offered to the end >>> user. For rapid deployment, we assume no changes in the >>> server infrastructure, and instead impose new >> requirements >>> and protocol extensions only to the endpoints. >>> >>> We would like to get some discussion going on >> the use case >>> itself as well as on the solution. Also, we >> would like to >>> hear you thoughts on DISPATCH or a new >> "dispatched" mini-WG >>> as the home for such work. >>> >>> Exact charter proposal and problem statemen is >> to follow. >>> >>> Regards, >>> Simo and Markus >>> >>> >>> >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> _______________________________________________ >>> 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 Mon Sep 21 06:32:41 2009 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 D5DDE3A63D3 for ; Mon, 21 Sep 2009 06:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 DWElCtzJBoha for ; Mon, 21 Sep 2009 06:32:40 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8339628C0E4 for ; Mon, 21 Sep 2009 06:32:40 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n8LDXeXY012518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2009 08:33:40 -0500 (CDT) 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 n8LDXeZi001460 for ; Mon, 21 Sep 2009 08:33:40 -0500 (CDT) Message-ID: <4AB780B4.3000601@alcatel-lucent.com> Date: Mon, 21 Sep 2009 08:33:40 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "dispatch@ietf.org" 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 Subject: [dispatch] Charter proposal: Session Recording Protocol 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, 21 Sep 2009 13:32:42 -0000 Hi: The following charter proposal is a continuation of the work presented on the same topic (SIP Session Recording) at the Stockholm IETF. Regards, The Session Recording Protocol (SRP) working group is chartered to define a SIP-based protocol for controlling a session (media) recorder. Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will produce a specification for a protocol that will manage delivery of media from an end-point that originates media or that has access to it to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. The Session Recording problem presents certain unique requirements that are not addressed in the current SIP protocol specification. These include requirements such as the need for a distinction between the session that is being recorded versus the session that has been established for recording. The SRP Working Group will thoroughly identify use cases, provide example system architectures and deployment scenarios, and define requirements. The scope of the activity includes: * Recorder Control * Session metadata content and format * Security mechanisms, including transport and media encryption * Negotiation of recording media streams Privacy and security of conversations are significant concerns. The group will define these issues and rationalize with IETF standards and practices. This includes privacy concerns (including RAVEN), encryption, NAT traversal, SIP-enabled firewalls, authorization, and security. The group will produce: * Updated Requirements, Use Cases, Architecture draft * Specification for Session Recording Protocol Timeline: Apr 2010 Requirements, Use Cases, Architecture to IESG as Informational Draft Nov 2010 Submit protocol draft to IESG as standards track - 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 pkyzivat@cisco.com Mon Sep 21 08:31:13 2009 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 7BE6C28C148 for ; Mon, 21 Sep 2009 08:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 PeNWmgykyzJm for ; Mon, 21 Sep 2009 08:31:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8259C3A6A94 for ; Mon, 21 Sep 2009 08:31:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE85t0qrR7PE/2dsb2JhbAC7TIhQAY42BYQb X-IronPort-AV: E=Sophos;i="4.44,424,1249257600"; d="scan'208";a="206549189" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2009 15:32:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8LFWEDB016657; Mon, 21 Sep 2009 08:32:14 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8LFWDTN015296; Mon, 21 Sep 2009 15:32:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 11:32:13 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 11:32:12 -0400 Message-ID: <4AB79C7C.5010803@cisco.com> Date: Mon, 21 Sep 2009 11:32:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Salvatore Loreto References: <4AB75AC7.6080509@ericsson.com> In-Reply-To: <4AB75AC7.6080509@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2009 15:32:12.0995 (UTC) FILETIME=[B0F53930:01CA3AD0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4609; t=1253547134; x=1254411134; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20Proposal=20for=2 0Disaggregated=20Media |Sender:=20; bh=HNZKi+EmuWkX3uuQqIqZ56I43c0PLyehsjYl0Jez/KY=; b=uw/aW/uTD3B0XNV+oxfpi18pO9zvk823jK7Tj+qT+W5O/rkYuvk35BoSY3 EPWfAuYSnCLvakSO4/0K1kUfQmi6yGyY4LJU4qzkBJtCaLOuVUJ2veHPlVf8 H636MWsiJ5; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IETF Dispatch , Gonzalo Camarillo Subject: Re: [dispatch] Charter Proposal for Disaggregated Media 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, 21 Sep 2009 15:31:13 -0000 I agree with the utility of such work. Comments inline. Salvatore Loreto wrote: > Hi there, > > below is a charter proposal for a WG on Disaggregated Media. > > All comments, thoughts, feedbacks are very welcome! > > cheers > Sal > > > > Disaggregated Media WG Charter > ------------------------------- Disaggregated media refers to the > ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are treated > by the far end of the session as a single media session. > > Generally, a given participant uses a single device to establish (or > participate in) a given multimedia session. Consequently, the SIP > signaling to manage the multimedia session and the actual media > streams are typically co-located in the same device. In scenarios > involving disaggregated media, a user wants to establish a single > multimedia session combining different media streams coming from > different devices under his or her control. This creates a need to > coordinate the exchange of the those media streams within the media > session. > > The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate > the different devices under his control to involve them in the call. > The different devices can communicate with one another using Mbus > messages, and then let only one device, a call control engine, to > initiate, manage and terminate call control relations to other SIP > endpoints. All the different user's devices need to support the Mbus > protocol. > > The Megaco [RFC3525] protocol can be used in a disaggregated media > scenario to let one of the user's devices act as a Media Gateway > Controller, > coordinating all the other devices under the user's control, which in > this case > will act as Media Gateways. In this case all the different user's > devices need to support the Megaco protocol. > > The SIP protocol provides 3pcc [RFC3725] as a possible mechanism > to coordinate the exchange of media streams coming from different > devices under the control of the same user, in the case at least one > among the different devices under his control supports this > mechanism and is able to become a Controller for the other in the call. > > All the existing mechanisms only cover a subset of the interesting > scenarios that involve disaggregated media. Scenarios not covered by > existing mechanisms include the loosely-coupled one where none of the > nodes can act as a controller > because it does not support the necessary functionality or because it > will not participate in the whole session. I don't understand the above. The disaggregated multimedia session will not be established unless *something* takes the initiative to establish it. IMO that thing, whatever it is, is acting as a "controller". The mechanism you have proposed before distributes the "controller" functionality across multiple nodes. There is something that causes a new stream to be established as a separate sip session and causes that to announce correlation with some other session. And then there is are the devices at the far end, that maintain the correlation and do required maintenance of the correlation as changes happen. Can you provide more definition of what you mean by "loosely coupled" while recognizing that something needs to know enough to do the initiation and maintenance of the correlation? > The objective of the proposed working group is to develop a framework > for Disaggregated Media that include both improvements on existing > mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms > like a loosely coupled mechanism that does not require the > implementation of complex logic on any of the terminals. I would argue that it is premature to assert that new mechanisms are required. > Specifically, the proposed working group will develop the following > deliverables: 1. A framework document describing key design > considerations for Disaggregated mediamechanism. > 2. A specification for a loosely couple mechanism. > 3. One or more specifications to improve existing mechanism to coordinate > disaggregated media. Are both (2) and (3) *specifications*? Or is (2) a requirements document that is then satisfied by (3)? If (2) is requirements, then this makes sense to me, though it might be possible to combine that with (1). If both (2) and (3) are mechanism specs then I don't get it. Thanks, Paul From Even.roni@huawei.com Mon Sep 21 09:25:14 2009 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 C978C3A6A3E for ; Mon, 21 Sep 2009 09:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.973 X-Spam-Level: X-Spam-Status: No, score=0.973 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYzoYSUmVlxX for ; Mon, 21 Sep 2009 09:25:14 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F0D543A6A33 for ; Mon, 21 Sep 2009 09:25:08 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQB00K3SXNCQU@szxga04-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 00:26:00 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQB00GLYXNC46@szxga04-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 00:26:00 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-27-16.red.bezeqint.net [82.81.27.16]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQB00IMJXN3F1@szxml01-in.huawei.com>; Tue, 22 Sep 2009 00:26:00 +0800 (CST) Date: Mon, 21 Sep 2009 19:23:44 +0300 From: Roni Even In-reply-to: <4AB75AC7.6080509@ericsson.com> To: 'Salvatore Loreto' , 'IETF Dispatch' Message-id: <003201ca3ad7$ea153b00$be3fb100$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Aco6qY/NAol5LRVASNmCEzl06YriJwALgYgw References: <4AB75AC7.6080509@ericsson.com> Cc: 'Gonzalo Camarillo' Subject: Re: [dispatch] Charter Proposal for Disaggregated Media and combining SIP and XMPP 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, 21 Sep 2009 16:25:14 -0000 Hi, What is the relation between this proposal and the SIP and XMPP proposal. To me it looks like both are trying to combine two separate call legs to be as one and have similar requirements. Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Salvatore Loreto > Sent: Monday, September 21, 2009 1:52 PM > To: IETF Dispatch > Cc: Gonzalo Camarillo > Subject: [dispatch] Charter Proposal for Disaggregated Media > > Hi there, > > below is a charter proposal for a WG on Disaggregated Media. > > All comments, thoughts, feedbacks are very welcome! > > cheers > Sal > > > > Disaggregated Media WG Charter > ------------------------------- > Disaggregated media refers to the ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are treated > by the far end of the session as a single media session. > > Generally, a given participant uses a single device to establish (or > participate in) a given multimedia session. Consequently, the SIP > signaling to manage the multimedia session and the actual media > streams are typically co-located in the same device. In scenarios > involving disaggregated media, a user wants to establish a single > multimedia session combining different media streams coming from > different devices under his or her control. This creates a need to > coordinate the exchange of the those media streams within the media > session. > > The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate > the different devices under his control to involve them in the call. > The different devices can communicate with one another using Mbus > messages, and then let only one device, a call control engine, to > initiate, manage and terminate call control relations to other SIP > endpoints. > All the different user's devices need to support the Mbus protocol. > > The Megaco [RFC3525] protocol can be used in a disaggregated media > scenario to let one of the user's devices act as a Media Gateway > Controller, > coordinating all the other devices under the user's control, which in > this case > will act as Media Gateways. In this case all the different user's > devices > need to support the Megaco protocol. > > The SIP protocol provides 3pcc [RFC3725] as a possible mechanism > to coordinate the exchange of media streams coming from different > devices under the control of the same user, in the case at least > one among the different devices under his control supports this > mechanism and is able to become a Controller for the other in the call. > > > All the existing mechanisms only cover a subset of the interesting > scenarios > that involve disaggregated media. Scenarios not covered by existing > mechanisms > include the loosely-coupled one where none of the nodes can act as a > controller > because it does not support the necessary functionality or because it > will not > participate in the whole session. > > > The objective of the proposed working group is to develop a framework > for Disaggregated Media that include both improvements on existing > mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms > like a loosely coupled mechanism that does not require the > implementation > of complex logic on any of the terminals. > > > Specifically, the proposed working group will develop the following > deliverables: > 1. A framework document describing key design considerations for > Disaggregated > mediamechanism. > 2. A specification for a loosely couple mechanism. > 3. One or more specifications to improve existing mechanism to > coordinate > disaggregated media. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From salvatore.loreto@ericsson.com Mon Sep 21 09:39:14 2009 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 6F5D43A689D for ; Mon, 21 Sep 2009 09:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HELO_EQ_SE=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 vZ6Q5Ar4cRL6 for ; Mon, 21 Sep 2009 09:39:09 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C82803A6A33 for ; Mon, 21 Sep 2009 09:39:08 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-13-4ab7ac68e9f2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id CF.2E.22406.86CA7BA4; Mon, 21 Sep 2009 18:40:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 18:39:01 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 18:39:01 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 347E624D8; Mon, 21 Sep 2009 19:39:01 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ED5DF21A17; Mon, 21 Sep 2009 19:39:00 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 455DF2195C; Mon, 21 Sep 2009 19:39:00 +0300 (EEST) Message-ID: <4AB7AC23.8090600@ericsson.com> Date: Mon, 21 Sep 2009 19:38:59 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Roni Even References: <4AB75AC7.6080509@ericsson.com> <003201ca3ad7$ea153b00$be3fb100$%roni@huawei.com> In-Reply-To: <003201ca3ad7$ea153b00$be3fb100$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 21 Sep 2009 16:39:01.0171 (UTC) FILETIME=[06045830:01CA3ADA] X-Brightmail-Tracker: AAAAAA== Cc: 'IETF Dispatch' , 'Gonzalo Camarillo' Subject: Re: [dispatch] Charter Proposal for Disaggregated Media and combining SIP and XMPP 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, 21 Sep 2009 16:39:14 -0000 Hi Roni, actually there isn't any relation between this two proposals, each of them has started from a different use case. however if you consider XMPP as a XML streaming, then combining SIP and XMPP can be considered as particular case where "a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control." /Sal Roni Even wrote: > Hi, > What is the relation between this proposal and the SIP and XMPP proposal. > To me it looks like both are trying to combine two separate call legs to be > as one and have similar requirements. > > Roni Even > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Salvatore Loreto >> Sent: Monday, September 21, 2009 1:52 PM >> To: IETF Dispatch >> Cc: Gonzalo Camarillo >> Subject: [dispatch] Charter Proposal for Disaggregated Media >> >> Hi there, >> >> below is a charter proposal for a WG on Disaggregated Media. >> >> All comments, thoughts, feedbacks are very welcome! >> >> cheers >> Sal >> >> >> >> Disaggregated Media WG Charter >> ------------------------------- >> Disaggregated media refers to the ability for a user to create a >> multimedia session combining different media streams, coming from >> different devices under his or her control, so that they are treated >> by the far end of the session as a single media session. >> >> Generally, a given participant uses a single device to establish (or >> participate in) a given multimedia session. Consequently, the SIP >> signaling to manage the multimedia session and the actual media >> streams are typically co-located in the same device. In scenarios >> involving disaggregated media, a user wants to establish a single >> multimedia session combining different media streams coming from >> different devices under his or her control. This creates a need to >> coordinate the exchange of the those media streams within the media >> session. >> >> The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate >> the different devices under his control to involve them in the call. >> The different devices can communicate with one another using Mbus >> messages, and then let only one device, a call control engine, to >> initiate, manage and terminate call control relations to other SIP >> endpoints. >> All the different user's devices need to support the Mbus protocol. >> >> The Megaco [RFC3525] protocol can be used in a disaggregated media >> scenario to let one of the user's devices act as a Media Gateway >> Controller, >> coordinating all the other devices under the user's control, which in >> this case >> will act as Media Gateways. In this case all the different user's >> devices >> need to support the Megaco protocol. >> >> The SIP protocol provides 3pcc [RFC3725] as a possible mechanism >> to coordinate the exchange of media streams coming from different >> devices under the control of the same user, in the case at least >> one among the different devices under his control supports this >> mechanism and is able to become a Controller for the other in the call. >> >> >> All the existing mechanisms only cover a subset of the interesting >> scenarios >> that involve disaggregated media. Scenarios not covered by existing >> mechanisms >> include the loosely-coupled one where none of the nodes can act as a >> controller >> because it does not support the necessary functionality or because it >> will not >> participate in the whole session. >> >> >> The objective of the proposed working group is to develop a framework >> for Disaggregated Media that include both improvements on existing >> mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms >> like a loosely coupled mechanism that does not require the >> implementation >> of complex logic on any of the terminals. >> >> >> Specifically, the proposed working group will develop the following >> deliverables: >> 1. A framework document describing key design considerations for >> Disaggregated >> mediamechanism. >> 2. A specification for a loosely couple mechanism. >> 3. One or more specifications to improve existing mechanism to >> coordinate >> disaggregated media. >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > From Even.roni@huawei.com Mon Sep 21 09:57:09 2009 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 D696928C1DB for ; Mon, 21 Sep 2009 09:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=1.733, BAYES_00=-2.599, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGRu6wYyeEDn for ; Mon, 21 Sep 2009 09:57:08 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 079AB3A6980 for ; Mon, 21 Sep 2009 09:57:07 -0700 (PDT) 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 <0KQB00EVDZ4VK8@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 00:58:07 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQB00FOUZ4VTC@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 00:58:07 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-27-16.red.bezeqint.net [82.81.27.16]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQB002XFZ4LI5@szxml02-in.huawei.com>; Tue, 22 Sep 2009 00:58:07 +0800 (CST) Date: Mon, 21 Sep 2009 19:55:46 +0300 From: Roni Even In-reply-to: <4AB7AC23.8090600@ericsson.com> To: 'Salvatore Loreto' Message-id: <004701ca3adc$668b1ed0$33a15c70$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Aco62jDUlwlWbYVvTS+QNVyGRjDDlQAAcnVw References: <4AB75AC7.6080509@ericsson.com> <003201ca3ad7$ea153b00$be3fb100$%roni@huawei.com> <4AB7AC23.8090600@ericsson.com> Cc: 'IETF Dispatch' , 'Gonzalo Camarillo' Subject: Re: [dispatch] Charter Proposal for Disaggregated Media and combining SIP and XMPP 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, 21 Sep 2009 16:57:10 -0000 Hi, This is what I meant, you can look at XMPP and the voice streams as two media streams that you want to handle as one multimedia session. Roni Even > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Monday, September 21, 2009 7:39 PM > To: Roni Even > Cc: 'IETF Dispatch'; 'Gonzalo Camarillo' > Subject: Re: [dispatch] Charter Proposal for Disaggregated Media and > combining SIP and XMPP > > Hi Roni, > > actually there isn't any relation between this two proposals, each of > them has started from a different use case. > > however if you consider XMPP as a XML streaming, then combining SIP and > XMPP can be considered as particular case where > "a user wants to establish a single multimedia session combining > different media streams coming from > different devices under his or her control." > > /Sal > > Roni Even wrote: > > Hi, > > What is the relation between this proposal and the SIP and XMPP > proposal. > > To me it looks like both are trying to combine two separate call legs > to be > > as one and have similar requirements. > > > > Roni Even > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > >> Behalf Of Salvatore Loreto > >> Sent: Monday, September 21, 2009 1:52 PM > >> To: IETF Dispatch > >> Cc: Gonzalo Camarillo > >> Subject: [dispatch] Charter Proposal for Disaggregated Media > >> > >> Hi there, > >> > >> below is a charter proposal for a WG on Disaggregated Media. > >> > >> All comments, thoughts, feedbacks are very welcome! > >> > >> cheers > >> Sal > >> > >> > >> > >> Disaggregated Media WG Charter > >> ------------------------------- > >> Disaggregated media refers to the ability for a user to create a > >> multimedia session combining different media streams, coming from > >> different devices under his or her control, so that they are treated > >> by the far end of the session as a single media session. > >> > >> Generally, a given participant uses a single device to establish (or > >> participate in) a given multimedia session. Consequently, the SIP > >> signaling to manage the multimedia session and the actual media > >> streams are typically co-located in the same device. In scenarios > >> involving disaggregated media, a user wants to establish a single > >> multimedia session combining different media streams coming from > >> different devices under his or her control. This creates a need to > >> coordinate the exchange of the those media streams within the media > >> session. > >> > >> The Message Bus (Mbus) [RFC3259] can be used by an user to > coordinate > >> the different devices under his control to involve them in the call. > >> The different devices can communicate with one another using Mbus > >> messages, and then let only one device, a call control engine, to > >> initiate, manage and terminate call control relations to other SIP > >> endpoints. > >> All the different user's devices need to support the Mbus protocol. > >> > >> The Megaco [RFC3525] protocol can be used in a disaggregated media > >> scenario to let one of the user's devices act as a Media Gateway > >> Controller, > >> coordinating all the other devices under the user's control, which > in > >> this case > >> will act as Media Gateways. In this case all the different user's > >> devices > >> need to support the Megaco protocol. > >> > >> The SIP protocol provides 3pcc [RFC3725] as a possible mechanism > >> to coordinate the exchange of media streams coming from different > >> devices under the control of the same user, in the case at least > >> one among the different devices under his control supports this > >> mechanism and is able to become a Controller for the other in the > call. > >> > >> > >> All the existing mechanisms only cover a subset of the interesting > >> scenarios > >> that involve disaggregated media. Scenarios not covered by existing > >> mechanisms > >> include the loosely-coupled one where none of the nodes can act as a > >> controller > >> because it does not support the necessary functionality or because > it > >> will not > >> participate in the whole session. > >> > >> > >> The objective of the proposed working group is to develop a > framework > >> for Disaggregated Media that include both improvements on existing > >> mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms > >> like a loosely coupled mechanism that does not require the > >> implementation > >> of complex logic on any of the terminals. > >> > >> > >> Specifically, the proposed working group will develop the following > >> deliverables: > >> 1. A framework document describing key design considerations for > >> Disaggregated > >> mediamechanism. > >> 2. A specification for a loosely couple mechanism. > >> 3. One or more specifications to improve existing mechanism to > >> coordinate > >> disaggregated media. > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > > > From L.Liess@telekom.de Mon Sep 21 10:44:20 2009 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 2867C3A699E for ; Mon, 21 Sep 2009 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.327, 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 mhxaRbsvR7e4 for ; Mon, 21 Sep 2009 10:44:19 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id D2AC53A6AC0 for ; Mon, 21 Sep 2009 10:44:18 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 21 Sep 2009 19:45:11 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 19:45:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 21 Sep 2009 19:45:10 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter proposal: SIP Alert-Info URN Thread-Index: Aco640Ol88Y9X4ViRTeB08Ydf9e9qw== From: To: X-OriginalArrivalTime: 21 Sep 2009 17:45:11.0307 (UTC) FILETIME=[446705B0:01CA3AE3] Cc: R.Jesske@telekom.de Subject: [dispatch] Charter proposal: SIP Alert-Info URN 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, 21 Sep 2009 17:44:20 -0000 Hello, Please find below our charter proposal for the SIP Alert-Info URN. Comments are very welcome! Kind regards, Laura=20 The SIP Alert-Info URN (SAIU) working group is chartered to define a new URN-scheme which allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN solves interoperability problems which we encounter today around the use of the Alert-Info header field for services as call waiting, call forwarding, blind transfer, automatic callback, call hold or emergency announcements sent over PBX systems. =20 RFC 3261 allows a UAS or proxy to provide a specific ring-/ringback-tone as a reference (e.g. HTTP URI) which can be played to the user in the Alert-Info header.=20 This mechanism does not ensure interoperability on the semantic level when there is no common understanding of the referenced content (different countries, hearing impaired) or when the user has his own tones configured in the end device. There are a variety of URI conventions and proprietary Alert-Info header field parameters to provide this today, all of which are non-interoperable. A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions. The group will produce: - A specification which describes the problem statement, the Alert-Info URN-scheme and defines the specific Alert-Info URNs identifiers to solve the known service interoperability problems.=20 Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 10 - Alert-Info URN specification to IESG (PS) From stpeter@stpeter.im Mon Sep 21 14:32:14 2009 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 AA91A3A680A for ; Mon, 21 Sep 2009 14:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=-0.269, 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 MjgV7QXQ98pn for ; Mon, 21 Sep 2009 14:32:13 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9BFCF3A68D0 for ; Mon, 21 Sep 2009 14:32:13 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C1F024007B; Mon, 21 Sep 2009 15:33:15 -0600 (MDT) Message-ID: <4AB7F11A.5040907@stpeter.im> Date: Mon, 21 Sep 2009 15:33:14 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 21 Sep 2009 21:32:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/21/09 6:28 AM, Simo.Veikkolainen@nokia.com wrote: > Hello, > > Below is the draft charter text for our proposal on combining SIP > voice with XMPP IM and presence. > > Comments are very welcome! Hi Simo, Do you think that this proposed working group would incorporate or complete work on the existing I-Ds I have listed below? http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media It would be nice to find a home for those I-Ds, and a focused group of people who want to finish them. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq38RoACgkQNL8k5A2w/vwgiACfUzJTMSaaH7hc+9u8JrPwgQ2S QQEAoMcAOMhkYNVHxNxJs7GIJye5XPoT =QMet -----END PGP SIGNATURE----- From jmpolk@cisco.com Mon Sep 21 16:02:11 2009 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 CCBAB3A6B37 for ; Mon, 21 Sep 2009 16:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 y-cxq4KWfE7Q for ; Mon, 21 Sep 2009 16:02:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C98133A6B35 for ; Mon, 21 Sep 2009 16:02:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAEOjt0qrR7PD/2dsb2JhbACIKLMUiFABjnUFhBuBXQ X-IronPort-AV: E=Sophos;i="4.44,426,1249257600"; d="scan'208";a="393183299" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2009 23:03:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n8LN3DAn003934; Mon, 21 Sep 2009 16:03:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8LN3DhD000553; Mon, 21 Sep 2009 23:03:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 16:03:13 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.47]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 16:03:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Sep 2009 18:03:09 -0500 To: Peter Saint-Andre , Simo.Veikkolainen@nokia.com From: "James M. Polk" In-Reply-To: <4AB7F11A.5040907@stpeter.im> References: <4AB7F11A.5040907@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 21 Sep 2009 23:03:12.0408 (UTC) FILETIME=[B19FF980:01CA3B0F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1763; t=1253574193; x=1254438193; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=20on=20 combining=20SIP=20voice=20with=0A=20=20XMPP=20IM=20and=09pre sence |Sender:=20; bh=L6JHQ7+0t5j9j+fmoX8yehh1t61IbyN5nlBDKB9Db5I=; b=M7+HZ3SBzPCsuMBc4EItQJgkCK3yJGSoL9vfAOp1T/Wk718sl1KgoZrvUw zOv+BGdQj/6vcnOGy+9VLDIxiqyJoTP8wjAhnnM/ovpl2qMp9IbIluUZB366 Cc61RFfeCA; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 21 Sep 2009 23:02:11 -0000 At 04:33 PM 9/21/2009, Peter Saint-Andre wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 9/21/09 6:28 AM, Simo.Veikkolainen@nokia.com wrote: > > Hello, > > > > Below is the draft charter text for our proposal on combining SIP > > voice with XMPP IM and presence. > > > > Comments are very welcome! > >Hi Simo, > >Do you think that this proposed working group would incorporate or >complete work on the existing I-Ds I have listed below? > >http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core >http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence >http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im >http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat >http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat >http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media > >It would be nice to find a home for those I-Ds, and a focused group of >people who want to finish them. +1 to what Peter asked. I'd like to add a comment about the charter as written emphasizing "SIP voice" at the expense of "SIP video" (i.e., there is no mention of video)... Since SIP doesn't care which codec(s) are in the offer/answer exchange, video needs to be stated explicitly if voice is called out. James >Peter > >- -- >Peter Saint-Andre >https://stpeter.im/ > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.8 (Darwin) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iEYEARECAAYFAkq38RoACgkQNL8k5A2w/vwgiACfUzJTMSaaH7hc+9u8JrPwgQ2S >QQEAoMcAOMhkYNVHxNxJs7GIJye5XPoT >=QMet >-----END PGP SIGNATURE----- >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Mon Sep 21 20:17:21 2009 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 EBFBB3A698E for ; Mon, 21 Sep 2009 20:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 6LSO2ffIGODS for ; Mon, 21 Sep 2009 20:17:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 079D83A67D9 for ; Mon, 21 Sep 2009 20:17:20 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8M3IL5S030036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Sep 2009 22:18:22 -0500 Message-Id: From: Dean Willis To: "" In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 22:18:15 -0500 References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 22 Sep 2009 03:17:22 -0000 On Sep 21, 2009, at 12:45 PM, wrote: > Hello, > > Please find below our charter proposal for the SIP Alert-Info URN. > > Comments are very welcome! > > Kind regards, > Laura > > > > The SIP Alert-Info URN (SAIU) working group is chartered to define a > new > URN-scheme which allows SIP to convey a particular alert indication > using a name instead of a referenced URI. The Alert-Info URN solves > interoperability problems which we encounter today around the use of > the > Alert-Info header field for services as call waiting, call forwarding, > blind transfer, automatic callback, call hold or emergency > announcements > sent over PBX systems. > > RFC 3261 allows a UAS or proxy to provide a specific ring-/ringback- > tone > as a reference (e.g. HTTP URI) which can be played to the user in the > Alert-Info header. > This mechanism does not ensure interoperability on the semantic level > when there is no common understanding of the referenced content > (different countries, hearing impaired) or when the user has his own > tones configured in the end device. There are a variety of URI > conventions and proprietary Alert-Info header field parameters to > provide this today, all of which are non-interoperable. A > standardized > set of Alert-Info URNs will increase SIP interoperability for this > header field by replacing proprietary conventions. > > The group will produce: > > - A specification which describes the problem statement, the Alert- > Info > URN-scheme and defines the specific Alert-Info URNs identifiers to > solve > the known service interoperability problems. > I think this is a very good idea for a short-lived, tightly-scoped working group, and I think the problem is valid and needs to be solved (indeed, every time one of the mobile standards groups tried to do something silly with ringtones, I suggested they look at alert-info). I'd like the proposed charter text to g into a little more depth about the "known service interoperability problems." Where are these being drawn from? Will the WG just reference an external spec for a list, or do we need to invent our own list and come to consensus on it? -- Dean From Even.roni@huawei.com Mon Sep 21 23:18:06 2009 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 B1BA03A67AA for ; Mon, 21 Sep 2009 23:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.893 X-Spam-Level: X-Spam-Status: No, score=0.893 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEdtSMNB+rK4 for ; Mon, 21 Sep 2009 23:18:05 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 77DF83A67D9 for ; Mon, 21 Sep 2009 23:18:05 -0700 (PDT) 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 <0KQD00FG607LZ8@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 14:18:58 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00HF807LMU@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 14:18:57 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-27-16.red.bezeqint.net [82.81.27.16]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQD00A4K07CWM@szxml01-in.huawei.com>; Tue, 22 Sep 2009 14:18:57 +0800 (CST) Date: Tue, 22 Sep 2009 09:16:41 +0300 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Message-id: <004401ca3b4c$44d0ac40$ce7204c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=US-ASCII Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Aco6tw6oxGz5jEN/RkOzR8EDleQxZwAk5wjA References: Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 06:18:06 -0000 Hi, I see similarity in the objectives to the disaggregated media discussed in a separate thread, see my inline comments in the objectives. I believe that there is a general case here and not only a specific use case. The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on - addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically. Roni: Same in disaggregated media where you have two separate call legs that you want to look like one - session correlation; endpoints need to be able to correlate voice sessions with IM/Presence such that they can be presented to the end user in a seamless fashion Roni: need to correlate for example between a call on a Phone device and video from a conference room video system. The audio will be on the phone and the video on the room system with two SIP call legs. - presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain. Roni: In the disaggregated media case the calling user should be able to know if the called party can have a separate video call before trying to start the second call leg. Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Monday, September 21, 2009 3:29 PM > To: dispatch@ietf.org > Subject: [dispatch] Charter proposal on combining SIP voice with XMPP > IM and presence > > Hello, > > Below is the draft charter text for our proposal on combining SIP voice > with XMPP IM and presence. > > Comments are very welcome! > > Regards, > Simo > > > ----------------- > > > Combining SIP VoIP and XMPP IM/Presence > ======================================= > > Currently most standards-based Voice over IP (VoIP) deployments use the > Session Initiation Protocol (SIP). In addition to providing basic > voice service SIP has an extensive support for more advanced telephony > features including interworking with the traditional Public Switched > Telephone Network (PSTN). SIP is also gaining popularity in the field > of video communication. At the same time, the Extensible Messaging and > Presence Protocol (XMPP) is enjoying widespread usage in instant > messaging and presence services. > > Both SIP and XMPP offer extensions for voice as well as IM and presence > (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE > protocols). However, widespread deployment of these extensions has not > so far taken place. In order to speed up deployment of integrated VoIP > and IM systems, SIP based voice and XMPP based IM/Presence could be > combined in endpoints to offer a voice, IM and presence service without > any changes to existing SIP and XMPP service infrastrucure. > > The objective of this Working Group is to develop solutions for > combining SIP based voice with XMPP based IM and Presence such that a > unified user experience can be offered to end user. Specifically, > solutions are needed on > - addressing; end users should be able to initiate sessions to a user > identity in either SIP or XMPP domain. The corresponding user identity > in the other protocol domain needs to be learned automatically. > - session correlation; endpoints need to be able to correlate voice > sessions with IM/Presence such that they can be presented to the end > user in a seamless fashion > - presence; it should be possible to change the XMPP presence status > based on the user's activity in the SIP domain. > > The goal is to rely on existing service infrastructre, and new > requirements should be imposed only to the endpoint. > > Protocol interworking, that is, translation from one protocol to > another, is out of scope of this WG. > > Milestones > Feb 2010 Problem statement and use cases submitted to IESG as > Informational > Dec 2010 Specification on combining SIP based voice and XMPP based > IM/Presence in a seamless manner submitted to IESG as Proposed > Standard. > > ----------------- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Mon Sep 21 23:21:40 2009 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 EC3623A68C9 for ; Mon, 21 Sep 2009 23:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=1.658, BAYES_00=-2.599, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBhbkQTwALaM for ; Mon, 21 Sep 2009 23:21:40 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 07E9C3A6891 for ; Mon, 21 Sep 2009 23:21:40 -0700 (PDT) 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 <0KQD00LH40DTB2@szxga01-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 14:22:41 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00IE00DTVJ@szxga01-in.huawei.com> for dispatch@ietf.org; Tue, 22 Sep 2009 14:22:41 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-27-16.red.bezeqint.net [82.81.27.16]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQD000K40DL0P@szxml01-in.huawei.com>; Tue, 22 Sep 2009 14:22:41 +0800 (CST) Date: Tue, 22 Sep 2009 09:20:25 +0300 From: Roni Even In-reply-to: To: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Message-id: <004501ca3b4c$ca997b90$5fcc72b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=US-ASCII Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Aco6tw6oxGz5jEN/RkOzR8EDleQxZwAlXAxQ References: Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 06:21:41 -0000 Hi, The charter looks good, what I am missing is the multiparty issue. XMPP is used for a multiparty chat and I think that in that case the users will expect an audio/video conference to run in parallel Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Monday, September 21, 2009 3:29 PM > To: dispatch@ietf.org > Subject: [dispatch] Charter proposal on combining SIP voice with XMPP > IM and presence > > Hello, > > Below is the draft charter text for our proposal on combining SIP voice > with XMPP IM and presence. > > Comments are very welcome! > > Regards, > Simo > > > ----------------- > > > Combining SIP VoIP and XMPP IM/Presence > ======================================= > > Currently most standards-based Voice over IP (VoIP) deployments use the > Session Initiation Protocol (SIP). In addition to providing basic > voice service SIP has an extensive support for more advanced telephony > features including interworking with the traditional Public Switched > Telephone Network (PSTN). SIP is also gaining popularity in the field > of video communication. At the same time, the Extensible Messaging and > Presence Protocol (XMPP) is enjoying widespread usage in instant > messaging and presence services. > > Both SIP and XMPP offer extensions for voice as well as IM and presence > (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE > protocols). However, widespread deployment of these extensions has not > so far taken place. In order to speed up deployment of integrated VoIP > and IM systems, SIP based voice and XMPP based IM/Presence could be > combined in endpoints to offer a voice, IM and presence service without > any changes to existing SIP and XMPP service infrastrucure. > > The objective of this Working Group is to develop solutions for > combining SIP based voice with XMPP based IM and Presence such that a > unified user experience can be offered to end user. Specifically, > solutions are needed on > - addressing; end users should be able to initiate sessions to a user > identity in either SIP or XMPP domain. The corresponding user identity > in the other protocol domain needs to be learned automatically. > - session correlation; endpoints need to be able to correlate voice > sessions with IM/Presence such that they can be presented to the end > user in a seamless fashion > - presence; it should be possible to change the XMPP presence status > based on the user's activity in the SIP domain. > > The goal is to rely on existing service infrastructre, and new > requirements should be imposed only to the endpoint. > > Protocol interworking, that is, translation from one protocol to > another, is out of scope of this WG. > > Milestones > Feb 2010 Problem statement and use cases submitted to IESG as > Informational > Dec 2010 Specification on combining SIP based voice and XMPP based > IM/Presence in a seamless manner submitted to IESG as Proposed > Standard. > > ----------------- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Mon Sep 21 23:56:52 2009 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 D4B723A6962 for ; Mon, 21 Sep 2009 23:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_SE=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 ioQyrHAxICur for ; Mon, 21 Sep 2009 23:56:52 -0700 (PDT) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id ECB513A67B5 for ; Mon, 21 Sep 2009 23:56:51 -0700 (PDT) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 80CDE28443; Tue, 22 Sep 2009 08:39:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Olle E. Johansson" In-Reply-To: Date: Tue, 22 Sep 2009 08:57:52 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Henry Sinnreich X-Mailer: Apple Mail (2.1075.2) Cc: "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" , "Markus.Isomaki@nokia.com" , "Simo.Veikkolainen@nokia.com" , Dan Wing Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 22 Sep 2009 06:56:52 -0000 21 sep 2009 kl. 15.21 skrev Henry Sinnreich: > On 9/20/09 10:20 PM, "Dan Wing" wrote: > > >So XMPP has to use E.164's (like SIP deployments do), or SIP > >will have to switch to user@host. I don't forsee either happening. > >If this is deemed necessary then we will have to map between them > >-- somehow. Send an XMPP message asking "what is your phone > >number" (in a computer-parsable manner), perhaps? > > Now why could not the application query the address book to get both > the E.164 addresses and user@host addresses? Most jabber servers have vcard support that could include both SIP and XMPP uri's. I don't know if SIP has it, but one could certainly involve LDAP for finding stuff like this. /O From lorenzo@meetecho.com Tue Sep 22 02:10:56 2009 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 2D64F3A69CC for ; Tue, 22 Sep 2009 02:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.036 X-Spam-Level: X-Spam-Status: No, score=0.036 tagged_above=-999 required=5 tests=[AWL=0.755, 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 DLyO3BOIlEUs for ; Tue, 22 Sep 2009 02:10:55 -0700 (PDT) Received: from smtp5.aruba.it (smtp7.aruba.it [62.149.128.206]) by core3.amsl.com (Postfix) with SMTP id 8EA173A69CA for ; Tue, 22 Sep 2009 02:10:54 -0700 (PDT) Received: (qmail 29111 invoked by uid 89); 22 Sep 2009 09:11:54 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.172) by smtp5.aruba.it with SMTP; 22 Sep 2009 09:11:54 -0000 Date: Tue, 22 Sep 2009 11:11:23 +0200 From: Lorenzo Miniero To: "Vijay K. Gurbani" Message-Id: <20090922111123.fd4c0c36.lorenzo@meetecho.com> In-Reply-To: <4AB780B4.3000601@alcatel-lucent.com> References: <4AB780B4.3000601@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.aruba.it 1.6.2 0/1000/N Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter proposal: Session Recording Protocol 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, 22 Sep 2009 09:10:56 -0000 On Mon, 21 Sep 2009 08:33:40 -0500 "Vijay K. Gurbani" wrote: > Hi: The following charter proposal is a continuation of the > work presented on the same topic (SIP Session Recording) > at the Stockholm IETF. > > Regards, > > The Session Recording Protocol (SRP) working group is chartered to > define a SIP-based protocol for controlling a session (media) recorder. > > Session recording is a critical requirement in many business > communications environments such as call centers and financial trading > floors. In some of these environments, all calls must be recorded for > regulatory and compliance reasons. In others, calls may be recorded for > quality control, business analytics, or consumer protection. Recording > is typically done by sending a copy of the media to the recording > devices. The working group will produce a specification for a protocol > that will manage delivery of media from an end-point that originates > media or that has access to it to a recording device. PBX and recording > vendors today implement proprietary, incompatible mechanisms to > facilitate recording. A standard protocol will reduce the complexity and > cost of providing such recording services. > > The Session Recording problem presents certain unique requirements that > are not addressed in the current SIP protocol specification. These > include requirements such as the need for a distinction between the > session that is being recorded versus the session that has been > established for recording. > > The SRP Working Group will thoroughly identify use cases, provide > example system architectures and deployment scenarios, and define > requirements. > > The scope of the activity includes: > > * Recorder Control > * Session metadata content and format > * Security mechanisms, including transport and media encryption > * Negotiation of recording media streams > > Privacy and security of conversations are significant concerns. The > group will define these issues and rationalize with IETF standards and > practices. This includes privacy concerns (including RAVEN), encryption, > NAT traversal, SIP-enabled firewalls, authorization, and security. > > The group will produce: > > * Updated Requirements, Use Cases, Architecture draft > * Specification for Session Recording Protocol > > Timeline: > > Apr 2010 Requirements, Use Cases, Architecture to IESG as > Informational Draft > > Nov 2010 Submit protocol draft to IESG as standards track > > - 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 > Hi Vijay, as a group we find this subject very interesting, and so we definitely support the charter proposal. We have a related draft on session recording (even though it's quite focused on conferencing at the moment) http://tools.ietf.org/html/draft-romano-dcon-recording-00 so we'd be glad to contribute to the work to be done in here. Lorenzo -- Lorenzo Miniero From Markus.Isomaki@nokia.com Tue Sep 22 04:15:58 2009 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 554543A6A0B for ; Tue, 22 Sep 2009 04:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 waDI3cBmUgTp for ; Tue, 22 Sep 2009 04:15:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 47AF03A6806 for ; Tue, 22 Sep 2009 04:15:57 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8MBGYH7006146; Tue, 22 Sep 2009 14:16:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 14:16:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 14:16:47 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 22 Sep 2009 13:16:38 +0200 From: To: , , Date: Tue, 22 Sep 2009 13:16:29 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco7D7ejgeRADw1wT4qBb5cGJpD50wAYsuXQ Message-ID: References: <4AB7F11A.5040907@stpeter.im> 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 X-OriginalArrivalTime: 22 Sep 2009 11:16:47.0144 (UTC) FILETIME=[2C73B280:01CA3B76] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 11:15:58 -0000 Hi James,=20 James M. Polk wrote: > >I'd like to add a comment about the charter as written=20 >emphasizing "SIP voice" at the expense of "SIP video" (i.e.,=20 >there is no mention of video)... > >Since SIP doesn't care which codec(s) are in the offer/answer=20 >exchange, video needs to be stated explicitly if voice is called out. > >James > I agree. I think we can pretty much replace "voice" with "voice and video" = throughout the charter. The reason voice was emphasized was simply due to its dominance over video = in current SIP deployments. However, if we look at the potential framework = for combined use of SIP and XMPP, it's quite clear that the setup of video = sessions would belong into the domain of SIP. There's no technical differen= ce between voice and video in this regard. Markus From emil@sip-communicator.org Tue Sep 22 04:59:44 2009 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 F04CA3A6975 for ; Tue, 22 Sep 2009 04:59:43 -0700 (PDT) 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 RgYp0B8NM368 for ; Tue, 22 Sep 2009 04:59:42 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 4965F3A692C for ; Tue, 22 Sep 2009 04:59:42 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so990285fga.13 for ; Tue, 22 Sep 2009 05:00:41 -0700 (PDT) Received: by 10.86.230.27 with SMTP id c27mr765318fgh.63.1253620841410; Tue, 22 Sep 2009 05:00:41 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id l12sm2708637fgb.4.2009.09.22.05.00.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Sep 2009 05:00:40 -0700 (PDT) Sender: Emil Ivov Message-ID: <4AB8BC67.3080702@sip-communicator.org> Date: Tue, 22 Sep 2009 14:00:39 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 11:59:44 -0000 Hey Simo, We've been considering and playing a similar mode of operation for a couple of years now and some of the most delicate issues that we've come across include "disambiguation of overlapping services and information" and "behaviour in cases of "half-failure". Here's what I mean: What happens for example if a mixed client receives a message over SIMPLE rather than XMPP. Should it be accepted and displayed to the user? If yes, then where should a client reply (i.e. SIMPLE or XMPP)? If we choose SIMPLE for how long should the client privilege SIMPLE over XMPP and under what conditions. What happens if a mixed client detects presence agent capabilities in a SIP service? Should it ignore them and only go for XMPP, use them for certain destinations only (e.g. destinations that we only have a SIP address for such as conventional SIP phones), or duplicate all information over the two protocols in which case: How should clients handle conflicting presence information received via the two protocols? How should we handle failures for only one of the services. For example: I am a mixed UA and am unable to connect to a SIP registrar but can still use XMPP. Should I declare complete failure to the user? Should I declare success but warn the user that some features won't work? If possible, should I try to make up for the missing SIP services using XMPP (and vice versa). So, if you think the above are worth considering how about adding something along these lines: disambiguation: both XMPP and SIP define semantics that allow each of the protocols to offer the complete set of services discussed in this charter (i.e. voice, video, messaging, and presence). In environments where one or more of these services are supported with both protocols clients should be able to use a common procedure for determining which one to use and under what conditions. half-failures: in cases where use of one of the protocols becomes impossible (e.g. due to a server failure) clients should be able to follow clear procedures on how to behave, which services could they try to reuse over the protocol that is still available and under what conditions. WDYT? Emil Simo.Veikkolainen@nokia.com wrote: > Hello, > > Below is the draft charter text for our proposal on combining SIP voice with XMPP IM and presence. > > Comments are very welcome! > > Regards, > Simo > > > ----------------- > > > Combining SIP VoIP and XMPP IM/Presence > ======================================= > > Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP). In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN). SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services. > > Both SIP and XMPP offer extensions for voice as well as IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastrucure. > > The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on > - addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically. > - session correlation; endpoints need to be able to correlate voice sessions with IM/Presence such that they can be presented to the end user in a seamless fashion > - presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain. > > The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint. > > Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG. > > Milestones > Feb 2010 Problem statement and use cases submitted to IESG as Informational > Dec 2010 Specification on combining SIP based voice and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard. > > ----------------- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- 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 pkyzivat@cisco.com Tue Sep 22 06:22:55 2009 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 88BC53A6A55 for ; Tue, 22 Sep 2009 06:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 GpHyaqQKy4Nz for ; Tue, 22 Sep 2009 06:22:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DB0903A69D0 for ; Tue, 22 Sep 2009 06:22:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJNsuEpAZnmf/2dsb2JhbAC/NIhPARCPYAWCIwsFgWiLCw X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="59318447" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Sep 2009 13:23:57 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8MDNvuG002841; Tue, 22 Sep 2009 09:23:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8MDNutA002097; Tue, 22 Sep 2009 13:23:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:23:56 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:23:56 -0400 Message-ID: <4AB8CFEC.8020703@cisco.com> Date: Tue, 22 Sep 2009 09:23:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emil Ivov References: <4AB8BC67.3080702@sip-communicator.org> In-Reply-To: <4AB8BC67.3080702@sip-communicator.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2009 13:23:56.0304 (UTC) FILETIME=[EFC92100:01CA3B87] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5206; t=1253625837; x=1254489837; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=20on=20 combining=20SIP=20voice=20with=20XMPP=0A=20IM=20and=09presen ce |Sender:=20 |To:=20Emil=20Ivov=20; bh=3i5hlsATbMxbsaLRWZxG6JGZXCuzBWHkPm0BbYV5yX8=; b=fBf0MD67eDZkvht1wqkQxp7ZOMzt19s0YI+aG9jGGV2+fs+RfKPIf+HY/0 UveIKTwPjEiGYJALeDmjnlDyLEYSZWXD9mr/j6gEsUtVnmQl/zuhumKLY03O whxBcVa34W; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 13:22:55 -0000 The issues Emil raises are good ones. I think they should be in scope for this effort. Thanks, Paul Emil Ivov wrote: > Hey Simo, > > We've been considering and playing a similar mode of operation for a > couple of years now and some of the most delicate issues that we've come > across include "disambiguation of overlapping services and information" > and "behaviour in cases of "half-failure". Here's what I mean: > > What happens for example if a mixed client receives a message over > SIMPLE rather than XMPP. Should it be accepted and displayed to the > user? If yes, then where should a client reply (i.e. SIMPLE or XMPP)? If > we choose SIMPLE for how long should the client privilege SIMPLE over > XMPP and under what conditions. > > What happens if a mixed client detects presence agent capabilities in a > SIP service? Should it ignore them and only go for XMPP, use them for > certain destinations only (e.g. destinations that we only have a SIP > address for such as conventional SIP phones), or duplicate all > information over the two protocols in which case: How should clients > handle conflicting presence information received via the two protocols? > > How should we handle failures for only one of the services. For example: > I am a mixed UA and am unable to connect to a SIP registrar but can > still use XMPP. Should I declare complete failure to the user? Should I > declare success but warn the user that some features won't work? If > possible, should I try to make up for the missing SIP services using > XMPP (and vice versa). > > So, if you think the above are worth considering how about adding > something along these lines: > > disambiguation: both XMPP and SIP define semantics that allow each of > the protocols to offer the complete set of services discussed in this > charter (i.e. voice, video, messaging, and presence). In environments > where one or more of these services are supported with both protocols > clients should be able to use a common procedure for determining which > one to use and under what conditions. > > half-failures: in cases where use of one of the protocols becomes > impossible (e.g. due to a server failure) clients should be able to > follow clear procedures on how to behave, which services could they try > to reuse over the protocol that is still available and under what > conditions. > > WDYT? > > Emil > > > Simo.Veikkolainen@nokia.com wrote: >> Hello, >> >> Below is the draft charter text for our proposal on combining SIP voice with XMPP IM and presence. >> >> Comments are very welcome! >> >> Regards, >> Simo >> >> >> ----------------- >> >> >> Combining SIP VoIP and XMPP IM/Presence >> ======================================= >> >> Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP). In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN). SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services. >> >> Both SIP and XMPP offer extensions for voice as well as IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastrucure. >> >> The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on >> - addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically. >> - session correlation; endpoints need to be able to correlate voice sessions with IM/Presence such that they can be presented to the end user in a seamless fashion >> - presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain. >> >> The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint. >> >> Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG. >> >> Milestones >> Feb 2010 Problem statement and use cases submitted to IESG as Informational >> Dec 2010 Specification on combining SIP based voice and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard. >> >> ----------------- >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From pkyzivat@cisco.com Tue Sep 22 06:24:33 2009 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 983AF3A68A7 for ; Tue, 22 Sep 2009 06:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 Td5DxOLbO-eB for ; Tue, 22 Sep 2009 06:24:32 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 604BE3A676A for ; Tue, 22 Sep 2009 06:24:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIJtuEpAZnme/2dsb2JhbAC/O4hPAY9vBYIjCwWBaIsL X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="59319893" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Sep 2009 13:25:35 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8MDPZa1003227; Tue, 22 Sep 2009 09:25:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8MDPZXT025939; Tue, 22 Sep 2009 13:25:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:25:35 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:25:35 -0400 Message-ID: <4AB8D050.1000708@cisco.com> Date: Tue, 22 Sep 2009 09:25:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Roni Even References: <004501ca3b4c$ca997b90$5fcc72b0$%roni@huawei.com> In-Reply-To: <004501ca3b4c$ca997b90$5fcc72b0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2009 13:25:35.0053 (UTC) FILETIME=[2AA507D0:01CA3B88] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3649; t=1253625935; x=1254489935; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=20on=20 combining=20SIP=20voice=20with=20XMPP=0A=20IM=20and=09presen ce |Sender:=20 |To:=20Roni=20Even=20; bh=JauRZ/9C9SmPUh9OYtDtgpSdw9fizg7l/rHETc3yPEE=; b=YnVnuuduaCvroyIEwqzfhQf0JPw01q+veFsHgcUNegHcl9q+UrT8korOGd SJVsxGIZG+xUQQ0drBxT+FuVih9mFhwKb94e/xi5ZmsRjF4i6MJmem1C715d YBoRLfewsO; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 13:24:33 -0000 Roni Even wrote: > Hi, > The charter looks good, what I am missing is the multiparty issue. XMPP is > used for a multiparty chat and I think that in that case the users will > expect an audio/video conference to run in parallel Agree. Similarly, other features will also be expected to work, such as transfer. Thanks, Paul > Roni Even > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Simo.Veikkolainen@nokia.com >> Sent: Monday, September 21, 2009 3:29 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Charter proposal on combining SIP voice with XMPP >> IM and presence >> >> Hello, >> >> Below is the draft charter text for our proposal on combining SIP voice >> with XMPP IM and presence. >> >> Comments are very welcome! >> >> Regards, >> Simo >> >> >> ----------------- >> >> >> Combining SIP VoIP and XMPP IM/Presence >> ======================================= >> >> Currently most standards-based Voice over IP (VoIP) deployments use the >> Session Initiation Protocol (SIP). In addition to providing basic >> voice service SIP has an extensive support for more advanced telephony >> features including interworking with the traditional Public Switched >> Telephone Network (PSTN). SIP is also gaining popularity in the field >> of video communication. At the same time, the Extensible Messaging and >> Presence Protocol (XMPP) is enjoying widespread usage in instant >> messaging and presence services. >> >> Both SIP and XMPP offer extensions for voice as well as IM and presence >> (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE >> protocols). However, widespread deployment of these extensions has not >> so far taken place. In order to speed up deployment of integrated VoIP >> and IM systems, SIP based voice and XMPP based IM/Presence could be >> combined in endpoints to offer a voice, IM and presence service without >> any changes to existing SIP and XMPP service infrastrucure. >> >> The objective of this Working Group is to develop solutions for >> combining SIP based voice with XMPP based IM and Presence such that a >> unified user experience can be offered to end user. Specifically, >> solutions are needed on >> - addressing; end users should be able to initiate sessions to a user >> identity in either SIP or XMPP domain. The corresponding user identity >> in the other protocol domain needs to be learned automatically. >> - session correlation; endpoints need to be able to correlate voice >> sessions with IM/Presence such that they can be presented to the end >> user in a seamless fashion >> - presence; it should be possible to change the XMPP presence status >> based on the user's activity in the SIP domain. >> >> The goal is to rely on existing service infrastructre, and new >> requirements should be imposed only to the endpoint. >> >> Protocol interworking, that is, translation from one protocol to >> another, is out of scope of this WG. >> >> Milestones >> Feb 2010 Problem statement and use cases submitted to IESG as >> Informational >> Dec 2010 Specification on combining SIP based voice and XMPP based >> IM/Presence in a seamless manner submitted to IESG as Proposed >> Standard. >> >> ----------------- >> _______________________________________________ >> 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 Sep 22 06:30:48 2009 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 E7DF73A69EB for ; Tue, 22 Sep 2009 06:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 MXnDUpMWrkET for ; Tue, 22 Sep 2009 06:30:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 72FF53A67A6 for ; Tue, 22 Sep 2009 06:30:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMFADFvuEqrR7MV/2dsb2JhbACNNbIJiE8Bj28FgiMLBYFoiws X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="393582738" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 13:31:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8MDVo8B000396; Tue, 22 Sep 2009 06:31:50 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8MDVnL7009474; Tue, 22 Sep 2009 13:31:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:31:42 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:31:42 -0400 Message-ID: <4AB8D1C0.3030907@cisco.com> Date: Tue, 22 Sep 2009 09:31:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Roni Even References: <004401ca3b4c$44d0ac40$ce7204c0$%roni@huawei.com> In-Reply-To: <004401ca3b4c$44d0ac40$ce7204c0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2009 13:31:42.0403 (UTC) FILETIME=[059A3130:01CA3B89] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5404; t=1253626310; x=1254490310; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=20on=20 combining=20SIP=20voice=20with=20XMPP=0A=20IM=20and=09presen ce |Sender:=20; bh=v4M6ihNzDccr840w5wqcJRpxXS1fG2MuEQSikUok8Q8=; b=lxDd0ta0Jrg0DV97UuBf1HiSeMTC8sdNQO0ijr0yPi6Qn7BQAeQIPbHXAj iV+5WhGqEdUu2tIaXgDwBAjCLb2vI7fqXKfKri7ZsThvfa/kwyuRj2Zbjmf/ LGBN0te94Njj+/9XNziGL4M4jhg9K/W+xEkIGRa/tjrXdL/lF9Rpc=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 13:30:49 -0000 Roni Even wrote: > Hi, > I see similarity in the objectives to the disaggregated media discussed in a > separate thread, see my inline comments in the objectives. I believe that > there is a general case here and not only a specific use case. > > The objective of this Working Group is to develop solutions for combining > SIP based voice with XMPP based IM and Presence such that a unified user > experience can be offered to end user. Specifically, solutions are needed on > - addressing; end users should be able to initiate sessions to a user > identity in either SIP or XMPP domain. The corresponding user identity in > the other protocol domain needs to be learned automatically. > > Roni: Same in disaggregated media where you have two separate call legs that > you want to look like one > > - session correlation; endpoints need to be able to correlate voice sessions > with IM/Presence such that they can be presented to the end user in a > seamless fashion > > Roni: need to correlate for example between a call on a Phone device and > video from a conference room video system. The audio will be on the phone > and the video on the room system with two SIP call legs. > > - presence; it should be possible to change the XMPP presence status based > on the user's activity in the SIP domain. > > Roni: In the disaggregated media case the calling user should be able to > know if the called party can have a separate video call before trying to > start the second call leg. I've been arguing that in the all-sip case the burden of aggregating the disparate media/devices should fall on the end that wants it, not on the other end that is happy to have a single multimedia session. That eliminates the question of whether the called party can support a separate video call. That of course doesn't work when aggregating two protocols that different approaches to session initiation, such as SIP and XMPP. (Unless one can function as a subordinate to the other, such as negotiating an "XMPP session" using sip. Thanks, Paul > Roni Even > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Simo.Veikkolainen@nokia.com >> Sent: Monday, September 21, 2009 3:29 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Charter proposal on combining SIP voice with XMPP >> IM and presence >> >> Hello, >> >> Below is the draft charter text for our proposal on combining SIP voice >> with XMPP IM and presence. >> >> Comments are very welcome! >> >> Regards, >> Simo >> >> >> ----------------- >> >> >> Combining SIP VoIP and XMPP IM/Presence >> ======================================= >> >> Currently most standards-based Voice over IP (VoIP) deployments use the >> Session Initiation Protocol (SIP). In addition to providing basic >> voice service SIP has an extensive support for more advanced telephony >> features including interworking with the traditional Public Switched >> Telephone Network (PSTN). SIP is also gaining popularity in the field >> of video communication. At the same time, the Extensible Messaging and >> Presence Protocol (XMPP) is enjoying widespread usage in instant >> messaging and presence services. >> >> Both SIP and XMPP offer extensions for voice as well as IM and presence >> (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE >> protocols). However, widespread deployment of these extensions has not >> so far taken place. In order to speed up deployment of integrated VoIP >> and IM systems, SIP based voice and XMPP based IM/Presence could be >> combined in endpoints to offer a voice, IM and presence service without >> any changes to existing SIP and XMPP service infrastrucure. >> >> The objective of this Working Group is to develop solutions for >> combining SIP based voice with XMPP based IM and Presence such that a >> unified user experience can be offered to end user. Specifically, >> solutions are needed on >> - addressing; end users should be able to initiate sessions to a user >> identity in either SIP or XMPP domain. The corresponding user identity >> in the other protocol domain needs to be learned automatically. >> - session correlation; endpoints need to be able to correlate voice >> sessions with IM/Presence such that they can be presented to the end >> user in a seamless fashion >> - presence; it should be possible to change the XMPP presence status >> based on the user's activity in the SIP domain. >> >> The goal is to rely on existing service infrastructre, and new >> requirements should be imposed only to the endpoint. >> >> Protocol interworking, that is, translation from one protocol to >> another, is out of scope of this WG. >> >> Milestones >> Feb 2010 Problem statement and use cases submitted to IESG as >> Informational >> Dec 2010 Specification on combining SIP based voice and XMPP based >> IM/Presence in a seamless manner submitted to IESG as Proposed >> Standard. >> >> ----------------- >> _______________________________________________ >> 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 Sep 22 06:36:29 2009 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 B4FCB3A6A38 for ; Tue, 22 Sep 2009 06:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 F4rrthX9BoLq for ; Tue, 22 Sep 2009 06:36:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BFE4F3A6A0B for ; Tue, 22 Sep 2009 06:36:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABxwuEpAZnme/2dsb2JhbAC/Q4hPAY9vBYQb X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="59320841" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Sep 2009 13:37:32 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8MDbWcS012351; Tue, 22 Sep 2009 09:37:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8MDbWwW009155; Tue, 22 Sep 2009 13:37:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:37:31 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:37:31 -0400 Message-ID: <4AB8D31D.3010302@cisco.com> Date: Tue, 22 Sep 2009 09:37:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Olle E. Johansson" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2009 13:37:31.0472 (UTC) FILETIME=[D5A9E500:01CA3B89] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1373; t=1253626652; x=1254490652; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20New=20topic=20proposal=20f or=20DISPATCH |Sender:=20 |To:=20=22Olle=20E.=20Johansson=22=20; bh=CrF2+szt4z/e3aMHTsjCJTVMaMauwbsx/47FhUZL//g=; b=NCEEszSB7MdWb7s2GdybArhNJPt/BwIMAC5fkFDABHeX8DwvgEB2LxEpMF JqWbdSVFzzZABfvKLICQr9XLNWTL1YeqvJDjTxdghMVkrSsYNPimvJLaJjcl PoHG8rml+2; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" , "Simo.Veikkolainen@nokia.com" , "Markus.Isomaki@nokia.com" , Henry Sinnreich Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 22 Sep 2009 13:36:29 -0000 AFAIK this is only a solution to the extent that I possess such info about the other party in the call. IM has evolved in such a way that typically you are only allowed to IM people you "know", so info is available locally about the other party. But the same is not true of telephony, where often the *only* information you have about the other party is the phone number. (Or AOR.) So while looking things up in your address book could provide some useful fallback behavior, I don't think it is a complete solution. Thanks, Paul Olle E. Johansson wrote: > > 21 sep 2009 kl. 15.21 skrev Henry Sinnreich: > >> On 9/20/09 10:20 PM, "Dan Wing" wrote: >> >> >So XMPP has to use E.164's (like SIP deployments do), or SIP >> >will have to switch to user@host. I don't forsee either happening. >> >If this is deemed necessary then we will have to map between them >> >-- somehow. Send an XMPP message asking "what is your phone >> >number" (in a computer-parsable manner), perhaps? >> >> Now why could not the application query the address book to get both >> the E.164 addresses and user@host addresses? > Most jabber servers have vcard support that could include both SIP and > XMPP uri's. > > I don't know if SIP has it, but one could certainly involve LDAP for > finding stuff like this. > > /O > > From dromasca@avaya.com Tue Sep 22 06:42:22 2009 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 6901928C10E for ; Tue, 22 Sep 2009 06:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 bsix-ABhIxFz for ; Tue, 22 Sep 2009 06:42:21 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 94FF028B23E for ; Tue, 22 Sep 2009 06:42:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,431,1249272000"; d="scan'208";a="174211348" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 22 Sep 2009 09:43:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Sep 2009 09:43:22 -0400 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, 22 Sep 2009 15:43:08 +0200 Message-ID: In-Reply-To: <4AB7F11A.5040907@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence thread-index: Aco7AyVI15FXuEcnSeSYFWHvGigIGwAh1Smg References: <4AB7F11A.5040907@stpeter.im> From: "Romascanu, Dan (Dan)" To: "Peter Saint-Andre" , Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 13:42:22 -0000 How would this work relate to the item in the XMPP WG charter? =20 > Many of the core and extended features of XMPP have also been implemented in technologies based on the Session Initiation Protocol (SIP). To ensure interworking between XMPP systems and SIP systems, a number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been produced. The group will define a framework within which this work could be completed. Dan > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: Tuesday, September 22, 2009 12:33 AM > To: Simo.Veikkolainen@nokia.com > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal on combining SIP=20 > voice with XMPP IM and presence >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 9/21/09 6:28 AM, Simo.Veikkolainen@nokia.com wrote: > > Hello, > >=20 > > Below is the draft charter text for our proposal on combining SIP=20 > > voice with XMPP IM and presence. > >=20 > > Comments are very welcome! >=20 > Hi Simo, >=20 > Do you think that this proposed working group would=20 > incorporate or complete work on the existing I-Ds I have listed below? >=20 > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media >=20 > It would be nice to find a home for those I-Ds, and a focused=20 > group of people who want to finish them. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkq38RoACgkQNL8k5A2w/vwgiACfUzJTMSaaH7hc+9u8JrPwgQ2S > QQEAoMcAOMhkYNVHxNxJs7GIJye5XPoT > =3DQMet > -----END PGP SIGNATURE----- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From Markus.Isomaki@nokia.com Tue Sep 22 06:43:25 2009 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 85A433A6964 for ; Tue, 22 Sep 2009 06:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 z5Ravy6mwGh3 for ; Tue, 22 Sep 2009 06:43:24 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 7DE4828C136 for ; Tue, 22 Sep 2009 06:43:23 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8MDhXdM008258; Tue, 22 Sep 2009 08:43:34 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 16:44:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 16:44:10 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 22 Sep 2009 15:44:10 +0200 From: To: , Date: Tue, 22 Sep 2009 15:44:08 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco7iEaIm7WJkpRnS/K3/01jlE4fjAAAT+oA Message-ID: References: <004501ca3b4c$ca997b90$5fcc72b0$%roni@huawei.com> <4AB8D050.1000708@cisco.com> In-Reply-To: <4AB8D050.1000708@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Sep 2009 13:44:10.0792 (UTC) FILETIME=[C3AD4A80:01CA3B8A] X-Nokia-AV: Clean Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 13:43:25 -0000 Hi,=20 Paul Kyzivat wrote: > >Roni Even wrote: >> Hi, >> The charter looks good, what I am missing is the multiparty issue.=20 >> XMPP is used for a multiparty chat and I think that in that case the=20 >> users will expect an audio/video conference to run in parallel > >Agree. > >Similarly, other features will also be expected to work, such=20 >as transfer. > We could add such things on the charter at later dates. I think it would be= important to get something concrete solved first, and preferably even impl= emented and deployed before going forward. Initially we should IMHO only ha= ve features that can be relatively easily implemented by using existing SIP= and XMPP client codebases. Otherwise we loose the whole point of this work= .=20 In general I agree that we need to have a way for the combined client to be= able to take part into a SIP based voice/video conference and XMPP based m= ultiparty IM chat and if the server side supports the proper extensions, ac= tually know that these two are part of the same multimedia conference. Perh= aps even the rosters can be correlated. But at least we shouldn't require t= he full XCON suite for this. Markus= From Hannes.Tschofenig@gmx.net Tue Sep 22 06:50:00 2009 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 A5C013A6A4E for ; Tue, 22 Sep 2009 06:50:00 -0700 (PDT) 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 GI2cI5bECOMe for ; Tue, 22 Sep 2009 06:49:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 514573A69C8 for ; Tue, 22 Sep 2009 06:49:58 -0700 (PDT) Received: (qmail invoked by alias); 22 Sep 2009 13:51:01 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp038) with SMTP; 22 Sep 2009 15:51:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/7KAFqFK/WC0nFV0Pk1PrFRn7uhL7Swgn6tPwCy ZZI1xY1SHkUP08 From: "Hannes Tschofenig" To: "'Paul Kyzivat'" , "'Roni Even'" References: <004401ca3b4c$44d0ac40$ce7204c0$%roni@huawei.com> <4AB8D1C0.3030907@cisco.com> Date: Tue, 22 Sep 2009 16:53:57 +0300 Message-ID: <000301ca3b8c$2259c850$9c5ba20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4AB8D1C0.3030907@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Aco7iQ20uyY0uFLwSsuxa5bRohQB3gAAqymQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 13:50:00 -0000 I have only followed parts of the email thread but I would favor of keeping the two efforts separately since the problem statements are quite different. Don't re-write them in a way that nobody understands them anymore. The SIP / XMPP interworking is also a topic of relevance today, i.e. not a research topic. From Markus.Isomaki@nokia.com Tue Sep 22 06:50:18 2009 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 7B06E3A6A4E for ; Tue, 22 Sep 2009 06:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 jKMrgIa67wIF for ; Tue, 22 Sep 2009 06:50:15 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 728A53A69E9 for ; Tue, 22 Sep 2009 06:50:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8MDn10D012774; Tue, 22 Sep 2009 08:50:27 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 16:51:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 16:51:04 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 22 Sep 2009 15:51:04 +0200 From: To: , , Date: Tue, 22 Sep 2009 15:51:02 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco7AyVI15FXuEcnSeSYFWHvGigIGwAh1SmgAAAZjuA= Message-ID: References: <4AB7F11A.5040907@stpeter.im> 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 X-OriginalArrivalTime: 22 Sep 2009 13:51:04.0570 (UTC) FILETIME=[BA4ECDA0:01CA3B8B] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 13:50:18 -0000 Hi, That's exactly the same work. I guess Peter is asking if that SIP-related w= ork could be moved from XMPP WG to happen together with the proposed SIP-XM= PP combined use work, as a new (mini-)WG for instance. To me Peter's request makes sense. Of course only if we manage to get the n= ew SIP/XMPP group setup.) It's a bit odd thing currently in XMPP WG. That's= the same reason we are bringing the SIP/XMPP combined use proposal to DISP= ATCH rather than XMPP WG, i.e. it does not really fit that well with the ot= her items XMPP WG is working on. Markus >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Romascanu,=20 >Dan (Dan) >Sent: 22 September, 2009 16:43 >To: Peter Saint-Andre; Veikkolainen Simo (Nokia-D/Helsinki) >Cc: dispatch@ietf.org >Subject: Re: [dispatch] Charter proposal on combining SIP=20 >voice with XMPP IM and presence > >How would this work relate to the item in the XMPP WG charter? =20 > >> Many of the core and extended features of XMPP have also been >implemented in technologies based on the Session Initiation=20 >Protocol (SIP). To ensure interworking between XMPP systems=20 >and SIP systems, a number of Internet-Drafts=20 >(draft-saintandre-sip-xmpp-*) have been produced. The group=20 >will define a framework within which this work could be completed. > >Dan > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Sent: Tuesday, September 22, 2009 12:33 AM >> To: Simo.Veikkolainen@nokia.com >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Charter proposal on combining SIP voice with=20 >> XMPP IM and presence >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 9/21/09 6:28 AM, Simo.Veikkolainen@nokia.com wrote: >> > Hello, >> >=20 >> > Below is the draft charter text for our proposal on combining SIP=20 >> > voice with XMPP IM and presence. >> >=20 >> > Comments are very welcome! >>=20 >> Hi Simo, >>=20 >> Do you think that this proposed working group would incorporate or=20 >> complete work on the existing I-Ds I have listed below? >>=20 >> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core >> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence >> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im >> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat >> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat >> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media >>=20 >> It would be nice to find a home for those I-Ds, and a=20 >focused group of=20 >> people who want to finish them. >>=20 >> Peter >>=20 >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>=20 >> iEYEARECAAYFAkq38RoACgkQNL8k5A2w/vwgiACfUzJTMSaaH7hc+9u8JrPwgQ2S >> QQEAoMcAOMhkYNVHxNxJs7GIJye5XPoT >> =3DQMet >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 Markus.Isomaki@nokia.com Tue Sep 22 07:04:45 2009 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 8373A3A69A7 for ; Tue, 22 Sep 2009 07:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 OmKuiYd4DrkA for ; Tue, 22 Sep 2009 07:04:44 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 753E13A691C for ; Tue, 22 Sep 2009 07:04:44 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8ME4prE025795; Tue, 22 Sep 2009 09:04:54 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 17:05:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 17:05:31 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 22 Sep 2009 16:05:30 +0200 From: To: , , Date: Tue, 22 Sep 2009 16:05:29 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco7iQ20uyY0uFLwSsuxa5bRohQB3gAAqymQAAAPEMA= Message-ID: References: <004401ca3b4c$44d0ac40$ce7204c0$%roni@huawei.com> <4AB8D1C0.3030907@cisco.com> <000301ca3b8c$2259c850$9c5ba20a@nsnintra.net> In-Reply-To: <000301ca3b8c$2259c850$9c5ba20a@nsnintra.net> 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-OriginalArrivalTime: 22 Sep 2009 14:05:31.0062 (UTC) FILETIME=[BEC6FD60:01CA3B8D] X-Nokia-AV: Clean Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 14:04:45 -0000 Hannes, Which two efforts are you talking about? At least three efforts have been b= rought up that have some relationship: 1. SIP and XMPP combined use (the charter proposed in this thread, draft-ve= ikkolainen-...)=20 2. SIP - XMPP interworking (already a WG item in XMPP WG, draft-saintandre-= sip-...) 3. Disaggregated media proposal (sent to DISPATCH by Salvatore Loreto) My take is that 1. and 2. are relatively orthogonal but probably the same s= et of people are interested in them. 1 and 3. are related in a sense that i= f we define some kind of session correlation header in SIP (to correlate tw= o or more SIP dialogs/sessions) we might ideally use the same for SIP/XMPP = correlation purposes. But that's a minor optimization and either work shoul= d not get stuck behind the other. There's still room for new SIP headers, r= ight :-) Markus >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Hannes Tschofenig >Sent: 22 September, 2009 16:54 >To: 'Paul Kyzivat'; 'Roni Even' >Cc: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >Subject: Re: [dispatch] Charter proposal on combining SIP=20 >voice with XMPP IM and presence > >I have only followed parts of the email thread but I would=20 >favor of keeping the two efforts separately since the problem=20 >statements are quite different. >Don't re-write them in a way that nobody understands them anymore.=20 > >The SIP / XMPP interworking is also a topic of relevance=20 >today, i.e. not a research topic.=20 > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch >= From Hannes.Tschofenig@gmx.net Tue Sep 22 07:07:22 2009 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 BDC213A68A7 for ; Tue, 22 Sep 2009 07:07:22 -0700 (PDT) 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 VyDa9jnArPTP for ; Tue, 22 Sep 2009 07:07:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4B26A3A681C for ; Tue, 22 Sep 2009 07:07:20 -0700 (PDT) Received: (qmail invoked by alias); 22 Sep 2009 14:08:24 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp069) with SMTP; 22 Sep 2009 16:08:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18H2bI0FygH2feUPQTad28AHoc0oeSrtxH1dZFuks 6vPXg3D9o+ykQS From: "Hannes Tschofenig" To: , , References: <004401ca3b4c$44d0ac40$ce7204c0$%roni@huawei.com><4AB8D1C0.3030907@cisco.com> <000301ca3b8c$2259c850$9c5ba20a@nsnintra.net> Date: Tue, 22 Sep 2009 17:11:20 +0300 Message-ID: <000401ca3b8e$8fa524c0$9c5ba20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Aco7iQ20uyY0uFLwSsuxa5bRohQB3gAAqymQAAAPEMAAAJlPQA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IMand presence 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, 22 Sep 2009 14:07:22 -0000 Sorry, I should have been more precise. I was referring to "SIP and XMPP combined use" and "Disaggregated media proposal". Even if we envision solutions to be similar (some form of SIP header) does not mean that they need to be mashed together. >-----Original Message----- >From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >Sent: 22 September, 2009 17:05 >To: Hannes.Tschofenig@gmx.net; pkyzivat@cisco.com; Even.roni@huawei.com >Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org >Subject: RE: [dispatch] Charter proposal on combining SIP >voice with XMPP IMand presence > >Hannes, > >Which two efforts are you talking about? At least three >efforts have been brought up that have some relationship: > >1. SIP and XMPP combined use (the charter proposed in this >thread, draft-veikkolainen-...) 2. SIP - XMPP interworking >(already a WG item in XMPP WG, draft-saintandre-sip-...) 3. >Disaggregated media proposal (sent to DISPATCH by Salvatore Loreto) > >My take is that 1. and 2. are relatively orthogonal but >probably the same set of people are interested in them. 1 and >3. are related in a sense that if we define some kind of >session correlation header in SIP (to correlate two or more >SIP dialogs/sessions) we might ideally use the same for >SIP/XMPP correlation purposes. But that's a minor optimization >and either work should not get stuck behind the other. There's >still room for new SIP headers, right :-) > >Markus > > >>-----Original Message----- >>From: dispatch-bounces@ietf.org >>[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Hannes Tschofenig >>Sent: 22 September, 2009 16:54 >>To: 'Paul Kyzivat'; 'Roni Even' >>Cc: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >>Subject: Re: [dispatch] Charter proposal on combining SIP voice with >>XMPP IM and presence >> >>I have only followed parts of the email thread but I would favor of >>keeping the two efforts separately since the problem statements are >>quite different. >>Don't re-write them in a way that nobody understands them anymore. >> >>The SIP / XMPP interworking is also a topic of relevance today, i.e. >>not a research topic. >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch >> > From L.Liess@telekom.de Tue Sep 22 07:11:33 2009 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 359803A67E7 for ; Tue, 22 Sep 2009 07:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=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 vHQ88uOr9UxS for ; Tue, 22 Sep 2009 07:11:32 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id D6E9D3A69A3 for ; Tue, 22 Sep 2009 07:11:31 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 22 Sep 2009 16:12:19 +0200 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, 22 Sep 2009 16:12:10 +0200 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, 22 Sep 2009 16:12:14 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal: SIP Alert-Info URN Thread-Index: Aco7M1qgAR7YOwIjS2GjsdGAd+15zgANCUCA References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> From: To: X-OriginalArrivalTime: 22 Sep 2009 14:12:10.0427 (UTC) FILETIME=[ACD140B0:01CA3B8E] Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 22 Sep 2009 14:11:33 -0000 Dean, Thank you for supporting the work. Please see answers in-line.=20 >=20 > I think this is a very good idea for a short-lived, tightly-scoped =20 > working group, and I think the problem is valid and needs to=20 > be solved =20 > (indeed, every time one of the mobile standards groups tried to do =20 > something silly with ringtones, I suggested they look at alert-info). >=20 > I'd like the proposed charter text to g into a little more=20 > depth about =20 > the "known service interoperability problems." Where are these being =20 > drawn from? The cases I know of are mainly the use-cases for which indications and sub-indications have been defined in=20 Sections 3 and 4. of http://www.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt . - For the call waiting supplementary service provided by carriers, there is a need for the callee's proxy informs the caller that the call is waiting. The callee's proxy must provide this information at a semantic to the caller's end device. A URI will not do it for different countries, hearing impaired and so on.=20 =20 - All other use cases in the draft came from Alan's implementation experience at Avaya and interoperability issues around the use of the=20 Alert-Info header field when not-using an external ring file. Here is Alan's text, which is not in the current version of the draft: =20 =20 For example, consider the PBX special ringtone for an external (to the PBX)=20 caller. Different vendors use different approaches such as: Alert-Info: ;alert=3Dnormal where ring.pcm is a = dummy file or: Alert-Info: or: Alert-Info: As a result, Alert-Info currently only works when the same vendor=20 provides proxy and UA, as only then is the same "fake" proprietary URI=20 convention is used. Also draft-ietf-bliss-shared-appearances needs to specify a default ringtone when using appearance Alert-Info parameter. =20 > Will the WG just reference an external spec for a=20 > list, or =20 > do we need to invent our own list and come to consensus on it? I intend to include the text above into the next version of the draft. Maybe a separate section in the draft on the problem statement and use cases would make sense.=20 My understanding from your mail way that you know of other use cases from other mobile standards group. Is that correct? If yes, does it make sense to consider them here? The syntax is open so people can add new labels.=20 In his message http://www.ietf.org/mail-archive/web/bliss/current/msg01020.html Adam raised the issue of the tones defined in TIA/EIA-41-D and 3GPP2 A.S0014. Personally, I don't have any experience with them. But, as John pointed out in http://www.ietf.org/mail-archive/web/bliss/current/msg01025.html, we should try to define names that reflect the meaning, rather than the representation, of a tone. I don't know anything about the meaning of Short-Short2. For my feeling, this are quite US specific and for my feeling URIs could be used in this case.=20 =20 Thanks a lot Laura >=20 > -- > Dean >=20 >=20 >=20 >=20 From enrico.marocco@telecomitalia.it Tue Sep 22 07:36:55 2009 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 41DF93A67DA for ; Tue, 22 Sep 2009 07:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.348, 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 4iHlI8HzItP8 for ; Tue, 22 Sep 2009 07:36:54 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id C62713A68A7 for ; Tue, 22 Sep 2009 07:36:53 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 22 Sep 2009 16:37:54 +0200 Received: from [163.162.173.6] (163.162.173.6) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Tue, 22 Sep 2009 16:37:54 +0200 Message-ID: <4AB8E15E.8070802@telecomitalia.it> Date: Tue, 22 Sep 2009 16:38:22 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020707000103080307060701" Cc: "dispatch@ietf.org" , Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS 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, 22 Sep 2009 14:36:55 -0000 --------------ms020707000103080307060701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christer, I see value in a general mechanism for selectively retrieve lists of URIs, but am wondering whether this is actually a charter proposal (in such case I guess the text requires heavy rewording, defining acronyms as a start) or just an event package registration request according to rfc3427bis, S.4.1? Enrico Christer Holmberg wrote: > > Hi, > > Below is the proposed charter for CBUS. > > Regards, > > Christer > > ----------------------------------------- > > CBUS Charter. > ============= > > Introduction: > ------------- > > Various OMA service enablers need to be able to retrieve a list of > addresses (URIs), where the users associated with the URIs fulfil > certain conditions. User information is evaluated against the > conditions, and the matches form a URI list. > > The need for the functionality originates from the OMA PoC service. > However, there is ongoing work in OMA to define a common mechanism, > called CBUS enabler (OMA-RD-CBUS-V1_0-20090203-C), to provide the > functionality, so that it can be used for various types of services > (e.g. messaging, gaming, conferencing and advertisement). > > The CBUS enabler provides the following functions: > > - Support for requestor initiated condition-based URIs selection requests. > > - Administration of conditions for URI selection. > > - Interaction with other enablers for retrieval of individual user's > information (e.g. presence information, location information). > > - Evaluation of conditions and selection of matching individual users > based on one time evaluation. > > - Re-evaluation of conditions and re-selection of matching individual > users based on monitoring. > > - Aggregation of one-time evaluation results and monitoring results > from different information sources. > > - Notification of evaluation results to requestor. > > The conditions can be based on user information which changes over time > (e.g. presence information or geographical location), but they can also > be based on more static user information (e.g. hobbies or personal > interests). > > The entity which acts as requester, and provides the conditions to be > used for the user information evaluation, is called CBUS client. The > CBUS client usually resides on the user equipment, or an application > server, which supports the CBUS enabler. > > The selection of URIs, based on the provided conditions, may be > performed by taking a snapshot, i.e. by making a one-time evaluation of > the user information to find out whether the conditions are fulfilled or > not. The URI selection may also be performed by continous monitoring of > the user information. > > > Work and deliverables: > ---------------------- > > The purpose of the work is to, based on the OMA CBUS requirements (OMA- > RD-CBUS-V1_0-20090203-C), procude the SIP protocol information elements > which are needed to implement the interface between the CBUS client and > CBUS server, using the SIP SUBSCRIBE/NOTIFY framework (RFC 3265). > > > The primary task for the work is to: > > 1. Procude a mechanism for a subscriber (CBUS client) to, when > subscribing to an event package which contains a list of URI, provide > conditions, candidate URIs and evaluation parameters to the notifier > (CBUS server). > > The mechanism may be used on defining an XML based message body type, > and SIP header field parameters. > > 2. Produce an event package, or possible re-use an existing event > package, used to the notifier (CBUS server) to send URI lists (based on > the conditions and candidate URIs) to the subscriber (CBUS client). > > The CBUS client actions triggered by the received URI list, and the > interactions between the CBUS server and other enablers, are outside the > scope of the work. > > > The work is planned to take place in, or in co-operaton with, the > SIPCORE WG. > > > Goals and milestones: > --------------------- > > Jan 2010 Working Group Last Call for the document which contains > the mechanism for a > subscriber to provide the needed CBUS information to the > notifier, and > contains the event package (if a new package is needed) for the > notifier to provide the URI list to the subscriber. > > Mar 2010 Submit document to IESG as Proposed Standard > --------------ms020707000103080307060701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5MjIxNDM4MjJaMCMG CSqGSIb3DQEJBDEWBBTqzz1USBqz7fZFAckw0hd2rvUFBjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAG6dK8S1kAXc QaTJLNj/e87P+nUtBeXjjdBEg9y3gAnnMZcOv0Am/oQM2Wec6eNgrE7Hwx40N/MZswYm3FxS tiRXqhRx5WuFh+/CR5DpiQRAOChzgdEHSOIZXKA4pYH1Qn2P3VYUzUOXQSKw9GovxC2CPOdp wlF1mfUmLp3SDXtg8AEClHDbXYfPl+qDgaY1gBEKz4y0G7CfNZPECovCez6T2FUmFtfyhhh7 zXuOghPOXPXpzZR7N/JRlvJPa8aZoi+s+VblHXywTWSsDXRGwfYgzbLefyf5FWs2PMhLQGaD isHRTgCSwajfIGoV+osSb+sBfFsiSXrDzo2yj2yRIFsAAAAAAAA= --------------ms020707000103080307060701-- From stpeter@stpeter.im Tue Sep 22 08:30:20 2009 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 600C63A680B for ; Tue, 22 Sep 2009 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.256, 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 M+GrC5c-GtdI for ; Tue, 22 Sep 2009 08:30:19 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 278AF28C137 for ; Tue, 22 Sep 2009 08:30:19 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2D0214007B; Tue, 22 Sep 2009 09:31:21 -0600 (MDT) Message-ID: <4AB8E99C.5080200@stpeter.im> Date: Tue, 22 Sep 2009 09:13:32 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4AB7F11A.5040907@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 15:30:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/09 7:43 AM, Romascanu, Dan (Dan) wrote: > How would this work relate to the item in the XMPP WG charter? > >> Many of the core and extended features of XMPP have also been > implemented in technologies based on the Session Initiation Protocol > (SIP). To ensure interworking between XMPP systems and SIP systems, a > number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been > produced. The group will define a framework within which this work could > be completed. Right, that refers to the drafts I noted in my previous message. As Simo points out, the same people would be interested in both the "combined SIP/XMPP" use cases and the "SIP/XMPP interworking" use cases. IMHO it would be more productive to complete the interworking tasks in a WG that is dedicated to SIP and XMPP, rather than in the XMPP WG. Peter > Dan > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Sent: Tuesday, September 22, 2009 12:33 AM >> To: Simo.Veikkolainen@nokia.com >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Charter proposal on combining SIP >> voice with XMPP IM and presence >> > On 9/21/09 6:28 AM, Simo.Veikkolainen@nokia.com wrote: >>>> Hello, >>>> >>>> Below is the draft charter text for our proposal on combining SIP >>>> voice with XMPP IM and presence. >>>> >>>> Comments are very welcome! > Hi Simo, > > Do you think that this proposed working group would > incorporate or complete work on the existing I-Ds I have listed below? > > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media > > It would be nice to find a home for those I-Ds, and a focused > group of people who want to finish them. > > Peter > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq46ZwACgkQNL8k5A2w/vygeACaAwTLZ/dPKqe6/WibhBe+wwGe gHAAnRS7DqTRq8BE4MLVqTxTO67sZ/al =aF6e -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Sep 22 08:30:21 2009 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 9FAD03A680B for ; Tue, 22 Sep 2009 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.851 X-Spam-Level: X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 wmQFobEc7RZY for ; Tue, 22 Sep 2009 08:30:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EF2543A67A3 for ; Tue, 22 Sep 2009 08:30:19 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B7C0240D12; Tue, 22 Sep 2009 09:31:23 -0600 (MDT) Message-ID: <4AB8EA0D.8080601@stpeter.im> Date: Tue, 22 Sep 2009 09:15:25 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Markus.Isomaki@nokia.com" References: <4AB7F11A.5040907@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 15:30:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/09 7:51 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > That's exactly the same work. I guess Peter is asking if that > SIP-related work could be moved from XMPP WG to happen together with > the proposed SIP-XMPP combined use work, as a new (mini-)WG for > instance. > > To me Peter's request makes sense. Of course only if we manage to get > the new SIP/XMPP group setup.) It's a bit odd thing currently in XMPP > WG. That's the same reason we are bringing the SIP/XMPP combined use > proposal to DISPATCH rather than XMPP WG, i.e. it does not really fit > that well with the other items XMPP WG is working on. Agreed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq46g0ACgkQNL8k5A2w/vyphQCgqORq0xeAr481jc8UWdz0l1sM LukAoKnaJUIZU7jX7BbX9HWov6Cw1cCa =vaLG -----END PGP SIGNATURE----- From dromasca@avaya.com Tue Sep 22 08:46:37 2009 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 A21633A6A08 for ; Tue, 22 Sep 2009 08:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 iMaEmxabIuTU for ; Tue, 22 Sep 2009 08:46:37 -0700 (PDT) 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 DC2013A6968 for ; Tue, 22 Sep 2009 08:46:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,432,1249272000"; d="scan'208";a="184195076" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Sep 2009 11:47:40 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Sep 2009 11:47:39 -0400 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, 22 Sep 2009 17:47:13 +0200 Message-ID: In-Reply-To: <4AB8E99C.5080200@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence thread-index: Aco7mb6qt1rrIC34S3CS3bzfsOUtzQAAcmBg References: <4AB7F11A.5040907@stpeter.im> <4AB8E99C.5080200@stpeter.im> From: "Romascanu, Dan (Dan)" To: "Peter Saint-Andre" Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 15:46:37 -0000 =20 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 > As Simo points out, the same people would be=20 > interested in both the "combined SIP/XMPP" use cases and the=20 > "SIP/XMPP interworking" use cases.=20 Can you shortly explain what is the difference between the two or point me to a reference that explains this?=20 > IMHO it would be more=20 > productive to complete the interworking tasks in a WG that is=20 > dedicated to SIP and XMPP, rather than in the XMPP WG. Yes, but the XMPP WG was (re)chartered just a few months ago, and I am trying to understand what changed since then, or what happened in the XMPP WG for this work to look so soon for another home.=20 Thanks and Regards, Dan >=20 > Peter >=20 > > Dan > >=20 From stpeter@stpeter.im Tue Sep 22 09:05:51 2009 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 4CF543A68A7 for ; Tue, 22 Sep 2009 09:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 vXovVfwdQ544 for ; Tue, 22 Sep 2009 09:05:50 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 793253A6882 for ; Tue, 22 Sep 2009 09:05:50 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 46FA54007B; Tue, 22 Sep 2009 10:06:54 -0600 (MDT) Message-ID: <4AB8F61E.5030304@stpeter.im> Date: Tue, 22 Sep 2009 10:06:54 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4AB7F11A.5040907@stpeter.im> <4AB8E99C.5080200@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 16:05:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/09 9:47 AM, Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > >> As Simo points out, the same people would be >> interested in both the "combined SIP/XMPP" use cases and the >> "SIP/XMPP interworking" use cases. > > Can you shortly explain what is the difference between the two or point > me to a reference that explains this? Combinations are things like "invoke an XMPP groupchat session from a SIP UA" or "show XMPP presence in a SIP UA". Interworkings are things like "gateway instant messages between a SIP network and an XMPP network". >> IMHO it would be more >> productive to complete the interworking tasks in a WG that is >> dedicated to SIP and XMPP, rather than in the XMPP WG. > > Yes, but the XMPP WG was (re)chartered just a few months ago, and I am > trying to understand what changed since then, or what happened in the > XMPP WG for this work to look so soon for another home. The XMPP WG was the best home we had for the SIP-XMPP interworking effort at the time and IMHO will not receive a great deal of attention within the XMPP WG because that WG is prioritizing XMPP-specific tasks such as: 1. Completion of revisions to RFC 3920 and RFC 3921 2. Replacement of RFC 3923 (end-to-end signing and encryption) with technologies that will be more widely deployed (probably based on TLS for encryption and XMLDSIG for signing, though that is yet to be worked out in detail) 3. Improvement of the server-to-server communications model for secure federation between large-scale service providers. IMHO those activities will keep the XMPP WG chugging along for a while and the SIP-XMPP work will not receive a lot of attention. If we can move it over to a new, more focused WG then I am in favor, because that will encourage faster progress, I think. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq49h4ACgkQNL8k5A2w/vzSBgCcCW1gmIkfa21x9xrfY2oQIH59 DdQAnRI/hoskAt5Rja+fH46zo/EqEnnI =aWhG -----END PGP SIGNATURE----- From dromasca@avaya.com Tue Sep 22 09:09:59 2009 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 1959F3A68BF for ; Tue, 22 Sep 2009 09:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 TBzPVq+Vp7KL for ; Tue, 22 Sep 2009 09:09:58 -0700 (PDT) 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 F33E43A69E9 for ; Tue, 22 Sep 2009 09:09:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,432,1249272000"; d="scan'208";a="184199584" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Sep 2009 12:11:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Sep 2009 12:11:01 -0400 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, 22 Sep 2009 18:10:52 +0200 Message-ID: In-Reply-To: <4AB8F61E.5030304@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence thread-index: Aco7nrbGcMLFMdDhTp2oz3U/cdlyUwAACyWA References: <4AB7F11A.5040907@stpeter.im> <4AB8E99C.5080200@stpeter.im> <4AB8F61E.5030304@stpeter.im> From: "Romascanu, Dan (Dan)" To: "Peter Saint-Andre" Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 16:09:59 -0000 Got it, thanks for the explanations. The differences between the two approaches could be caught in text in the proposed charter - BTW. Moving work from an existing WG to a new one is an interesting exercise, because you are implicitly requiring some kind of rechartering of the XMPP WG as well, but (much) better schedules in a better focused effort are a good argument.=20 Dan =20 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 > Sent: Tuesday, September 22, 2009 7:07 PM > To: Romascanu, Dan (Dan) > Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal on combining SIP=20 > voice with XMPP IM and presence >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 9/22/09 9:47 AM, Romascanu, Dan (Dan) wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > >=20 > >> As Simo points out, the same people would be interested in=20 > both the=20 > >> "combined SIP/XMPP" use cases and the "SIP/XMPP interworking" use=20 > >> cases. > >=20 > > Can you shortly explain what is the difference between the two or=20 > > point me to a reference that explains this? >=20 > Combinations are things like "invoke an XMPP groupchat=20 > session from a SIP UA" or "show XMPP presence in a SIP UA". >=20 > Interworkings are things like "gateway instant messages=20 > between a SIP network and an XMPP network". >=20 > >> IMHO it would be more > >> productive to complete the interworking tasks in a WG that is=20 > >> dedicated to SIP and XMPP, rather than in the XMPP WG. > >=20 > > Yes, but the XMPP WG was (re)chartered just a few months=20 > ago, and I am=20 > > trying to understand what changed since then, or what=20 > happened in the=20 > > XMPP WG for this work to look so soon for another home. >=20 > The XMPP WG was the best home we had for the SIP-XMPP=20 > interworking effort at the time and IMHO will not receive a=20 > great deal of attention within the XMPP WG because that WG is=20 > prioritizing XMPP-specific tasks such as: >=20 > 1. Completion of revisions to RFC 3920 and RFC 3921 >=20 > 2. Replacement of RFC 3923 (end-to-end signing and=20 > encryption) with technologies that will be more widely=20 > deployed (probably based on TLS for encryption and XMLDSIG=20 > for signing, though that is yet to be worked out in detail) >=20 > 3. Improvement of the server-to-server communications model=20 > for secure federation between large-scale service providers. >=20 > IMHO those activities will keep the XMPP WG chugging along=20 > for a while and the SIP-XMPP work will not receive a lot of=20 > attention. If we can move it over to a new, more focused WG=20 > then I am in favor, because that will encourage faster=20 > progress, I think. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkq49h4ACgkQNL8k5A2w/vzSBgCcCW1gmIkfa21x9xrfY2oQIH59 > DdQAnRI/hoskAt5Rja+fH46zo/EqEnnI > =3DaWhG > -----END PGP SIGNATURE----- >=20 From oej@edvina.net Tue Sep 22 09:32:37 2009 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 94CE03A6882 for ; Tue, 22 Sep 2009 09:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_SE=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 f14bYYx5gjdS for ; Tue, 22 Sep 2009 09:32:36 -0700 (PDT) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 95C903A6901 for ; Tue, 22 Sep 2009 09:32:35 -0700 (PDT) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 515F528433; Tue, 22 Sep 2009 18:14:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Olle E. Johansson" In-Reply-To: <4AB8F61E.5030304@stpeter.im> Date: Tue, 22 Sep 2009 18:33:38 +0200 Content-Transfer-Encoding: 7bit Message-Id: <24488C12-E0C5-4B29-9143-44979A85677A@edvina.net> References: <4AB7F11A.5040907@stpeter.im> <4AB8E99C.5080200@stpeter.im> <4AB8F61E.5030304@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1075.2) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 16:32:37 -0000 22 sep 2009 kl. 18.06 skrev Peter Saint-Andre: >Combinations are things like "invoke an XMPP groupchat session from a >SIP UA" or "show XMPP presence in a SIP UA". >Interworkings are things like "gateway instant messages between a SIP >network and an XMPP network". I think both your combination examples requires interworking. What I've seen discussed here are multiprotocol clients so combination would rather be something like "invoke a SIP conference call and XMPP groupchat simultaneously" or "Avoid SIP calls if XMPP presence is DND" > IMHO those activities will keep the XMPP WG chugging along for a while > and the SIP-XMPP work will not receive a lot of attention. If we can > move it over to a new, more focused WG then I am in favor, because > that > will encourage faster progress, I think. Will a new working group mean a whole set of fresh new members with more time? /O From stpeter@stpeter.im Tue Sep 22 09:39:16 2009 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 DF5853A695D for ; Tue, 22 Sep 2009 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 0jmy-0X4gns9 for ; Tue, 22 Sep 2009 09:39:15 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E177B3A6882 for ; Tue, 22 Sep 2009 09:39:15 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AA5484007B; Tue, 22 Sep 2009 10:40:19 -0600 (MDT) Message-ID: <4AB8FDF4.10702@stpeter.im> Date: Tue, 22 Sep 2009 10:40:20 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Olle E. Johansson" References: <4AB7F11A.5040907@stpeter.im> <4AB8E99C.5080200@stpeter.im> <4AB8F61E.5030304@stpeter.im> <24488C12-E0C5-4B29-9143-44979A85677A@edvina.net> In-Reply-To: <24488C12-E0C5-4B29-9143-44979A85677A@edvina.net> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 16:39:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/09 10:33 AM, Olle E. Johansson wrote: > > 22 sep 2009 kl. 18.06 skrev Peter Saint-Andre: > >> IMHO those activities will keep the XMPP WG chugging along for a while >> and the SIP-XMPP work will not receive a lot of attention. If we can >> move it over to a new, more focused WG then I am in favor, because that >> will encourage faster progress, I think. > > Will a new working group mean a whole set of fresh new members with more > time? Last I checked, fresh new members don't materialize out of thin air. :) My point is that *if* a new SIP-XMPP group is being chartered anyway, it would be more productive to have all the SIP-XMPP work happening there, because (1) most people involved in the XMPP WG are only interested in XMPP and the SIP-XMPP work is not top-of-mind for them, and (2) we might be able to attract interest in SIP-XMPP work among implementers for whom SIP-XMPP interworking/combinations are a pain point (that would include client developers, server developers, and operators). If we reach out to those folks and define a problem statement that captures what they are seeing in the implementation and deployment space, then yes we might be able to attract some fresh new members. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq4/fQACgkQNL8k5A2w/vwwTQCfdXLD79b3ybnpEpz3Loqjk/+S MaIAn1Km+L+cbb73EFRsuklo4CjDsv0j =xxA8 -----END PGP SIGNATURE----- From oej@edvina.net Tue Sep 22 09:42:49 2009 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 7B4423A6AAC for ; Tue, 22 Sep 2009 09:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_SE=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 EcjVQktNaskG for ; Tue, 22 Sep 2009 09:42:48 -0700 (PDT) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 214BE3A6A18 for ; Tue, 22 Sep 2009 09:42:47 -0700 (PDT) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 39B5128433; Tue, 22 Sep 2009 18:24:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Olle E. Johansson" In-Reply-To: <4AB8FDF4.10702@stpeter.im> Date: Tue, 22 Sep 2009 18:43:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7BC6F3B3-346D-4352-B4DF-4404A216F53D@edvina.net> References: <4AB7F11A.5040907@stpeter.im> <4AB8E99C.5080200@stpeter.im> <4AB8F61E.5030304@stpeter.im> <24488C12-E0C5-4B29-9143-44979A85677A@edvina.net> <4AB8FDF4.10702@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1075.2) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 22 Sep 2009 16:42:50 -0000 22 sep 2009 kl. 18.40 skrev Peter Saint-Andre: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/22/09 10:33 AM, Olle E. Johansson wrote: >> >> 22 sep 2009 kl. 18.06 skrev Peter Saint-Andre: >> >>> IMHO those activities will keep the XMPP WG chugging along for a >>> while >>> and the SIP-XMPP work will not receive a lot of attention. If we can >>> move it over to a new, more focused WG then I am in favor, because >>> that >>> will encourage faster progress, I think. >> >> Will a new working group mean a whole set of fresh new members with >> more >> time? > > Last I checked, fresh new members don't materialize out of thin > air. :) I am aware of that issue... ;-) > > My point is that *if* a new SIP-XMPP group is being chartered > anyway, it > would be more productive to have all the SIP-XMPP work happening > there, > because (1) most people involved in the XMPP WG are only interested in > XMPP and the SIP-XMPP work is not top-of-mind for them, and (2) we > might > be able to attract interest in SIP-XMPP work among implementers for > whom > SIP-XMPP interworking/combinations are a pain point (that would > include > client developers, server developers, and operators). If we reach > out to > those folks and define a problem statement that captures what they are > seeing in the implementation and deployment space, then yes we might > be > able to attract some fresh new members. Agreed. I am very interested in the SIP-XMPP work. I might just materialize at some point. Maybe not out of thin air though. /O From fluffy@cisco.com Tue Sep 22 10:30:31 2009 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 EC16D3A67D7; Tue, 22 Sep 2009 10:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.23 X-Spam-Level: X-Spam-Status: No, score=-106.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_MED=-4, 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 aN8W+67fivd7; Tue, 22 Sep 2009 10:30:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9166828C106; Tue, 22 Sep 2009 10:30:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADumuEqrR7MV/2dsb2JhbADAS4hPAZAMBYQb X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="393788432" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 17:31:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8MHVYss005862; Tue, 22 Sep 2009 10:31:34 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8MHVXLh012992; Tue, 22 Sep 2009 17:31:33 GMT Message-Id: <5FC83EF4-C26E-4DD0-8D4B-2E67D0F0716C@cisco.com> From: Cullen Jennings To: rai@ietf.org, dispatch@ietf.org, sipping , SIP List Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Sep 2009 11:31:32 -0600 References: <4568491E-A8CA-4089-84C7-2D555F929204@americafree.tv> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4901; t=1253640694; x=1254504694; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20Request=20for=20community=20guidance=2 0on=20issue=20concerning=20a=20future=20meeting=20of=20the=2 0IETF |Sender:=20; bh=vEUxTuf8FxjvDgC+2Yw3Y4RKH4lSS5F9Xb1b9/w6WEI=; b=CEWVcWg52pYz+HCPSbOwPiXXNEbTReTeHmG1NGlOqJsrGQiePrpm42XR3N w7/ytD3ZcHWSRF8nfnrO0HH786/tnQoSgLUaIiyRMOT+UXksDhdZtzbEyuFb DOAU6ia4ZK6QdvTjKEPByzu9N3ho+pmIYIfrj0uLCIAOIkd485R0I=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [dispatch] Fwd: Request for community guidance on issue concerning a future meeting of the IETF 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, 22 Sep 2009 17:30:32 -0000 Please don't reply to this message. Go reply to the copy on the ietf@ietf.org thread. I often shy away from forwarding things to the RAI lists, however, I think that people need to be aware that there is conversation going on that is probably pretty important around if IETF 79 should be in China or Canada. I expect that coming out of this conversation will be not just where IETF 76 happens, but also guidelines or lore that impacts what type of environments the IETF expects to host meetings in that country. Anyways, if you have any interest in this, go send your 2 cents to ietf@ietf.org mailing list. Thanks, Cullen Begin forwarded message: > From: Marshall Eubanks > Date: September 18, 2009 9:42:00 AM MDT (CA) > To: IETF Announcement list , IETF-Discussion > list , Working Group Chairs > Cc: IAOC Jabberr , IAB IAB , IESG >, irtf-chair@irtf.org > Subject: Request for community guidance on issue concerning a future > meeting of the IETF > > Greetings; > > We have received numerous suggestions and requests for an IETF meeting > in China and the IAOC has been working on a potential China meeting > for > several years. We are now close to making a decision on a potential > upcoming meeting in China. However, the following issue has arisen > and we would appreciate your feedback. > > The Chinese government has imposed a rule on all conferences held > since 2008 regarding political speech. A fundamental law in China > requires that one not criticize the government. Practically, this > has reference to public political statements or protest marches, which > are not the IETF's custom. The government, which is a party to the > issue, > requires that people who attend conferences in China (the IETF being > but one example) not engage in political speech during their tour > in China. We consider this to be acceptable, on the basis that the > IETF intends to abide by the laws of whatever nations it visits and > we don't believe that this impacts our ability to do technical work. > > The rule is implemented in the Hotel agreement and reads (note that > the "Client" would be the Host, and the "Group" would be the IETF) : > > "Should the contents of the Group's activities, visual or audio > presentations at the conference,or printed materials used at the > conference (which are within the control of the Client) contain > any defamation against the Government of the People's Republic > of China, or show any disrespect to the Chinese culture, or > violates any laws of the People's Republic of China or feature > any topics regarding human rights or religion without prior > approval from the Government of the People's Republic of China, > the Hotel reserves the right to terminate the event on the spot > and/or ask the person(s) who initiates or participates in any or > all of the above action to leave the hotel premises immediately. > > The Client will support and assist the Hotel with the necessary > actions to handle such situations. Should there be any financial > loss incurred to the Hotel or damage caused to the Hotel's > reputation as a result of any or all of the above acts, the Hotel > will claim compensation from the Client." > > What does this condition mean ? The hotel staff would have, in theory, > the legal right to shut down the meeting and ask the offending > participants to leave the property immediately. While we do not > foresee a situation where such action would take place, we feel that > it is proper to disclose these conditions to the community. > > The members of the IAOC, speaking as individuals, do not like this > condition as a matter of principle. The IAOC does believe that this > condition would not prevent the IETF from conducting its business. > > We note that the Vancouver/Quebec survey conducted earlier this year > asked for people to suggest venues in Asia; an overwhelming majority > (94%) of those who mentioned China were in favor of having a meeting > there. > > We are therefore asking for input from the community by two means - by > commenting on the IETF discussion list, and also by completing a very > short survey on people's intentions to travel to China, or not, > subject to these conditions. This survey can be found here : > > https://www.surveymonkey.com/s.aspx?sm=h4DUkRUOdG_2bVLqioPcYYHw_3d_3d > > All responses received by October 1, 2009 at 9:00 AM EDT (1300 UTC) > will be considered by the IAOC in making its decision. We appreciate > the assistance of the community in providing us with data that will > help us to make an informed decision. > > Regards > Marshall Eubanks > (acting for the IAOC) > From dean.willis@softarmor.com Tue Sep 22 11:17:00 2009 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 4A79E3A698E for ; Tue, 22 Sep 2009 11:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 6hKmHuSvst2m for ; Tue, 22 Sep 2009 11:16:59 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5AC793A696D for ; Tue, 22 Sep 2009 11:16:59 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8MII0JD005702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Sep 2009 13:18:02 -0500 Message-Id: <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> From: Dean Willis To: "" In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Sep 2009 13:17:55 -0500 References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 22 Sep 2009 18:17:00 -0000 On Sep 22, 2009, at 9:12 AM, wrote: > > My understanding from your mail way that you know of other use cases > from other mobile standards group. Is that correct? If yes, does it > make sense to consider them here? The syntax is open so people can add > new labels. > It's been a while but I may remember conversations in 3GPP, 3GPP2, and OMA. The ring-back for national standard ringers has always seemed like a a good application of URN in alert-info. In other words, if you call somebody in France, you might get back a 180 with an alert-info with a URN that basically means "France standard ring tone". I vaguely remember discussion about URN-based alert-info for "public alert" calls, like storm warnings and evacuation orders. There's also been discussion of use in forward-ring cases, as in alert- info in an INVITE request. See http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. This suggests several additional cases that may need to be considered, probably national variants of distinctive-ring indicators. While we probably don't want to charter every possible use case, it would probably be appropriate to consider any published use cases from the mobile groups. So perhaps part of the task of the WG would be to review the extant standards and see if any of them should be added to the initial registry. -- Dean From richard@shockey.us Tue Sep 22 11:24:28 2009 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 24DC528C167 for ; Tue, 22 Sep 2009 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tusYKhYS7pSK for ; Tue, 22 Sep 2009 11:24:25 -0700 (PDT) Received: from outbound-mail-24.bluehost.com (outbound-mail-24.bluehost.com [69.89.21.19]) by core3.amsl.com (Postfix) with SMTP id EBEB63A67BE for ; Tue, 22 Sep 2009 11:23:57 -0700 (PDT) Received: (qmail 13741 invoked by uid 0); 22 Sep 2009 18:25:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 22 Sep 2009 18:25:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ltt7xnda9gut0JtGxrzVcLUduTBkNyPREQUtW7Vi6WcXbG22Amv5j6B/9pNEU2RNKHUkcAn96PKy/ZRNX9m++be2uZ9a2NbaukJ/UoPCfAnCENpMgdJLs++M4Xz2rBM4; Received: from pool-96-255-226-99.washdc.fios.verizon.net ([96.255.226.99] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MqA2u-0007tB-CN; Tue, 22 Sep 2009 12:25:00 -0600 From: "Richard Shockey" To: "'Milan Patel'" , "'Gonzalo Camarillo'" , "'DISPATCH'" References: <4AB0F267.8050903@ericsson.com> <0913B6CD18F370498CD65864CF254E900AD34F4B@zharhxm1.corp.nortel.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E900AD34F4B@zharhxm1.corp.nortel.com> Date: Tue, 22 Sep 2009 14:24:56 -0400 Message-ID: <012f01ca3bb1$fcebc340$f6c349c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco2183+F4+NRlXDQ3acsebFeOf6DQDxXh0wAETsnpA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.99 authed with richard+shockey.us} Subject: Re: [dispatch] Cutoff for charter proposals on Monday 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, 22 Sep 2009 18:24:28 -0000 I want to add some support to this idea but for a totally different reason. This concept breaks open the issue that there have been some in the IETF that objected to non-routing parameters used in TEL URI's and frankly this bizarre restriction has caused me a world of grief. Case in point. http://tools.ietf.org/html/draft-ietf-enum-cnam-08 What I'd like to see is this issue settled once and for all. What is and is not acceptable use of the TEL URI? If Calling Party Catagory is acceptable use of the TEL paramameter then I want CNAM. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Milan Patel > Sent: Monday, September 21, 2009 5:35 AM > To: Gonzalo Camarillo; DISPATCH > Subject: Re: [dispatch] Cutoff for charter proposals on Monday > > Hi, > > I would like to add an additional topic to the DISPATCH charter - URI > parameters to describe the calling party category and toll class. > > Previously, Calling Party Category (CPC) URI parameter was defined in > a > draft by Rohan Mahy in the IPTEL group. > There is still a need by carriers for this parameter and it is > currently > also used within TISPAN and 3GPP. > The motivation for defining the CPC URI parameter is to provide a > standardized method of providing information about the calling party > and > the station used to originate a call. Currently, a number of > proprietary > solutions are being used as a standardized solution is unavailable. > > My intention is to revise Rohan's draft: > http://tools.ietf.org/html/draft-mahy-iptel-cpc-06 > And to take on board some of the comments received on the old IPTEL > list. > My proposal is to provide a draft that defines 2 URI parameters: "cpc" > and "oli" indicating the category and tolls class of the calling > party, > allowing mapping to parameters used in ISUP. > > Best regards, > Milan > > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 > Mobile +44 774 053 9261 / ESN 748 9261 > > For the Companies listed below, The Institute of Chartered Accountants > in England and Wales authorises A R Bloom, S Harris and C Hill to act > as > Insolvency Practitioners under section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants authorises > A > M Hudson to act as an Insolvency Practitioner under section 390(2)(a) > of > the Insolvency Act 1986. > > The affairs, business and property of the Companies are being managed > by > the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill > who > act as agents of the Companies only and without personal liability. > > The Companies are Nortel Networks UK Limited; Nortel Networks SA; > Nortel > GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks > SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel > Networks > Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; > Nortel > Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania > SRL; > Nortel Networks AB; Nortel Networks International Finance & Holding BV > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 16 September 2009 15:13 > To: DISPATCH > Subject: [dispatch] Cutoff for charter proposals on Monday > > Folks, > > this is a reminder of our cutoff for charter proposals, which is on > Monday (September 21st). Per our previous email: "A charter proposal > must consist of a minimum of a problem statement and at least one > milestone/deliverable. This deadline will allow time for consideration > of proposals that could potentially be "dispatched" prior to the WG > session." > > A few of the topics we received arrived after the previous deadline, > which was September 7th. We will be considering even those topics that > arrived a bit late because we realize the deadline was quite tough to > meet (specially for people that returned from their vacation right > before the deadline). > > We are expecting charter proposals for: > > o Third-party authorization > o CBUS > o Session recording > o Identity > o Disaggregated media > o Domain registrations in SIP > o SIP - XMPP > o Alert-info URNs > o Reference to an earlier communication > > Let the chairs know if there are topics missing from this list. > > 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 From richard@shockey.us Tue Sep 22 11:36:59 2009 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 F27E13A6AC9 for ; Tue, 22 Sep 2009 11:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgh7S87CJEbN for ; Tue, 22 Sep 2009 11:36:57 -0700 (PDT) Received: from outbound-mail-306.bluehost.com (outbound-mail-306.bluehost.com [67.222.53.252]) by core3.amsl.com (Postfix) with SMTP id 143B93A6ACB for ; Tue, 22 Sep 2009 11:36:57 -0700 (PDT) Received: (qmail 2675 invoked by uid 0); 22 Sep 2009 18:38:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 22 Sep 2009 18:38:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=XpCAwYrGr4VKTzrKRFrkGHzQhOCmBZUsUxtyv6mf9lj6pNMQvzRlMJPuY6zr5psODepJJU2g2PaOj5jwaxvEDYu4XBl4wMtonP4CI3gkxRaaOCmpzNaavnFNR9mWFtU0; Received: from pool-96-255-226-99.washdc.fios.verizon.net ([96.255.226.99] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MqAFU-0000wh-RF; Tue, 22 Sep 2009 12:38:01 -0600 From: "Richard Shockey" To: "'Alan Johnston'" , "'Dean Willis'" References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> <4AAA5C98.1080502@sipstation.com> In-Reply-To: <4AAA5C98.1080502@sipstation.com> Date: Tue, 22 Sep 2009 14:37:56 -0400 Message-ID: <013001ca3bb3$ce1d1e40$6a575ac0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoy6vnoHtnAdjSVQBKiXJRa9I4EwwIx8pbg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.99 authed with richard+shockey.us} Cc: dispatch@ietf.org, 'Gonzalo Camarillo' , 'Hadriel Kaplan' Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic Domain Registration 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, 22 Sep 2009 18:36:59 -0000 Alan is right ..the problem statement will be easier to explain once we have a draft in hand. This is not really a proposal for a WG. There is only one draft here. What we need to explain is what is actually happening in the market with certain classes of SIP-PBX deployments especially in Small and Medium business markets. There are much larger issue here that should be addressed in the provisioning of PBX to SSP networks but that is not the topic here. > -----Original Message----- > From: Alan Johnston [mailto:alan@sipstation.com] > Sent: Friday, September 11, 2009 10:20 AM > To: Dean Willis > Cc: Richard Shockey; dispatch@ietf.org; 'Hadriel Kaplan'; 'Gonzalo > Camarillo' > Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic > Domain Registration > > Dean, > > The plan is not to rewrite the Internet's name architecture nor > replace > RFC 3263. > > The plan is to standardize a function that has been shown to be needed > in the marketplace for the deployment of SIP in certain applications. > > And yes, dynamic DNS is an alternative, it does work, but again, there > are reasons why it is not being used in this certain application. > > Anyway, lets start this conversation properly when we have a draft. > > Thanks, > Alan > > > Dean Willis wrote: > > > > On Sep 4, 2009, at 2:53 PM, Richard Shockey wrote: > > > >> Dispatch Chairs: We would like to reserve some time during > DISPATCH to > >> discuss the topic of domain registration in SIP. > > > > It seems like you're proposing a deep and fundamental rewrite of the > > Internet's name architecture, replacing RFC 3263 and its use of DNS > > with some sort of SIP REGISTER technique. > > > > Or maybe I'm missing it entirely, and what you're proposing is a way > > to use SIP REGISTER messages to populate a DNS SRV record within a > > registry? > > > > This raises the question of delegation to that registry -- the > > registry has to be authoritative for all of example.com in order to > > be able to host an srv record for example.com. So your mythical SMB > is > > still going to require a DNS service provider that has to be > > meaningfully provisioned. It's just a question of the outsourcing > > contract, and I fail to see a need for protocol work here. After > all, > > we have dynamic DNS, and it works pretty darned well for me today. > > > > So what you talking 'bout, Shockey? > > > > -- > > Dean > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From christer.holmberg@ericsson.com Tue Sep 22 12:41:04 2009 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 5142D3A6802 for ; Tue, 22 Sep 2009 12:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.58 X-Spam-Level: X-Spam-Status: No, score=-5.58 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_SE=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 8myGvy3GGgm6 for ; Tue, 22 Sep 2009 12:41:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id ED3293A6800 for ; Tue, 22 Sep 2009 12:40:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7c03ae0000055e7-92-4ab9288aa75a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B4.B8.21991.A8829BA4; Tue, 22 Sep 2009 21:42:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:42:02 +0200 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: Tue, 22 Sep 2009 21:39:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposed: CBUS Thread-Index: Aco7kkg6jd2/WFQ3TIK/d3UkkPs1jQAKir3E References: <4AB8E15E.8070802@telecomitalia.it> From: "Christer Holmberg" To: "Enrico Marocco" X-OriginalArrivalTime: 22 Sep 2009 19:42:02.0348 (UTC) FILETIME=[C1B8BAC0:01CA3BBC] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS 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, 22 Sep 2009 19:41:04 -0000 Hi Enrico, =20 If an even package registration, in addition to the body used in the = NOTIFY request, also allows the definition of the XML body (and possilbe = event header parameters) which is needed in the SUBSCRIBE request (in = order to provide the conditions etc), then I agree that it may be = enough. =20 Regards, =20 Christer ________________________________ From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] Sent: Tue 22/09/2009 16:38 To: Christer Holmberg Cc: dispatch@ietf.org; Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS Christer, I see value in a general mechanism for selectively retrieve lists of URIs, but am wondering whether this is actually a charter proposal (in such case I guess the text requires heavy rewording, defining acronyms as a start) or just an event package registration request according to rfc3427bis, S.4.1? Enrico Christer Holmberg wrote: > > Hi, > > Below is the proposed charter for CBUS. > > Regards, > > Christer > > ----------------------------------------- > > CBUS Charter. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Introduction: > ------------- > > Various OMA service enablers need to be able to retrieve a list of > addresses (URIs), where the users associated with the URIs fulfil > certain conditions. User information is evaluated against the > conditions, and the matches form a URI list. > > The need for the functionality originates from the OMA PoC service. > However, there is ongoing work in OMA to define a common mechanism, > called CBUS enabler (OMA-RD-CBUS-V1_0-20090203-C), to provide the > functionality, so that it can be used for various types of services > (e.g. messaging, gaming, conferencing and advertisement). > > The CBUS enabler provides the following functions: > > - Support for requestor initiated condition-based URIs selection = requests. > > - Administration of conditions for URI selection. > > - Interaction with other enablers for retrieval of individual user's > information (e.g. presence information, location information). > > - Evaluation of conditions and selection of matching individual users > based on one time evaluation. > > - Re-evaluation of conditions and re-selection of matching individual > users based on monitoring. > > - Aggregation of one-time evaluation results and monitoring results > from different information sources. > > - Notification of evaluation results to requestor. > > The conditions can be based on user information which changes over = time > (e.g. presence information or geographical location), but they can = also > be based on more static user information (e.g. hobbies or personal > interests). > > The entity which acts as requester, and provides the conditions to be > used for the user information evaluation, is called CBUS client. The > CBUS client usually resides on the user equipment, or an application > server, which supports the CBUS enabler. > > The selection of URIs, based on the provided conditions, may be > performed by taking a snapshot, i.e. by making a one-time evaluation = of > the user information to find out whether the conditions are fulfilled = or > not. The URI selection may also be performed by continous monitoring = of > the user information. > > > Work and deliverables: > ---------------------- > > The purpose of the work is to, based on the OMA CBUS requirements = (OMA- > RD-CBUS-V1_0-20090203-C), procude the SIP protocol information = elements > which are needed to implement the interface between the CBUS client = and > CBUS server, using the SIP SUBSCRIBE/NOTIFY framework (RFC 3265). > > > The primary task for the work is to: > > 1. Procude a mechanism for a subscriber (CBUS client) to, when > subscribing to an event package which contains a list of URI, provide > conditions, candidate URIs and evaluation parameters to the notifier > (CBUS server). > > The mechanism may be used on defining an XML based message body type, > and SIP header field parameters. > > 2. Produce an event package, or possible re-use an existing event > package, used to the notifier (CBUS server) to send URI lists (based = on > the conditions and candidate URIs) to the subscriber (CBUS client). > > The CBUS client actions triggered by the received URI list, and the > interactions between the CBUS server and other enablers, are outside = the > scope of the work. > > > The work is planned to take place in, or in co-operaton with, the > SIPCORE WG. > > > Goals and milestones: > --------------------- > > Jan 2010 Working Group Last Call for the document which = contains > the mechanism for a > subscriber to provide the needed CBUS information to the > notifier, and > contains the event package (if a new package is needed) = for the > notifier to provide the URI list to the subscriber. > > Mar 2010 Submit document to IESG as Proposed Standard > From pkyzivat@cisco.com Tue Sep 22 18:10:47 2009 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 61B573A6A86 for ; Tue, 22 Sep 2009 18:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 SE25Qn8OQJMg for ; Tue, 22 Sep 2009 18:10:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 35C993A694C for ; Tue, 22 Sep 2009 18:10:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUEADcTuUqrR7PD/2dsb2JhbACPOK4tiE8BkB8FhBs X-IronPort-AV: E=Sophos;i="4.44,434,1249257600"; d="scan'208";a="394066617" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Sep 2009 01:11:48 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n8N1Bnkq022792; Tue, 22 Sep 2009 18:11:49 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8N1BmDs015097; Wed, 23 Sep 2009 01:11:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:11:48 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:11:47 -0400 Message-ID: <4AB975CE.4040104@cisco.com> Date: Tue, 22 Sep 2009 21:11:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <40FB0FFB97588246A1BEFB05759DC8A0036E29AD@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A0036E2DE4@S4DE9JSAANI.ost.t-com.de> <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> In-Reply-To: <58C1975B-4034-4D04-83C2-1E48D6461B15@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2009 01:11:47.0989 (UTC) FILETIME=[D2E1F450:01CA3BEA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2359; t=1253668309; x=1254532309; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=3A=20=2 0SIP=20Alert-Info=20URN |Sender:=20; bh=oeNENQkgg5VYhNGFucrXiIcttCtM6lEtp5fGUlkq5U0=; b=cMwnbQ0aBmrmaF0ulEjE21d+dMNOdnTXJn6gw48jlRe69BLB1VUGKNl0dy kgL9Yekq5bn0fa1GKkty/xZgwErSKhKOdIyJ9iiyFW+UVRgF300Df4Z2M50l rZLQ3rSRaG; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: dispatch@ietf.org, "" Subject: Re: [dispatch] Charter proposal: SIP Alert-Info URN 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, 23 Sep 2009 01:10:47 -0000 I agree with Dean here. The example of the "France standard ring tone" is a case where you have a URN that identifies some specific audio signal, but in a semantic way rather than by providing an encoding of it. This can be useful for a variety of reasons: - its not biased towards a particular representation, which might not be suitable for all devices - its convenient when you want to store the actual encoding locally rather than fetching it - because it is specified "by name" rather than "by value", its easier to make policy decisions about whether to use it or not. - it facilitates translation for the hearing impaired Thanks, Paul Dean Willis wrote: > > On Sep 22, 2009, at 9:12 AM, > wrote: >> >> My understanding from your mail way that you know of other use cases >> from other mobile standards group. Is that correct? If yes, does it >> make sense to consider them here? The syntax is open so people can add >> new labels. >> > > It's been a while but I may remember conversations in 3GPP, 3GPP2, and OMA. > > The ring-back for national standard ringers has always seemed like a a > good application of URN in alert-info. In other words, if you call > somebody in France, you might get back a 180 with an alert-info with a > URN that basically means "France standard ring tone". > > I vaguely remember discussion about URN-based alert-info for "public > alert" calls, like storm warnings and evacuation orders. > > > There's also been discussion of use in forward-ring cases, as in > alert-info in an INVITE request. > > See http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. This > suggests several additional cases that may need to be considered, > probably national variants of distinctive-ring indicators. > > > While we probably don't want to charter every possible use case, it > would probably be appropriate to consider any published use cases from > the mobile groups. So perhaps part of the task of the WG would be to > review the extant standards and see if any of them should be added to > the initial registry. > > -- > Dean > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dean.willis@softarmor.com Tue Sep 22 20:34:47 2009 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 A36573A683C for ; Tue, 22 Sep 2009 20:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_73=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 Og0aafCwvjSi for ; Tue, 22 Sep 2009 20:34:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8347C3A67F1 for ; Tue, 22 Sep 2009 20:34:46 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8N3ZlsA009789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Sep 2009 22:35:50 -0500 Message-Id: <2D4423EC-4433-4510-9590-56BE69BF5AD7@softarmor.com> From: Dean Willis To: Alan Johnston In-Reply-To: <4AAA5C98.1080502@sipstation.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: Tue, 22 Sep 2009 22:35:41 -0500 References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> <4AAA5C98.1080502@sipstation.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic Domain Registration 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, 23 Sep 2009 03:34:47 -0000 On Sep 11, 2009, at 9:20 AM, Alan Johnston wrote: > Dean, > > The plan is not to rewrite the Internet's name architecture nor > replace RFC 3263. > > The plan is to standardize a function that has been shown to be > needed in the marketplace for the deployment of SIP in certain > applications. > > And yes, dynamic DNS is an alternative, it does work, but again, > there are reasons why it is not being used in this certain > application. > > Anyway, lets start this conversation properly when we have a draft. > > Thanks, Ah, so you're not really "registering a domain with the Internet using SIP", you're "registering a domain-wide set of AORs with a routing proxy". So here's the use case I'm envisioning. The DNS SRV record for example.org points statically to a service provider's routing proxy/ registrar. This gets provisioned into the DNS when example.org contracts with the service provider. When the example.org PBX powers up, it needs to register with the proxy/registrar. But rather than running a separate REGISTER transaction for each user in example.org, you want to use a single transaction to tell the proxy/registrar "If it's for anybody at example.org, send it to this Contact". One way to approach this might be to use a to/from of "*.example.org" in the REGISTER method (which would be an extension to RFC 3261), along with appropriate authentication. This is something like the bulk-registration problem for gateways, where people have hacked REGISTER to indicate a range of phone numbers. It has the advantage of being able to use qvalue prioritization to have some users at example.org register directly with the service provider, bypassing the PBX. But I worry that it's still a serious misuse of the REGISTER model. We're not really registering a contact; what we're really doing is exchanging routing information for a whole bunch of contacts. Where it breaks down is when example,org's node is not a PBX (a UA, or even B2BUA) but is instead a real proxy (I know, there's no such thing ...). The subtle distinction is in the identity presentation, and its coupling to TLS. I shall try to construct an example for clarification. Suppose Bob calls "alice@example.org", and the service provider issues a 302 with the previously registered Contact value. Bob's UA is now expecting to talk to Alice's UA, via SIPS/TLS. What certificate does the PBX present at the TLS level? is it the certificate of "alice@example.org ", or is it the certificate of "pbx.example.org"? Does this induce an unanticipated respondent problem for Bob? Alternatively suppose a 305 was used. Bob's UA now expects to be talking SIPS/TLS to a proxy that knows how to find Alice. How is the behavior different? This brings in a whole raft of unclarities around TLS, domain usage, certificate/identity coupling, and 302 vs 305 behavior that combine to make me a very confused puppy. It might be that the Domain Certs draft has all this cleared up and I just missed it. It also relates to that long-running "what is an AOR" debate. But it's certainly more useful if the service provider's proxy/ registrar knows it is getting a route towards an AOR instead of a contact for that AOR. Sure, we could extend REGISTER to convey this information. Once we've done that, can REGISTER be used as a general- purpose SIP route exchange mechanism? Or would we be better served by building a real routing protocol, ala TRIP? So given this discussion: I know you like to jump directly to a solution, and "Domain Registration" with its similarity to that private PBX-club SIP specification hint at the solution you might be approaching. But I'd really like to take a step back here and get clarity on the problem we're trying to solve before leaping to a solution, because I have a strong suspicion that we're leading towards the wrong solution to a poorly-defined problem that is itself a subset of an interesting more-general problem. The "domain registration" concept, as I understand it, seems to be a subset of the broader SIP routing-exchange problem. This broader problem I see as becoming increasingly critical in the era of P2P overlays, as it starts to address inter-overlay routing and might even address questions like "What happens if some users in example.org are in overlay A using CHORD and some are in overlay B using PASTRY". This might not be as tactical a solution as hacking REGISTER, but I think it's a real problem and that there are tractable solutions that would fit into the scope of a working group. -- Dean -- Dean From R.Jesske@telekom.de Tue Sep 22 21:29:30 2009 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 9DED23A683F for ; Tue, 22 Sep 2009 21:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=1.300, 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 nb3jY16dl4qs for ; Tue, 22 Sep 2009 21:29:27 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id B9D453A679F for ; Tue, 22 Sep 2009 21:29:25 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 23 Sep 2009 06:30:23 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 06:30:23 +0200 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_01CA3C06.8FFA8042" Date: Wed, 23 Sep 2009 06:30:21 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404F7CF39@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-76 DISPATCH WG deadlines Thread-Index: AcohwNkciiguS2xuQiuKUNJpbaNnbQAuvWPQBURmvQABHjO2IA== From: To: X-OriginalArrivalTime: 23 Sep 2009 04:30:23.0663 (UTC) FILETIME=[912D83F0:01CA3C06] Subject: [dispatch] WG: IETF-76 DISPATCH WG deadlines 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, 23 Sep 2009 04:29:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3C06.8FFA8042 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, here is a proposal for the Charter. I missed to sent it to the whole list. I'm sorry for that. So here for discussion: =20 The use of the Reason header field in responses is considered in RFC3326, doing so is not specified for any existing response code.=20 Nevertheless for interoperability reason between SIP and PSTN such behaviour is needed and already deployed within many networks. A guideline to permit the use of the Reason header within Response is needed. =20 Milestone: May 2010 Guideline for Reason in Responses to ISEG =20 Best Regards =20 Roland ________________________________ Von: Jesske, Roland=20 Gesendet: Donnerstag, 17. September 2009 14:22 An: 'Mary Barnes'; 'Gonzalo Camarillo' Betreff: AW: [dispatch] IETF-76 DISPATCH WG deadlines Hi Mary and Gonzalo, with regard to the mail of this morning I saw that you have already mentioned the reason issue. Looking on this mail it seems to me that I have to write something for the Charter. So I try my best: =20 The use of the Reason header field in responses is considered in RFC3326, doing so is not specified for any existing response code.=20 Nevertheless for interoperability reason between SIP and PSTN such behaviour is needed and already deployed within many networks. A guideline to permit the use of the Reason header within Response is needed. =20 Milestone: May 2010 Guideline for Reason in Responses to ISEG =20 Is the milestone correct or do I have to differentiate? =20 I hope everything is correct. Commons? =20 Thank you and Best Regards =20 Roland ________________________________ Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftrag von Mary Barnes Gesendet: Freitag, 21. August 2009 18:25 An: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Betreff: [dispatch] IETF-76 DISPATCH WG deadlines Hi all,=20 As was done for IETF-75, we are setting earlier deadlines for discussing topics in DISPATCH prior to the WG session at IETF-76. =20 We will again follow the deadlines for BoFs:=20 http://www.ietf.org/meeting/cutoff-dates.html#76 =20 This provides enough time to dispatch topics prior to the meeting as appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs, mailing lists, etc. Thus, allowing us to have more focused and constructive discussions on a smaller set of topics prior to the WG session.=20 Please note that the dates are much sooner than you might expect as the time between IETF-75 and IETF-76 is 3 weeks less than the time between IETF-74 and IETF-75. The document deadlines are 9 and 10 weeks away from next Monday (August 24th). =20 Thus, the following are the proposed deadlines:=20 Sept 7th - Cutoff date to notify the chairs and DISPATCH WG mailing list of plans to submit a proposal.=20 ------------------------------------------------------------------------ --------------------------------=20 This will help folks with similar topics to work together before the meeting. If a preliminary charter proposal is available at this point, please include it. September 21st - Cutoff for charter proposals for topics.=20 --------------------------------------------------------=20 A charter proposal must consist of a minimum of a problem statement and at least one milestone/deliverable. This deadline will allow time for consideration of proposals that could potentially be "dispatched" prior to the WG session. September 28th - Topics that are to be the focus of IETF-76 are announced.=20 ------------------------------------------------------------------------ ---=20 The idea here is to focus the discussion over the weeks preceding IETF-76 on these main topics, noting that any new or updates to any documents are due 3-4 weeks later. This will ensure we have constructive discussions before the meeting and are actually able to determine consensus as to where work should be progressed (e.g., separate BoF, a new WG, an existing WG, individual document, etc.) at IETF-76. Note, that the exact disposition for a topic may (per the usual process) require follow-up and confirmation by the ADS and/or IESG (e.g., for a new WG, Bof, individually sponsored document, etc.) or with another WG to ensure agreement with the DISPATCH WG consensus for the topic. As discussed previously, the intention is not necessarily to preclude folks submitting documents on other topics, however, it is very unlikely there would be agenda time allocated to documents/topics submitted after the deadlines. We can include one or two slides on these topics in the DISPATCH WG chair charts so that the authors can gather other interested parties to contribute to the work.=20 Regards,=20 Mary and Gonzalo=20 DISPATCH WG co-chairs=20 ------_=_NextPart_001_01CA3C06.8FFA8042 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF-76 DISPATCH WG deadlines
Dear all,
here is a proposal for the Charter. I missed = to sent it=20 to the whole list. I'm sorry for that.
So here for discussion:
 
The use of the Reason header field in = responses is=20 considered in RFC3326, doing so is not specified for any existing = response code.=20
Nevertheless for interoperabi= lity reason=20 between SIP and PSTN such behaviour = is needed and already deployed within many&= nbsp;networks.
A guideline to permit the use = of the=20 Reason header within Response is = needed.
 
Milestone:
May 2010 Guideline for Reason in = Responses  to=20 ISEG
 
Best=20 Regards
 
Roland

Von: Jesske, Roland =
Gesendet:=20 Donnerstag, 17. September 2009 14:22
An: 'Mary Barnes'; = 'Gonzalo=20 Camarillo'
Betreff: AW: [dispatch] IETF-76 DISPATCH WG=20 deadlines

Hi Mary and Gonzalo,
with regard to the mail of this morning I saw = that you=20 have already mentioned the reason issue.
Looking on this mail it seems to me that I = have to=20 write something for the Charter.
So I try my best:
 
The use of the Reason header field in = responses is=20 considered in RFC3326, doing so is not specified for any existing = response code.=20
Nevertheless for interoperabi= lity reason=20 between SIP and PSTN such behaviour = is needed and already deployed within many&= nbsp;networks.
A guideline to permit the use = of the=20 Reason header within Response is = needed.
 
Milestone:
May 2010 Guideline for Reason in = Responses  to=20 ISEG
 
Is the milestone correct or do I have to=20 differentiate?
 
I hope everything is correct.=20 Commons?
 
Thank you and Best=20 Regards
 
Roland

Von: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] Im Auftrag von Mary=20 Barnes
Gesendet: Freitag, 21. August 2009 18:25
An:=20 dispatch@ietf.org
Cc: = rai-ads@tools.ietf.org
Betreff:=20 [dispatch] IETF-76 DISPATCH WG deadlines

Hi all,

As was done for IETF-75, we are = setting=20 earlier deadlines for discussing topics in DISPATCH prior to the WG = session at=20 IETF-76. 

We will again follow the = deadlines for=20 BoFs:
http://www.ietf.org/meeting/cutoff-dates.html#76 =

This provides enough time to = dispatch topics=20 prior to the meeting as appropriate - e.g., mini-bofs, official bofs, = other WGs,=20 new WGs,  mailing lists, etc. Thus, allowing us to have more = focused and=20 constructive discussions on a smaller set of topics prior to the WG = session.=20

Please note that the dates are = much sooner=20 than you might expect as the time between IETF-75 and IETF-76 is 3 weeks = less=20 than the time between IETF-74 and IETF-75. The document deadlines are 9 = and 10=20 weeks away from next Monday (August 24th). 


Thus, the following are the = proposed=20 deadlines:

Sept 7th  - Cutoff date to = notify the=20 chairs and DISPATCH WG mailing list of plans to submit a = proposal.=20
----------------------------------------------------------------= ----------------------------------------=20

This will help folks with similar = topics to=20 work together before the meeting. If a preliminary charter proposal is = available=20 at this point, please include it.


September 21st - Cutoff for = charter proposals=20 for topics.
-------------------------------------------------------- =

A charter proposal must consist = of a minimum=20 of a problem statement and at least one milestone/deliverable. This = deadline=20 will allow time for consideration of proposals that could potentially be = "dispatched" prior to the WG session.


September 28th - Topics that are = to be the=20 focus of IETF-76 are announced.
----------------------------------------------------------------= -----------=20

The idea here is to focus the = discussion over=20 the weeks preceding IETF-76 on these main topics, noting that any new or = updates=20 to any documents are due 3-4 weeks later.  This will ensure we have = constructive discussions before the meeting and are actually able to = determine=20 consensus as to where work should be progressed (e.g., separate BoF, a = new WG,=20 an existing WG, individual document, etc.) at IETF-76. Note, that the = exact=20 disposition for a topic may (per the usual process) require follow-up = and=20 confirmation by the ADS and/or IESG (e.g., for a new WG, Bof, = individually=20 sponsored document, etc.) or with another WG to ensure agreement with = the=20 DISPATCH WG consensus for the topic.


As discussed previously, the = intention is not=20 necessarily to preclude folks submitting documents on other topics, = however, it=20 is very unlikely there would be agenda time allocated to = documents/topics=20 submitted after the deadlines. We can include one or two slides on these = topics=20 in the DISPATCH WG chair charts so that the authors can gather other = interested=20 parties to contribute to the work.

Regards,
Mary and Gonzalo
DISPATCH WG=20 co-chairs

------_=_NextPart_001_01CA3C06.8FFA8042-- From enrico.marocco@telecomitalia.it Wed Sep 23 00:11:50 2009 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 623A83A691E for ; Wed, 23 Sep 2009 00:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.331, 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 xUxjJG4CRzUU for ; Wed, 23 Sep 2009 00:11:44 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 0FB3E3A67A2 for ; Wed, 23 Sep 2009 00:11:42 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 23 Sep 2009 09:12:46 +0200 Received: from [163.162.173.6] (163.162.173.6) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Wed, 23 Sep 2009 09:12:46 +0200 Message-ID: <4AB9CA8B.6050701@telecomitalia.it> Date: Wed, 23 Sep 2009 09:13:15 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Christer Holmberg References: <4AB8E15E.8070802@telecomitalia.it> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060001070905030008060704" Cc: "dispatch@ietf.org" , Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS 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, 23 Sep 2009 07:11:50 -0000 --------------ms060001070905030008060704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, I'm probably not the right person to answer this, but as I understand the new RAI process, a non-template even package (that as per 3265 includes definitions of NOTIFY and SUBSCRIBE bodies as well as Event header parameters) that falls outside the scope of any existing WG may (should?) be submitted to dispatch as an individual contribution. However, since this would be the first time S.4.1 is run, I'd suggest to do that under the guidance of RAI management since the very beginning. Enrico Christer Holmberg wrote: > Hi Enrico, > > If an even package registration, in addition to the body used in the > NOTIFY request, also allows the definition of the XML body (and > possilbe event header parameters) which is needed in the SUBSCRIBE > request (in order to provide the conditions etc), then I agree that > it may be enough. > > Regards, > > Christer > > ________________________________ > > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] Sent: > Tue 22/09/2009 16:38 To: Christer Holmberg Cc: dispatch@ietf.org; > Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS > > > > Christer, I see value in a general mechanism for selectively retrieve > lists of URIs, but am wondering whether this is actually a charter > proposal (in such case I guess the text requires heavy rewording, > defining acronyms as a start) or just an event package registration > request according to rfc3427bis, S.4.1? > > Enrico > > Christer Holmberg wrote: >> Hi, >> >> Below is the proposed charter for CBUS. >> >> Regards, >> >> Christer >> >> ----------------------------------------- >> >> CBUS Charter. ============= >> >> Introduction: ------------- >> >> Various OMA service enablers need to be able to retrieve a list of >> addresses (URIs), where the users associated with the URIs fulfil >> certain conditions. User information is evaluated against the >> conditions, and the matches form a URI list. >> >> The need for the functionality originates from the OMA PoC service. >> However, there is ongoing work in OMA to define a common >> mechanism, called CBUS enabler (OMA-RD-CBUS-V1_0-20090203-C), to >> provide the functionality, so that it can be used for various types >> of services (e.g. messaging, gaming, conferencing and >> advertisement). >> >> The CBUS enabler provides the following functions: >> >> - Support for requestor initiated condition-based URIs selection >> requests. >> >> - Administration of conditions for URI selection. >> >> - Interaction with other enablers for retrieval of individual >> user's information (e.g. presence information, location >> information). >> >> - Evaluation of conditions and selection of matching individual >> users based on one time evaluation. >> >> - Re-evaluation of conditions and re-selection of matching >> individual users based on monitoring. >> >> - Aggregation of one-time evaluation results and monitoring results >> from different information sources. >> >> - Notification of evaluation results to requestor. >> >> The conditions can be based on user information which changes over >> time (e.g. presence information or geographical location), but they >> can also be based on more static user information (e.g. hobbies or >> personal interests). >> >> The entity which acts as requester, and provides the conditions to >> be used for the user information evaluation, is called CBUS client. >> The CBUS client usually resides on the user equipment, or an >> application server, which supports the CBUS enabler. >> >> The selection of URIs, based on the provided conditions, may be >> performed by taking a snapshot, i.e. by making a one-time >> evaluation of the user information to find out whether the >> conditions are fulfilled or not. The URI selection may also be >> performed by continous monitoring of the user information. >> >> >> Work and deliverables: ---------------------- >> >> The purpose of the work is to, based on the OMA CBUS requirements >> (OMA- RD-CBUS-V1_0-20090203-C), procude the SIP protocol >> information elements which are needed to implement the interface >> between the CBUS client and CBUS server, using the SIP >> SUBSCRIBE/NOTIFY framework (RFC 3265). >> >> >> The primary task for the work is to: >> >> 1. Procude a mechanism for a subscriber (CBUS client) to, when >> subscribing to an event package which contains a list of URI, >> provide conditions, candidate URIs and evaluation parameters to the >> notifier (CBUS server). >> >> The mechanism may be used on defining an XML based message body >> type, and SIP header field parameters. >> >> 2. Produce an event package, or possible re-use an existing event >> package, used to the notifier (CBUS server) to send URI lists >> (based on the conditions and candidate URIs) to the subscriber >> (CBUS client). >> >> The CBUS client actions triggered by the received URI list, and the >> interactions between the CBUS server and other enablers, are >> outside the scope of the work. >> >> >> The work is planned to take place in, or in co-operaton with, the >> SIPCORE WG. >> >> >> Goals and milestones: --------------------- >> >> Jan 2010 Working Group Last Call for the document which >> contains the mechanism for a subscriber to provide the needed CBUS >> information to the notifier, and contains the event package (if a >> new package is needed) for the notifier to provide the URI list to >> the subscriber. >> >> Mar 2010 Submit document to IESG as Proposed Standard --------------ms060001070905030008060704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5MjMwNzEzMTVaMCMG CSqGSIb3DQEJBDEWBBR8c9vDLyrWNEbuKVbrq1/9xjKrbjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAD7ec1bWotYj zVQUAkJsG4Cm2/PKEGkYzCxm3lM6UJPIws+vvNg94Aq5DxlbncqQuznU6WynVFICNW68YQIb S1uOxDc6p77NrHW/jstAhR5+2PB5C2rFjbSnOGzt4FbuoN/ed1yaB6KwK5HcEGk9jVM2YMrz RoxfQCcWvrnTPqLIGb4ZYDN01hCdQJtTgIHf97PuBFghw1LiP+tnQmlGE/ZD32QRWZ3foU2L HUfCuEbWGE9jhNv+Wsd6VngSjkdoHNBNnr7zRBoz83AEYFc5Nu9lKtvtJrLZbqrBNTxEYzBg QRvsimr3nu+S3MRFPBHGMTr4NYf+k8MPzSE5DSfA02IAAAAAAAA= --------------ms060001070905030008060704-- From christer.holmberg@ericsson.com Wed Sep 23 00:16:49 2009 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 6CF5328C0D9 for ; Wed, 23 Sep 2009 00:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HELO_EQ_SE=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 K0uZJjV-e9uB for ; Wed, 23 Sep 2009 00:16:48 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 941293A68C9 for ; Wed, 23 Sep 2009 00:16:47 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-0c-4ab9cb9f059a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D0.E7.22406.F9BC9BA4; Wed, 23 Sep 2009 09:17:51 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 09:17:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Sep 2009 09:17:50 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_005B_01CA3C37.1AD5AF80" Message-ID: In-Reply-To: <4AB9CA8B.6050701@telecomitalia.it> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposed: CBUS Thread-Index: Aco8HURn7Lge/Xm2RCK+tn912ZDDmQAAFVQg References: <4AB8E15E.8070802@telecomitalia.it> <4AB9CA8B.6050701@telecomitalia.it> From: "Christer Holmberg" To: "Enrico Marocco" X-OriginalArrivalTime: 23 Sep 2009 07:17:51.0488 (UTC) FILETIME=[F625F000:01CA3C1D] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS 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, 23 Sep 2009 07:16:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005B_01CA3C37.1AD5AF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I guess the chairs can give us guidance on this. I don't expect a new WG to be formed for this, but we were asked to provide a charter, so that's what I did :) Regards, Christer > -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Sent: 23. syyskuuta 2009 10:13 > To: Christer Holmberg > Cc: dispatch@ietf.org; Gonzalo Camarillo > Subject: Re: [dispatch] Charter proposed: CBUS > > Well, I'm probably not the right person to answer this, but > as I understand the new RAI process, a non-template even > package (that as per > 3265 includes definitions of NOTIFY and SUBSCRIBE bodies as > well as Event header parameters) that falls outside the scope > of any existing WG may (should?) be submitted to dispatch as > an individual contribution. > > However, since this would be the first time S.4.1 is run, I'd > suggest to do that under the guidance of RAI management since > the very beginning. > > Enrico > > Christer Holmberg wrote: > > Hi Enrico, > > > > If an even package registration, in addition to the body > used in the > > NOTIFY request, also allows the definition of the XML body (and > > possilbe event header parameters) which is needed in the SUBSCRIBE > > request (in order to provide the conditions etc), then I > agree that it > > may be enough. > > > > Regards, > > > > Christer > > > > ________________________________ > > > > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] Sent: > > Tue 22/09/2009 16:38 To: Christer Holmberg Cc: dispatch@ietf.org; > > Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS > > > > > > > > Christer, I see value in a general mechanism for > selectively retrieve > > lists of URIs, but am wondering whether this is actually a charter > > proposal (in such case I guess the text requires heavy rewording, > > defining acronyms as a start) or just an event package registration > > request according to rfc3427bis, S.4.1? > > > > Enrico > > > > Christer Holmberg wrote: > >> Hi, > >> > >> Below is the proposed charter for CBUS. > >> > >> Regards, > >> > >> Christer > >> > >> ----------------------------------------- > >> > >> CBUS Charter. ============= > >> > >> Introduction: ------------- > >> > >> Various OMA service enablers need to be able to retrieve a list of > >> addresses (URIs), where the users associated with the URIs fulfil > >> certain conditions. User information is evaluated against the > >> conditions, and the matches form a URI list. > >> > >> The need for the functionality originates from the OMA PoC service. > >> However, there is ongoing work in OMA to define a common > mechanism, > >> called CBUS enabler (OMA-RD-CBUS-V1_0-20090203-C), to provide the > >> functionality, so that it can be used for various types of > services > >> (e.g. messaging, gaming, conferencing and advertisement). > >> > >> The CBUS enabler provides the following functions: > >> > >> - Support for requestor initiated condition-based URIs selection > >> requests. > >> > >> - Administration of conditions for URI selection. > >> > >> - Interaction with other enablers for retrieval of > individual user's > >> information (e.g. presence information, location information). > >> > >> - Evaluation of conditions and selection of matching > individual users > >> based on one time evaluation. > >> > >> - Re-evaluation of conditions and re-selection of matching > individual > >> users based on monitoring. > >> > >> - Aggregation of one-time evaluation results and > monitoring results > >> from different information sources. > >> > >> - Notification of evaluation results to requestor. > >> > >> The conditions can be based on user information which changes over > >> time (e.g. presence information or geographical location), > but they > >> can also be based on more static user information (e.g. hobbies or > >> personal interests). > >> > >> The entity which acts as requester, and provides the > conditions to be > >> used for the user information evaluation, is called CBUS client. > >> The CBUS client usually resides on the user equipment, or an > >> application server, which supports the CBUS enabler. > >> > >> The selection of URIs, based on the provided conditions, may be > >> performed by taking a snapshot, i.e. by making a one-time > evaluation > >> of the user information to find out whether the conditions are > >> fulfilled or not. The URI selection may also be performed by > >> continous monitoring of the user information. > >> > >> > >> Work and deliverables: ---------------------- > >> > >> The purpose of the work is to, based on the OMA CBUS requirements > >> (OMA- RD-CBUS-V1_0-20090203-C), procude the SIP protocol > information > >> elements which are needed to implement the interface > between the CBUS > >> client and CBUS server, using the SIP SUBSCRIBE/NOTIFY > framework (RFC > >> 3265). > >> > >> > >> The primary task for the work is to: > >> > >> 1. Procude a mechanism for a subscriber (CBUS client) to, when > >> subscribing to an event package which contains a list of > URI, provide > >> conditions, candidate URIs and evaluation parameters to > the notifier > >> (CBUS server). > >> > >> The mechanism may be used on defining an XML based message > body type, > >> and SIP header field parameters. > >> > >> 2. Produce an event package, or possible re-use an existing event > >> package, used to the notifier (CBUS server) to send URI > lists (based > >> on the conditions and candidate URIs) to the subscriber (CBUS > >> client). > >> > >> The CBUS client actions triggered by the received URI > list, and the > >> interactions between the CBUS server and other enablers, > are outside > >> the scope of the work. > >> > >> > >> The work is planned to take place in, or in co-operaton with, the > >> SIPCORE WG. > >> > >> > >> Goals and milestones: --------------------- > >> > >> Jan 2010 Working Group Last Call for the document which > >> contains the mechanism for a subscriber to provide the needed CBUS > >> information to the notifier, and contains the event > package (if a new > >> package is needed) for the notifier to provide the URI list to the > >> subscriber. > >> > >> Mar 2010 Submit document to IESG as Proposed Standard > ------=_NextPart_000_005B_01CA3C37.1AD5AF80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQXjCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEOzCCAyOgAwIBAgIRAJVH75z4QARyornUiAPBkWswDQYJKoZIhvcNAQEFBQAw OTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Ew MTAeFw0wODA0MjQwNzQ1MjVaFw0xMTA0MjQwNzQ1MjJaMG8xETAPBgNVBAoMCEVyaWNzc29uMRow GAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEPMA0GA1UEBRMGTE1GQ0hIMS0wKwYJKoZIhvcNAQkB Fh5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAIEQRcFxzKUClXod2Fgx0hXOshVy2Tb+a/3Idz+tbTlkf6ctY/oiog7p1KAt2yhnHl0VNXYC 6HqeOdKVzXfFC/SXlSM5drm2zAQSCjp/sG8PJjX0i+Kdqsv1BtcAfDauavWu9xnxjxN2urorN4XE IB/7KyANnHBvYbfc6B9maq/zAgMBAAGjggGKMIIBhjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdo dHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFs ZGFwOi8vbGRhcC50cnVzdC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwl MjBDQTAxLG89RXJpY3Nzb24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAp BgNVHREEIjAggR5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYq hXBrAQEwMTAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWww HQYDVR0OBBYEFAh/qeNFQFeOQVkqjxEElbl724C1MB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVF sXZfYzCbMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEALkfHT85VI4KjtTfmNwdS wAX9HgA7Mo5R35LHQ5zi+On/XlK73aAhVT4YmYzQGPfRD1VM5CjDghkD1gPyV8sQGrViMjTkf3qz ZlzC0kPndA3IM9wHJMYsIPNxoqSSgF39GpxuJ35bXlliCcVeU/jmUJySnBOZKueYQVe0H8L1OYYT u9yMMSfOT3BgQ7a8up1T7MjDffAWOVOcx9csvbgXWugZyX2rnuANIkt/XLdiRDStLk6M1pr7rQHP 8ZLPwENu0/RhcnFdb8O0dIJslTwkZh3RrmAluhkptje3VKwvg9JkPiontpQqhtFgtcJoWteKRjv1 tiBZlEvfdA74nDpgZjCCBEUwggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEF BQAwRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1 YmxpYyBSb290IENBIHYxMB4XDTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4 QYFe1HACqavqNLwUGIqIEyHv1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl 84Sc+Fx09IrDU/SZSWFSfhqTu3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzG LSYWgt6/tpwuOH5lcfNfHWMcCYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0e XPujKT7tU5xxSI2SdceJqzUbAz2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEA AaOCATwwggE4MBIGA1UdEwEB/wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYI KwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/ MH2ge6B5hndsZGFwOi8vbGRhcC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJs aWMlMjBSb290JTIwQ0ElMjB2MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2Nh dGlvbmxpc3Q/YmFzZTAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZf YzCbMB8GA1UdIwQYMBaAFEXb8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2 AEoqQz+M3Ra9alkpn/YnwhXIv6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x /GK3in/mik8i/PK2/q8HutzYFSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/he wS8s6dFFn70w795xUwJBWZ67OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk +xQbgehCEi7mu3cXsaU1Xq3kMXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy 2iXGKjdlxlWTsdDyulXYz+OYCMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuG Wj0wDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMU UlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRow GAYDVQQKDBFUZWxpYVNvbmVyYSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJv b3QgQ0EgdjEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt +WZe5QKGnaVEQSyY7lICKF5DuVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5Nck dBWPWp/T2uaQdOAwgqHpN0pe1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgoox KnCS+ZjB5icWAg+Qd1QpQhF46H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBo pzQBj6s5SyVh8A+j5liDBjghXYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhME mytMNbGicR1mRH6tAgMBAAGjggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGd jDAdBgNVHQ4EFgQURdvwj7gaYqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYD VR0gBH4wfDA9BgkqhkiG9w0FBgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhLmNvbTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYS5jb20wcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0 eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2Vj dXJpdHlfMjA0OF92My5DUkwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos 2CnIm7/872ytSrEHWZgvhOUEkUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6 K7hidWBDOm46bNdM3ZwhMyDCfkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW 6r73coraDP8diOpiQouMvM6bKuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Ln e2oT0JI3pwdA2v6jO4p/OLHntP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg 1JRIliSphrqr9kbfwHdeVxPdOI5GtDYPMYICfjCCAnoCAQEwTjA5MREwDwYDVQQKDAhFcmljc3Nv bjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAlUfvnPhABHKiudSIA8GR azAJBgUrDgMCGgUAoIIBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTA5MjMwNzE3NTBaMCMGCSqGSIb3DQEJBDEWBBQYOOU0gA5inSPHWa4SV8IML1UtgjBdBgkr BgEEAYI3EAQxUDBOMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBMDECEQCVR++c+EAEcqK51IgDwZFrMF8GCyqGSIb3DQEJEAILMVCgTjA5MREw DwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEA lUfvnPhABHKiudSIA8GRazBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggq hkiG9w0CBTANBgkqhkiG9w0BAQEFAASBgHerXUbqnIxB/Oc+BRGE5OYT7m0UIbro/56n4ZXx/A6J j7peE/4nlGznRqR1/mannSXhUfKcPD8lZNCwZqxlxDfUKldM+FIZujnR9gtOdzyzEUB1TBSn+Sra KGygsdpRkPORF2RQBNI/15TymCZL0AMQEIEDSYO8ZAGIQyk8a95UAAAAAAAA ------=_NextPart_000_005B_01CA3C37.1AD5AF80-- From Simo.Veikkolainen@nokia.com Wed Sep 23 00:48:40 2009 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 D20063A6884 for ; Wed, 23 Sep 2009 00:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 lTBEhSPB0Nwy for ; Wed, 23 Sep 2009 00:48:39 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3C60A3A6800 for ; Wed, 23 Sep 2009 00:48:38 -0700 (PDT) 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 n8N7nPHo031784; Wed, 23 Sep 2009 10:49:31 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 10:49:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 10:49:29 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 23 Sep 2009 09:49:29 +0200 From: To: , Date: Wed, 23 Sep 2009 09:49:26 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco7h/hyh1IgRD9fTEeDdw1yE6OZLAAl6nIg Message-ID: References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com> In-Reply-To: <4AB8CFEC.8020703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Sep 2009 07:49:29.0657 (UTC) FILETIME=[618B8A90:01CA3C22] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 23 Sep 2009 07:48:40 -0000 Hi Paul and Emil, >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >Sent: 22 September, 2009 16:24 >To: Emil Ivov >Cc: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >Subject: Re: [dispatch] Charter proposal on combining SIP=20 >voice with XMPP IM and presence > >The issues Emil raises are good ones. >I think they should be in scope for this effort. I also think the issues Emil raises are very valid, and we would need to co= nsider those. > Thanks, > Paul > >Emil Ivov wrote: >> Hey Simo, >>=20 >> We've been considering and playing a similar mode of operation for a=20 >> couple of years now and some of the most delicate issues that we've=20 >> come across include "disambiguation of overlapping services=20 >and information" >> and "behaviour in cases of "half-failure". Here's what I mean: >>=20 >> What happens for example if a mixed client receives a message over=20 >> SIMPLE rather than XMPP. Should it be accepted and displayed to the=20 >> user? If yes, then where should a client reply (i.e. SIMPLE=20 >or XMPP)?=20 >> If we choose SIMPLE for how long should the client privilege SIMPLE=20 >> over XMPP and under what conditions. >>=20 >> What happens if a mixed client detects presence agent=20 >capabilities in=20 >> a SIP service? Should it ignore them and only go for XMPP, use them=20 >> for certain destinations only (e.g. destinations that we only have a=20 >> SIP address for such as conventional SIP phones), or duplicate all=20 >> information over the two protocols in which case: How should clients=20 >> handle conflicting presence information received via the two=20 >protocols? >>=20 >> How should we handle failures for only one of the services.=20 >For example: >> I am a mixed UA and am unable to connect to a SIP registrar but can=20 >> still use XMPP. Should I declare complete failure to the=20 >user? Should=20 >> I declare success but warn the user that some features won't=20 >work? If=20 >> possible, should I try to make up for the missing SIP services using=20 >> XMPP (and vice versa). Without addressing each issue separately, I would say we can provide normat= ive statements for some situations, but most likely some issues listed abov= e will have to be left for the implementation to deal with. As has been pointed out in earlier emails, there is no automatic correlatio= n of SIP and XMPP user id's and thus an AOR alice@example.com may not belon= g to the same person as the JID alice@example.com. This rules out the possi= bility of responding to a SIP MESSAGE with an XMPP stanza without= some a priori knowledge on Alice's identity in XMPP domain.=20 >From an end user's point of view it makes no difference which protocol is u= sed. Personally, I would not mind having all my messaging (IM's via differe= nt service providers, SMS, email etc.) visible in a single application view= , and let the application hide some of the complexity.=20 We have only covered some use cases in our document, but I agree we probabl= y need to take a look at other situations as well. We just need to be caref= ul in not exploding the scope of the work and thus delay the work.=20 Simo >> So, if you think the above are worth considering how about adding=20 >> something along these lines: >>=20 >> disambiguation: both XMPP and SIP define semantics that=20 >allow each of=20 >> the protocols to offer the complete set of services=20 >discussed in this=20 >> charter (i.e. voice, video, messaging, and presence). In=20 >environments=20 >> where one or more of these services are supported with both=20 >protocols=20 >> clients should be able to use a common procedure for=20 >determining which=20 >> one to use and under what conditions. >>=20 >> half-failures: in cases where use of one of the protocols becomes=20 >> impossible (e.g. due to a server failure) clients should be able to=20 >> follow clear procedures on how to behave, which services could they=20 >> try to reuse over the protocol that is still available and=20 >under what=20 >> conditions. >>=20 >> WDYT? >>=20 >> Emil >>=20 >>=20 >> Simo.Veikkolainen@nokia.com wrote: >>> Hello, >>> >>> Below is the draft charter text for our proposal on=20 >combining SIP voice with XMPP IM and presence. >>> >>> Comments are very welcome! >>> >>> Regards, >>> Simo >>> >>> >>> ----------------- >>> >>> >>> Combining SIP VoIP and XMPP IM/Presence=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Currently most standards-based Voice over IP (VoIP)=20 >deployments use the Session Initiation Protocol (SIP). In=20 >addition to providing basic voice service SIP has an extensive=20 >support for more advanced telephony features including=20 >interworking with the traditional Public Switched Telephone=20 >Network (PSTN). SIP is also gaining popularity in the field=20 >of video communication. At the same time, the Extensible=20 >Messaging and Presence Protocol (XMPP) is enjoying widespread=20 >usage in instant messaging and presence services. =20 >>> >>> Both SIP and XMPP offer extensions for voice as well as IM=20 >and presence (XMPP voice via the Jingle extension, and SIP=20 >IM/presence via SIMPLE protocols). However, widespread=20 >deployment of these extensions has not so far taken place. In=20 >order to speed up deployment of integrated VoIP and IM=20 >systems, SIP based voice and XMPP based IM/Presence could be=20 >combined in endpoints to offer a voice, IM and presence=20 >service without any changes to existing SIP and XMPP service=20 >infrastrucure.=20 >>> >>> The objective of this Working Group is to develop solutions for=20 >>> combining SIP based voice with XMPP based IM and Presence=20 >such that a=20 >>> unified user experience can be offered to end user. Specifically,=20 >>> solutions are needed on >>> - addressing; end users should be able to initiate sessions=20 >to a user identity in either SIP or XMPP domain. The=20 >corresponding user identity in the other protocol domain needs=20 >to be learned automatically. >>> - session correlation; endpoints need to be able to correlate voice=20 >>> sessions with IM/Presence such that they can be presented=20 >to the end=20 >>> user in a seamless fashion >>> - presence; it should be possible to change the XMPP=20 >presence status based on the user's activity in the SIP domain. >>> >>> The goal is to rely on existing service infrastructre, and=20 >new requirements should be imposed only to the endpoint.=20 >>> >>> Protocol interworking, that is, translation from one=20 >protocol to another, is out of scope of this WG. >>> >>> Milestones >>> Feb 2010 Problem statement and use cases submitted to IESG as=20 >>> Informational Dec 2010 Specification on combining SIP based=20 >voice and XMPP based IM/Presence in a seamless manner=20 >submitted to IESG as Proposed Standard. >>> >>> ----------------- >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>=20 >= From Simo.Veikkolainen@nokia.com Wed Sep 23 00:52:15 2009 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 37CF83A692D for ; Wed, 23 Sep 2009 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 qwKBFRvLwDxK for ; Wed, 23 Sep 2009 00:52:14 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 10B5E3A682F for ; Wed, 23 Sep 2009 00:52:13 -0700 (PDT) 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 n8N7qtb7001907; Wed, 23 Sep 2009 10:53:06 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 10:53:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 10:53:06 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 23 Sep 2009 09:53:06 +0200 From: To: , Date: Wed, 23 Sep 2009 09:53:05 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco7o+az3kDyMTrVRSq1IO3qOOXOqwAfo+Mg Message-ID: References: <4AB7F11A.5040907@stpeter.im> <4AB8E99C.5080200@stpeter.im> <4AB8F61E.5030304@stpeter.im> <24488C12-E0C5-4B29-9143-44979A85677A@edvina.net> <4AB8FDF4.10702@stpeter.im> <7BC6F3B3-346D-4352-B4DF-4404A216F53D@edvina.net> In-Reply-To: <7BC6F3B3-346D-4352-B4DF-4404A216F53D@edvina.net> 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-OriginalArrivalTime: 23 Sep 2009 07:53:06.0969 (UTC) FILETIME=[E312B890:01CA3C22] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 23 Sep 2009 07:52:15 -0000 =20 >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Olle E. Johansson >Sent: 22 September, 2009 19:44 >To: Peter Saint-Andre >Cc: dispatch@ietf.org >Subject: Re: [dispatch] Charter proposal on combining SIP=20 >voice with XMPP IM and presence > > >22 sep 2009 kl. 18.40 skrev Peter Saint-Andre: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/22/09 10:33 AM, Olle E. Johansson wrote: >>> >>> 22 sep 2009 kl. 18.06 skrev Peter Saint-Andre: >>> >>>> IMHO those activities will keep the XMPP WG chugging along for a=20 >>>> while and the SIP-XMPP work will not receive a lot of=20 >attention. If=20 >>>> we can move it over to a new, more focused WG then I am in favor,=20 >>>> because that will encourage faster progress, I think. >>> >>> Will a new working group mean a whole set of fresh new members with=20 >>> more time? >> >> Last I checked, fresh new members don't materialize out of thin air.=20 >> :) >I am aware of that issue... ;-) > >> >> My point is that *if* a new SIP-XMPP group is being chartered =20 >> anyway, it >> would be more productive to have all the SIP-XMPP work happening =20 >> there, >> because (1) most people involved in the XMPP WG are only=20 >interested in >> XMPP and the SIP-XMPP work is not top-of-mind for them, and (2) we =20 >> might >> be able to attract interest in SIP-XMPP work among implementers for =20 >> whom >> SIP-XMPP interworking/combinations are a pain point (that would =20 >> include >> client developers, server developers, and operators). If we reach =20 >> out to >> those folks and define a problem statement that captures=20 >what they are >> seeing in the implementation and deployment space, then yes=20 >we might =20 >> be >> able to attract some fresh new members. > >Agreed. I am very interested in the SIP-XMPP work. >I might just materialize at some point. Maybe not out of thin air =20 >though. I wouldn't expect new resources to pop up to complete the draft-saintandre-= * documents just by moving that work to another WG (if such was formed), bu= t otherwise I think it makes sense to concentrate this bulk of work togethe= r. Simo >/O >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch >= From emcho@sip-communicator.org Wed Sep 23 05:45:25 2009 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 8D9643A6830 for ; Wed, 23 Sep 2009 05:45:25 -0700 (PDT) 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, J_CHICKENPOX_43=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 c5U+UNRLGzkt for ; Wed, 23 Sep 2009 05:45:24 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 02F5D3A6359 for ; Wed, 23 Sep 2009 05:45:23 -0700 (PDT) Received: by fxm27 with SMTP id 27so516159fxm.42 for ; Wed, 23 Sep 2009 05:46:27 -0700 (PDT) Received: by 10.86.232.33 with SMTP id e33mr1966675fgh.71.1253709986892; Wed, 23 Sep 2009 05:46:26 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 4sm442996fge.7.2009.09.23.05.46.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Sep 2009 05:46:26 -0700 (PDT) Sender: Emil Ivov Message-ID: <4ABA18A0.5070603@sip-communicator.org> Date: Wed, 23 Sep 2009 14:46:24 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 23 Sep 2009 12:45:25 -0000 Hey Simo, Simo.Veikkolainen@nokia.com wrote: > As has been pointed out in earlier emails, there is no automatic > correlation of SIP and XMPP user id's and thus an AOR > alice@example.com may not belong to the same person as the JID > alice@example.com. This rules out the possibility of responding to a > SIP MESSAGE with an XMPP stanza without some a priori > knowledge on Alice's identity in XMPP domain. I understand why we would not want to rely on an implicit correlation like for example JID == AOR. However an explicit correlation such as an XMPP contact header in SIP messages and a SIP URI in the XMPP vcards would be very helpful. A XMPP+SIP user receiving a call from someone not on their contact list is likely to wish to add the remote party to their roster or send them instant messages. Not being able to do so would feel awkward to the user. > From an end user's point of view it makes no difference which > protocol is used. Personally, I would not mind having all my > messaging (IM's via different service providers, SMS, email etc.) > visible in a single application view, and let the application hide > some of the complexity. Not sure I understand. Does this mean that you expect messages to be traveling over both SIMPLE and XMPP? If yes, then we definitely need some priority rules. Cheers, Emil > > Simo > >>> So, if you think the above are worth considering how about adding >>> something along these lines: >>> >>> disambiguation: both XMPP and SIP define semantics that >> allow each of >>> the protocols to offer the complete set of services >> discussed in this >>> charter (i.e. voice, video, messaging, and presence). In >> environments >>> where one or more of these services are supported with both >> protocols >>> clients should be able to use a common procedure for >> determining which >>> one to use and under what conditions. >>> >>> half-failures: in cases where use of one of the protocols becomes >>> impossible (e.g. due to a server failure) clients should be able >>> to follow clear procedures on how to behave, which services >>> could they try to reuse over the protocol that is still available >>> and >> under what >>> conditions. >>> >>> WDYT? >>> >>> Emil >>> >>> >>> Simo.Veikkolainen@nokia.com wrote: >>>> Hello, >>>> >>>> Below is the draft charter text for our proposal on >> combining SIP voice with XMPP IM and presence. >>>> Comments are very welcome! >>>> >>>> Regards, Simo >>>> >>>> >>>> ----------------- >>>> >>>> >>>> Combining SIP VoIP and XMPP IM/Presence >>>> ======================================= >>>> >>>> Currently most standards-based Voice over IP (VoIP) >> deployments use the Session Initiation Protocol (SIP). In addition >> to providing basic voice service SIP has an extensive support for >> more advanced telephony features including interworking with the >> traditional Public Switched Telephone Network (PSTN). SIP is also >> gaining popularity in the field of video communication. At the same >> time, the Extensible Messaging and Presence Protocol (XMPP) is >> enjoying widespread usage in instant messaging and presence >> services. >>>> Both SIP and XMPP offer extensions for voice as well as IM >> and presence (XMPP voice via the Jingle extension, and SIP >> IM/presence via SIMPLE protocols). However, widespread deployment >> of these extensions has not so far taken place. In order to speed >> up deployment of integrated VoIP and IM systems, SIP based voice >> and XMPP based IM/Presence could be combined in endpoints to offer >> a voice, IM and presence service without any changes to existing >> SIP and XMPP service infrastrucure. >>>> The objective of this Working Group is to develop solutions for >>>> combining SIP based voice with XMPP based IM and Presence >> such that a >>>> unified user experience can be offered to end user. >>>> Specifically, solutions are needed on - addressing; end users >>>> should be able to initiate sessions >> to a user identity in either SIP or XMPP domain. The corresponding >> user identity in the other protocol domain needs to be learned >> automatically. >>>> - session correlation; endpoints need to be able to correlate >>>> voice sessions with IM/Presence such that they can be presented >>>> >>>> >> to the end >>>> user in a seamless fashion - presence; it should be possible to >>>> change the XMPP >> presence status based on the user's activity in the SIP domain. >>>> The goal is to rely on existing service infrastructre, and >> new requirements should be imposed only to the endpoint. >>>> Protocol interworking, that is, translation from one >> protocol to another, is out of scope of this WG. >>>> Milestones Feb 2010 Problem statement and use cases submitted >>>> to IESG as Informational Dec 2010 Specification on combining >>>> SIP based >> voice and XMPP based IM/Presence in a seamless manner submitted to >> IESG as Proposed Standard. >>>> ----------------- >>>> _______________________________________________ dispatch >>>> mailing list dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> -- 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 vkg@alcatel-lucent.com Wed Sep 23 06:51:18 2009 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 21F8D28C130 for ; Wed, 23 Sep 2009 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 b6GVJFHPVVNA for ; Wed, 23 Sep 2009 06:51:17 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id EE0C328C11F for ; Wed, 23 Sep 2009 06:51:16 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n8NDqM1B001230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Sep 2009 08:52:22 -0500 (CDT) 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 n8NDqLUD024467; Wed, 23 Sep 2009 08:52:22 -0500 (CDT) Message-ID: <4ABA2815.1040609@alcatel-lucent.com> Date: Wed, 23 Sep 2009 08:52:21 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Miniero References: <4AB780B4.3000601@alcatel-lucent.com> <20090922111123.fd4c0c36.lorenzo@meetecho.com> In-Reply-To: <20090922111123.fd4c0c36.lorenzo@meetecho.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.33 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter proposal: Session Recording Protocol 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, 23 Sep 2009 13:51:18 -0000 Lorenzo Miniero wrote: > Hi Vijay, > > as a group we find this subject very interesting, and so we definitely > support the charter proposal. We have a related draft on session > recording (even though it's quite focused on conferencing at the > moment) > > http://tools.ietf.org/html/draft-romano-dcon-recording-00 > > so we'd be glad to contribute to the work to be done in here. Lorenzo: Thank you for your note of support. I, as well as others on the SRP author list, did indeed look at your draft over the summer; IIRC, a good part of it is synchronizing other multimedia objects to the recorded source as well. We will be releasing an update to the requirements draft shortly, and it would be great to have you contribute to the discussion therein. Once again, thanks. - 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 salvatore.loreto@ericsson.com Wed Sep 23 07:51:15 2009 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 D3B8428C12D for ; Wed, 23 Sep 2009 07:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, HELO_EQ_SE=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 Y8YYIROH53bF for ; Wed, 23 Sep 2009 07:51:14 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0840A28C124 for ; Wed, 23 Sep 2009 07:51:13 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-ad-4aba2cf729a7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 86.B2.15624.7FC2ABA4; Wed, 23 Sep 2009 16:13:11 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 16:10:26 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 16:09:00 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A50FB2976; Wed, 23 Sep 2009 17:08:59 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6F28B21A17; Wed, 23 Sep 2009 17:08:59 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B25D72195C; Wed, 23 Sep 2009 17:08:58 +0300 (EEST) Message-ID: <4ABA2BFA.40209@ericsson.com> Date: Wed, 23 Sep 2009 17:08:58 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Paul Kyzivat References: <4AB75AC7.6080509@ericsson.com> <4AB79C7C.5010803@cisco.com> In-Reply-To: <4AB79C7C.5010803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 23 Sep 2009 14:09:00.0480 (UTC) FILETIME=[66036400:01CA3C57] X-Brightmail-Tracker: AAAAAA== Cc: IETF Dispatch , Gonzalo Camarillo Subject: Re: [dispatch] Charter Proposal for Disaggregated Media 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, 23 Sep 2009 14:51:16 -0000 Hi Paul, thanks for the comments, please see my answers in line cheers Sal Paul Kyzivat wrote: > I agree with the utility of such work. Comments inline. > > I don't understand the above. The disaggregated multimedia session > will not be established unless *something* takes the initiative to > establish it. IMO that thing, whatever it is, is acting as a > "controller". > > The mechanism you have proposed before distributes the "controller" > functionality across multiple nodes. There is something that causes a > new stream to be established as a separate sip session and causes that > to announce correlation with some other session. And then there is are > the devices at the far end, that maintain the correlation and do > required maintenance of the correlation as changes happen. > > Can you provide more definition of what you mean by "loosely coupled" > while recognizing that something needs to know enough to do the > initiation and maintenance of the correlation? > the "loosely couple control" is a scenario where you can easily remove, at any point, any of several devices involved in the conversation, and the other end of the conversation will remain unaffected. easily and at any point mean that you do not need to start a complicate mechanism before you can remove the device (e.g. you do not need to choose a new controller and transfer the control to it) of course loosely couple control still needs some sort of control, you are right. However the control could be easily a "distributed" control with a minimal amount of information, where, for example, each device involved in the conversation only knows the list of all the other devices involved in the conversation, but it does not need to know the full state "information" related to the dialog that each device has with the far end of the conversation. >> The objective of the proposed working group is to develop a framework >> for Disaggregated Media that include both improvements on existing >> mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms >> like a loosely coupled mechanism that does not require the >> implementation of complex logic on any of the terminals. > > I would argue that it is premature to assert that new mechanisms are > required. right, that is something the community has to decide. >> Specifically, the proposed working group will develop the following >> deliverables: 1. A framework document describing key design >> considerations for Disaggregated mediamechanism. >> 2. A specification for a loosely couple mechanism. >> 3. One or more specifications to improve existing mechanism to >> coordinate >> disaggregated media. > > Are both (2) and (3) *specifications*? Or is (2) a requirements > document that is then satisfied by (3)? yes (1) and (2) can be combined and then eventually produce a new actual mechanism. > > If (2) is requirements, then this makes sense to me, though it might > be possible to combine that with (1). If both (2) and (3) are > mechanism specs then I don't get it. > > Thanks, > Paul From RIFATYU@nortel.com Wed Sep 23 12:55:59 2009 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 F185E3A6882 for ; Wed, 23 Sep 2009 12:55:59 -0700 (PDT) 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 yDXOYErPOgys for ; Wed, 23 Sep 2009 12:55:59 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B49AC3A683A for ; Wed, 23 Sep 2009 12:55:58 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8NJuxW09119; Wed, 23 Sep 2009 19:57:00 GMT 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_01CA3C88.01864ECA" Date: Wed, 23 Sep 2009 15:56:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New topic proposal for DISPATCH Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgO+rxqA References: From: "Rifaat Shekh-Yusef" To: , , "Mary Barnes" , Cc: Markus.Isomaki@nokia.com Subject: Re: [dispatch] New topic proposal for DISPATCH 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, 23 Sep 2009 19:56:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3C88.01864ECA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Simo, Markus, =20 I am very interested in this work and I like your approach. =20 I have a question regarding the open issue you have in section 5.2: Why do you require the correlation-value to be an end-to-end identifier? In the case where there is an SBC that creates a new dialog for the target, would it not be enough for each endpoint to use the Call-ID of the other dialog as the correlation-value? =20 Thanks, Rifaat =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com Sent: Friday, September 04, 2009 8:09 AM To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsson.com Cc: Markus.Isomaki@nokia.com Subject: [dispatch] New topic proposal for DISPATCH Hi, =20 We would like to propose a new DISPATCH topic on how SIP and XMPP can be used together in a complementary fashion. =20 We have been working on a solution which combines SIP based VoIP and XMPP based IM and Presence. The requirements and a proposed solution is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 . =20 The motivation for this work comes from experience which shows that most standards based VoIP deployments use SIP. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is widely used in instant messaging and presence services. An interesting scenario arises when a SIP based voice (and video) service is combined together with an XMPP based instant messaging and presence service.=20 =20 Note that the goal in this work is not SIP-XMPP protocol translation, but to define protocol extensions and best practises such that SIP based VoIP and XMPP based IM and presence could be seamlessly combined and offered to the end user. For rapid deployment, we assume no changes in the server infrastructure, and instead impose new requirements and protocol extensions only to the endpoints. =20 We would like to get some discussion going on the use case itself as well as on the solution. Also, we would like to hear you thoughts on DISPATCH or a new "dispatched" mini-WG as the home for such work. =20 Exact charter proposal and problem statemen is to follow.=20 =20 Regards, Simo and Markus =20 =20 ------_=_NextPart_001_01CA3C88.01864ECA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Simo,=20 Markus,
 
I am=20 very interested in this work and I like your = approach.
 
I have=20 a question regarding the open issue you have in section = 5.2:
Why do=20 you require the correlation-value to be an end-to-end=20 identifier?
In the=20 case where there is an SBC that creates a new dialog for the = target,=20 would it not be enough for each endpoint to use the Call-ID = of the=20 other dialog as the correlation-value?
 
Thanks,
 Rifaat
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 Simo.Veikkolainen@nokia.com
Sent: Friday, September 04, = 2009 8:09=20 AM
To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Cc:=20 Markus.Isomaki@nokia.com
Subject: [dispatch] New topic = proposal for=20 DISPATCH

Hi,
 
We would like to propose a new DISPATCH topic on how SIP and XMPP = can be=20 used together in a complementary fashion.
 
We have been working on a solution which combines SIP based VoIP = and XMPP=20 based IM and Presence. The requirements and a proposed solution is = outlined in=20 http://tools.ietf.org/html/draft-veikkolainen-sip-voip= -xmpp-im-01.
 
The motivation for this work comes from experience which shows that = most=20 standards based VoIP deployments use SIP. At the same time, the = Extensible=20 Messaging and Presence Protocol (XMPP) is widely used in instant = messaging and=20 presence services. An interesting scenario arises when a SIP based voice = (and=20 video) service is combined together with an XMPP based instant messaging = and=20 presence service.
 
Note that the goal in this work is not SIP-XMPP protocol = translation, but=20 to define protocol extensions and best practises such that SIP based = VoIP and=20 XMPP based IM and presence could be seamlessly combined and offered to = the end=20 user. For rapid deployment, we assume no changes in the server = infrastructure,=20 and instead impose new requirements and protocol extensions only to the=20 endpoints.
 
We would like to get some discussion going on the use case itself = as well=20 as on the solution. Also, we would like to hear you thoughts on DISPATCH = or a=20 new "dispatched" mini-WG as the home for such work.
 
Exact charter proposal and problem statemen is to follow.
 
Regards,
Simo and Markus
 
 
------_=_NextPart_001_01CA3C88.01864ECA-- From pkyzivat@cisco.com Wed Sep 23 14:19:06 2009 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 661D83A6933 for ; Wed, 23 Sep 2009 14:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 9L8CxlRjEfSJ for ; Wed, 23 Sep 2009 14:19:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D460C3A67D7 for ; Wed, 23 Sep 2009 14:19:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKItukpAZnmf/2dsb2JhbAC+eYhPARCPbAWCIwoBBRULgUiLCg X-IronPort-AV: E=Sophos;i="4.44,440,1249257600"; d="scan'208";a="59591802" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Sep 2009 21:20:11 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8NLKBmS026376; Wed, 23 Sep 2009 17:20:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8NLKBWf011623; Wed, 23 Sep 2009 21:20:11 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 17:20:10 -0400 Received: from [161.44.182.195] ([161.44.182.195]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 17:20:10 -0400 Message-ID: <4ABA9109.8010702@cisco.com> Date: Wed, 23 Sep 2009 17:20:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2009 21:20:10.0347 (UTC) FILETIME=[A1A7D3B0:01CA3C93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7512; t=1253740811; x=1254604811; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Charter=20proposal=20on=20 combining=20SIP=20voice=20with=20XMPP=0A=20IM=20and=09presen ce |Sender:=20 |To:=20Simo.Veikkolainen@nokia.com; bh=C4a+gCGgIGADVkNT5gR+4VXA0CaAJI2EjCuXl1rJt6A=; b=DgFPgAOtVTRC9WiyxiKF7QmfFcV5nLcvg8O/NBNPR5BAku0t7VB/UDhWNa p4rwOHxhfpdbjEe8IJaI494CHSuRGrFi9vjSZkuJcA4pNP+3EMXSE1Zf3IgK pPVW74cNUj; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 23 Sep 2009 21:19:06 -0000 Simo, It would be a good start to *identify* these issues in whatever is produced, and discuss their resolution - even if all that is said is that a particular issue is ruled out of scope or unsolved in an initial release. I'd just like to have them *considered* rather than not even being mentioned. Thanks, Paul Simo.Veikkolainen@nokia.com wrote: > Hi Paul and Emil, > >> -----Original Message----- >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 22 September, 2009 16:24 >> To: Emil Ivov >> Cc: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >> Subject: Re: [dispatch] Charter proposal on combining SIP >> voice with XMPP IM and presence >> >> The issues Emil raises are good ones. >> I think they should be in scope for this effort. > > > I also think the issues Emil raises are very valid, and we would need to consider those. > >> Thanks, >> Paul >> >> Emil Ivov wrote: >>> Hey Simo, >>> >>> We've been considering and playing a similar mode of operation for a >>> couple of years now and some of the most delicate issues that we've >>> come across include "disambiguation of overlapping services >> and information" >>> and "behaviour in cases of "half-failure". Here's what I mean: >>> >>> What happens for example if a mixed client receives a message over >>> SIMPLE rather than XMPP. Should it be accepted and displayed to the >>> user? If yes, then where should a client reply (i.e. SIMPLE >> or XMPP)? >>> If we choose SIMPLE for how long should the client privilege SIMPLE >>> over XMPP and under what conditions. >>> >>> What happens if a mixed client detects presence agent >> capabilities in >>> a SIP service? Should it ignore them and only go for XMPP, use them >>> for certain destinations only (e.g. destinations that we only have a >>> SIP address for such as conventional SIP phones), or duplicate all >>> information over the two protocols in which case: How should clients >>> handle conflicting presence information received via the two >> protocols? >>> How should we handle failures for only one of the services. >> For example: >>> I am a mixed UA and am unable to connect to a SIP registrar but can >>> still use XMPP. Should I declare complete failure to the >> user? Should >>> I declare success but warn the user that some features won't >> work? If >>> possible, should I try to make up for the missing SIP services using >>> XMPP (and vice versa). > > Without addressing each issue separately, I would say we can provide normative statements for some situations, but most likely some issues listed above will have to be left for the implementation to deal with. > > As has been pointed out in earlier emails, there is no automatic correlation of SIP and XMPP user id's and thus an AOR alice@example.com may not belong to the same person as the JID alice@example.com. This rules out the possibility of responding to a SIP MESSAGE with an XMPP stanza without some a priori knowledge on Alice's identity in XMPP domain. > >>From an end user's point of view it makes no difference which protocol is used. Personally, I would not mind having all my messaging (IM's via different service providers, SMS, email etc.) visible in a single application view, and let the application hide some of the complexity. > > We have only covered some use cases in our document, but I agree we probably need to take a look at other situations as well. We just need to be careful in not exploding the scope of the work and thus delay the work. > > Simo > >>> So, if you think the above are worth considering how about adding >>> something along these lines: >>> >>> disambiguation: both XMPP and SIP define semantics that >> allow each of >>> the protocols to offer the complete set of services >> discussed in this >>> charter (i.e. voice, video, messaging, and presence). In >> environments >>> where one or more of these services are supported with both >> protocols >>> clients should be able to use a common procedure for >> determining which >>> one to use and under what conditions. >>> >>> half-failures: in cases where use of one of the protocols becomes >>> impossible (e.g. due to a server failure) clients should be able to >>> follow clear procedures on how to behave, which services could they >>> try to reuse over the protocol that is still available and >> under what >>> conditions. >>> >>> WDYT? >>> >>> Emil >>> >>> >>> Simo.Veikkolainen@nokia.com wrote: >>>> Hello, >>>> >>>> Below is the draft charter text for our proposal on >> combining SIP voice with XMPP IM and presence. >>>> Comments are very welcome! >>>> >>>> Regards, >>>> Simo >>>> >>>> >>>> ----------------- >>>> >>>> >>>> Combining SIP VoIP and XMPP IM/Presence >>>> ======================================= >>>> >>>> Currently most standards-based Voice over IP (VoIP) >> deployments use the Session Initiation Protocol (SIP). In >> addition to providing basic voice service SIP has an extensive >> support for more advanced telephony features including >> interworking with the traditional Public Switched Telephone >> Network (PSTN). SIP is also gaining popularity in the field >> of video communication. At the same time, the Extensible >> Messaging and Presence Protocol (XMPP) is enjoying widespread >> usage in instant messaging and presence services. >>>> Both SIP and XMPP offer extensions for voice as well as IM >> and presence (XMPP voice via the Jingle extension, and SIP >> IM/presence via SIMPLE protocols). However, widespread >> deployment of these extensions has not so far taken place. In >> order to speed up deployment of integrated VoIP and IM >> systems, SIP based voice and XMPP based IM/Presence could be >> combined in endpoints to offer a voice, IM and presence >> service without any changes to existing SIP and XMPP service >> infrastrucure. >>>> The objective of this Working Group is to develop solutions for >>>> combining SIP based voice with XMPP based IM and Presence >> such that a >>>> unified user experience can be offered to end user. Specifically, >>>> solutions are needed on >>>> - addressing; end users should be able to initiate sessions >> to a user identity in either SIP or XMPP domain. The >> corresponding user identity in the other protocol domain needs >> to be learned automatically. >>>> - session correlation; endpoints need to be able to correlate voice >>>> sessions with IM/Presence such that they can be presented >> to the end >>>> user in a seamless fashion >>>> - presence; it should be possible to change the XMPP >> presence status based on the user's activity in the SIP domain. >>>> The goal is to rely on existing service infrastructre, and >> new requirements should be imposed only to the endpoint. >>>> Protocol interworking, that is, translation from one >> protocol to another, is out of scope of this WG. >>>> Milestones >>>> Feb 2010 Problem statement and use cases submitted to IESG as >>>> Informational Dec 2010 Specification on combining SIP based >> voice and XMPP based IM/Presence in a seamless manner >> submitted to IESG as Proposed Standard. >>>> ----------------- >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> From Simo.Veikkolainen@nokia.com Wed Sep 23 23:35:08 2009 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 5FA2B3A6902 for ; Wed, 23 Sep 2009 23:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_43=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 BgNDu73xyMjV for ; Wed, 23 Sep 2009 23:35:07 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E98693A6894 for ; Wed, 23 Sep 2009 23:35:06 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8O6YZ7i026857; Thu, 24 Sep 2009 01:35:04 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 09:35:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 09:35:41 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 24 Sep 2009 08:35:40 +0200 From: To: Date: Thu, 24 Sep 2009 08:34:17 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco8S+cMO7KxnhegR5GAnpgsgLQBZgAku7Gg Message-ID: References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com> <4ABA18A0.5070603@sip-communicator.org> In-Reply-To: <4ABA18A0.5070603@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Sep 2009 06:35:41.0630 (UTC) FILETIME=[3CA5FDE0:01CA3CE1] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 06:35:08 -0000 =20 >-----Original Message----- >From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf=20 >Of ext Emil Ivov >Sent: 23 September, 2009 15:46 >To: Veikkolainen Simo (Nokia-D/Helsinki) >Cc: pkyzivat@cisco.com; dispatch@ietf.org >Subject: Re: [dispatch] Charter proposal on combining SIP=20 >voice with XMPP IM and presence > >Hey Simo, > >Simo.Veikkolainen@nokia.com wrote: >> As has been pointed out in earlier emails, there is no automatic=20 >> correlation of SIP and XMPP user id's and thus an AOR=20 >> alice@example.com may not belong to the same person as the JID=20 >> alice@example.com. This rules out the possibility of responding to a=20 >> SIP MESSAGE with an XMPP stanza without some a priori=20 >> knowledge on Alice's identity in XMPP domain. > >I understand why we would not want to rely on an implicit=20 >correlation like for example JID =3D=3D AOR. However an explicit=20 >correlation such as an XMPP contact header in SIP messages and=20 >a SIP URI in the XMPP vcards would be very helpful. A XMPP+SIP=20 >user receiving a call from someone not on their contact list=20 >is likely to wish to add the remote party to their roster or=20 >send them instant messages. Not being able to do so would feel=20 >awkward to the user. Yes. Explicit correlation (carrying SIP identities in XMPP or vice versa) i= s what we proposed in our draft, and we think could indeed be useful. > >> From an end user's point of view it makes no difference=20 >which protocol=20 >> is used. Personally, I would not mind having all my messaging (IM's=20 >> via different service providers, SMS, email etc.) visible in=20 >a single=20 >> application view, and let the application hide some of the=20 >complexity. > >Not sure I understand. Does this mean that you expect messages=20 >to be traveling over both SIMPLE and XMPP? If yes, then we=20 >definitely need some priority rules. What I meant was that from a UI point of view, all the end user needs to se= e is a contact name and possibility send a message (or call). A lot of the = complexity of selecting the actual protocol *could* be hidden by the applic= ation. This may not be what all application developers wish, but for exampl= e the phonebooks in some mobile devices seem to be going to that direction,= combining IM and SMS in one "conversation" view. So, for example, if a user wants the send an initial message to a contact w= hose both SIP and XMPP IDs are known, the app could do the selection of pro= tocol, depending on the other user's presence information. However, when re= sponding to a message in a conversation, it probably is better to use the s= ame protocol that was used when sending, unless the client knows that the o= ther client's UI can render the messages in the same conversation view.=20 So, I'll I'm saying is we need to carefully consider making normative state= ments that could potentially limit the application design and usability.=20 Simo >Cheers, >Emil > > >>=20 >> Simo >>=20 >>>> So, if you think the above are worth considering how about adding =20 >>>> something along these lines: >>>>=20 >>>> disambiguation: both XMPP and SIP define semantics that >>> allow each of >>>> the protocols to offer the complete set of services >>> discussed in this >>>> charter (i.e. voice, video, messaging, and presence). In >>> environments >>>> where one or more of these services are supported with both >>> protocols >>>> clients should be able to use a common procedure for >>> determining which >>>> one to use and under what conditions. >>>>=20 >>>> half-failures: in cases where use of one of the protocols becomes =20 >>>> impossible (e.g. due to a server failure) clients should=20 >be able to=20 >>>> follow clear procedures on how to behave, which services=20 >could they=20 >>>> try to reuse over the protocol that is still available and >>> under what >>>> conditions. >>>>=20 >>>> WDYT? >>>>=20 >>>> Emil >>>>=20 >>>>=20 >>>> Simo.Veikkolainen@nokia.com wrote: >>>>> Hello, >>>>>=20 >>>>> Below is the draft charter text for our proposal on >>> combining SIP voice with XMPP IM and presence. >>>>> Comments are very welcome! >>>>>=20 >>>>> Regards, Simo >>>>>=20 >>>>>=20 >>>>> ----------------- >>>>>=20 >>>>>=20 >>>>> Combining SIP VoIP and XMPP IM/Presence=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> Currently most standards-based Voice over IP (VoIP) >>> deployments use the Session Initiation Protocol (SIP). In=20 >addition =20 >>> to providing basic voice service SIP has an extensive support for=20 >>> more advanced telephony features including interworking with the=20 >>> traditional Public Switched Telephone Network (PSTN). SIP is also=20 >>> gaining popularity in the field of video communication. At=20 >the same =20 >>> time, the Extensible Messaging and Presence Protocol (XMPP) is=20 >>> enjoying widespread usage in instant messaging and presence=20 >services. >>>>> Both SIP and XMPP offer extensions for voice as well as IM >>> and presence (XMPP voice via the Jingle extension, and SIP=20 >>> IM/presence via SIMPLE protocols). However, widespread=20 >deployment of=20 >>> these extensions has not so far taken place. In order to speed up=20 >>> deployment of integrated VoIP and IM systems, SIP based voice and=20 >>> XMPP based IM/Presence could be combined in endpoints to offer a=20 >>> voice, IM and presence service without any changes to existing SIP=20 >>> and XMPP service infrastrucure. >>>>> The objective of this Working Group is to develop solutions for =20 >>>>> combining SIP based voice with XMPP based IM and Presence >>> such that a >>>>> unified user experience can be offered to end user.=20 >>>>> Specifically, solutions are needed on - addressing; end users=20 >>>>> should be able to initiate sessions >>> to a user identity in either SIP or XMPP domain. The corresponding=20 >>> user identity in the other protocol domain needs to be learned=20 >>> automatically. >>>>> - session correlation; endpoints need to be able to=20 >correlate voice=20 >>>>> sessions with IM/Presence such that they can be presented >>>>>=20 >>>>>=20 >>> to the end >>>>> user in a seamless fashion - presence; it should be possible to =20 >>>>> change the XMPP >>> presence status based on the user's activity in the SIP domain. >>>>> The goal is to rely on existing service infrastructre, and >>> new requirements should be imposed only to the endpoint. >>>>> Protocol interworking, that is, translation from one >>> protocol to another, is out of scope of this WG. >>>>> Milestones Feb 2010 Problem statement and use cases submitted to=20 >>>>> IESG as Informational Dec 2010 Specification on combining=20 >SIP based >>> voice and XMPP based IM/Presence in a seamless manner submitted to=20 >>> IESG as Proposed Standard. >>>>> ----------------- >>>>> _______________________________________________ dispatch mailing=20 >>>>> 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 Simo.Veikkolainen@nokia.com Wed Sep 23 23:35:11 2009 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 E3D873A6894 for ; Wed, 23 Sep 2009 23:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 vsoPy36q-a1Y for ; Wed, 23 Sep 2009 23:35:10 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8F76E3A695C for ; Wed, 23 Sep 2009 23:35:10 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8O6XWgc026005; Thu, 24 Sep 2009 01:35:28 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 09:36:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 09:35:56 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 24 Sep 2009 08:35:39 +0200 From: To: Date: Thu, 24 Sep 2009 08:35:39 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco8k6YKhck/a76qQgyNGnfxVqeh0AASvXuA Message-ID: References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com> <4ABA9109.8010702@cisco.com> In-Reply-To: <4ABA9109.8010702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Sep 2009 06:35:56.0491 (UTC) FILETIME=[458199B0:01CA3CE1] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 06:35:12 -0000 =20 >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >Sent: 24 September, 2009 00:20 >To: Veikkolainen Simo (Nokia-D/Helsinki) >Cc: emcho@sip-communicator.org; dispatch@ietf.org >Subject: Re: [dispatch] Charter proposal on combining SIP=20 >voice with XMPP IM and presence > >Simo, > >It would be a good start to *identify* these issues in=20 >whatever is produced, and discuss their resolution - even if=20 >all that is said is that a particular issue is ruled out of=20 >scope or unsolved in an initial release. I'd just like to have=20 >them *considered* rather than not even being mentioned. Agreed. I also think we cannot just bypass these; they are anyways the prac= tical problems implementors are going to face. Simo > Thanks, > Paul > >Simo.Veikkolainen@nokia.com wrote: >> Hi Paul and Emil, >>=20 >>> -----Original Message----- >>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 22 September, 2009 16:24 >>> To: Emil Ivov >>> Cc: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org >>> Subject: Re: [dispatch] Charter proposal on combining SIP=20 >voice with=20 >>> XMPP IM and presence >>> >>> The issues Emil raises are good ones. >>> I think they should be in scope for this effort. >>=20 >>=20 >> I also think the issues Emil raises are very valid, and we=20 >would need to consider those. >>=20 >>> Thanks, >>> Paul >>> >>> Emil Ivov wrote: >>>> Hey Simo, >>>> >>>> We've been considering and playing a similar mode of=20 >operation for a=20 >>>> couple of years now and some of the most delicate issues=20 >that we've=20 >>>> come across include "disambiguation of overlapping services >>> and information" >>>> and "behaviour in cases of "half-failure". Here's what I mean: >>>> >>>> What happens for example if a mixed client receives a message over=20 >>>> SIMPLE rather than XMPP. Should it be accepted and=20 >displayed to the=20 >>>> user? If yes, then where should a client reply (i.e. SIMPLE >>> or XMPP)?=20 >>>> If we choose SIMPLE for how long should the client=20 >privilege SIMPLE=20 >>>> over XMPP and under what conditions. >>>> >>>> What happens if a mixed client detects presence agent >>> capabilities in >>>> a SIP service? Should it ignore them and only go for XMPP,=20 >use them=20 >>>> for certain destinations only (e.g. destinations that we=20 >only have a=20 >>>> SIP address for such as conventional SIP phones), or duplicate all=20 >>>> information over the two protocols in which case: How=20 >should clients=20 >>>> handle conflicting presence information received via the two >>> protocols? >>>> How should we handle failures for only one of the services.=20 >>> For example: >>>> I am a mixed UA and am unable to connect to a SIP=20 >registrar but can=20 >>>> still use XMPP. Should I declare complete failure to the >>> user? Should >>>> I declare success but warn the user that some features won't >>> work? If >>>> possible, should I try to make up for the missing SIP=20 >services using=20 >>>> XMPP (and vice versa). >>=20 >> Without addressing each issue separately, I would say we can=20 >provide normative statements for some situations, but most=20 >likely some issues listed above will have to be left for the=20 >implementation to deal with. >>=20 >> As has been pointed out in earlier emails, there is no=20 >automatic correlation of SIP and XMPP user id's and thus an=20 >AOR alice@example.com may not belong to the same person as the=20 >JID alice@example.com. This rules out the possibility of=20 >responding to a SIP MESSAGE with an XMPP stanza=20 >without some a priori knowledge on Alice's identity in XMPP domain.=20 >>=20 >>>From an end user's point of view it makes no difference=20 >which protocol is used. Personally, I would not mind having=20 >all my messaging (IM's via different service providers, SMS,=20 >email etc.) visible in a single application view, and let the=20 >application hide some of the complexity.=20 >>=20 >> We have only covered some use cases in our document, but I=20 >agree we probably need to take a look at other situations as=20 >well. We just need to be careful in not exploding the scope of=20 >the work and thus delay the work.=20 >>=20 >> Simo >>=20 >>>> So, if you think the above are worth considering how about adding=20 >>>> something along these lines: >>>> >>>> disambiguation: both XMPP and SIP define semantics that >>> allow each of >>>> the protocols to offer the complete set of services >>> discussed in this >>>> charter (i.e. voice, video, messaging, and presence). In >>> environments >>>> where one or more of these services are supported with both >>> protocols >>>> clients should be able to use a common procedure for >>> determining which >>>> one to use and under what conditions. >>>> >>>> half-failures: in cases where use of one of the protocols becomes=20 >>>> impossible (e.g. due to a server failure) clients should=20 >be able to=20 >>>> follow clear procedures on how to behave, which services=20 >could they=20 >>>> try to reuse over the protocol that is still available and >>> under what >>>> conditions. >>>> >>>> WDYT? >>>> >>>> Emil >>>> >>>> >>>> Simo.Veikkolainen@nokia.com wrote: >>>>> Hello, >>>>> >>>>> Below is the draft charter text for our proposal on >>> combining SIP voice with XMPP IM and presence. >>>>> Comments are very welcome! >>>>> >>>>> Regards, >>>>> Simo >>>>> >>>>> >>>>> ----------------- >>>>> >>>>> >>>>> Combining SIP VoIP and XMPP IM/Presence=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> Currently most standards-based Voice over IP (VoIP) >>> deployments use the Session Initiation Protocol (SIP). In addition=20 >>> to providing basic voice service SIP has an extensive support for=20 >>> more advanced telephony features including interworking with the=20 >>> traditional Public Switched Telephone Network (PSTN). SIP is also=20 >>> gaining popularity in the field of video communication. At the same=20 >>> time, the Extensible Messaging and Presence Protocol (XMPP) is=20 >>> enjoying widespread usage in instant messaging and presence=20 >services. >>>>> Both SIP and XMPP offer extensions for voice as well as IM >>> and presence (XMPP voice via the Jingle extension, and SIP=20 >>> IM/presence via SIMPLE protocols). However, widespread=20 >deployment of=20 >>> these extensions has not so far taken place. In order to speed up=20 >>> deployment of integrated VoIP and IM systems, SIP based voice and=20 >>> XMPP based IM/Presence could be combined in endpoints to offer a=20 >>> voice, IM and presence service without any changes to existing SIP=20 >>> and XMPP service infrastrucure. >>>>> The objective of this Working Group is to develop solutions for=20 >>>>> combining SIP based voice with XMPP based IM and Presence >>> such that a >>>>> unified user experience can be offered to end user. Specifically,=20 >>>>> solutions are needed on >>>>> - addressing; end users should be able to initiate sessions >>> to a user identity in either SIP or XMPP domain. The corresponding=20 >>> user identity in the other protocol domain needs to be learned=20 >>> automatically. >>>>> - session correlation; endpoints need to be able to=20 >correlate voice=20 >>>>> sessions with IM/Presence such that they can be presented >>> to the end >>>>> user in a seamless fashion >>>>> - presence; it should be possible to change the XMPP >>> presence status based on the user's activity in the SIP domain. >>>>> The goal is to rely on existing service infrastructre, and >>> new requirements should be imposed only to the endpoint.=20 >>>>> Protocol interworking, that is, translation from one >>> protocol to another, is out of scope of this WG. >>>>> Milestones >>>>> Feb 2010 Problem statement and use cases submitted to IESG as=20 >>>>> Informational Dec 2010 Specification on combining SIP based >>> voice and XMPP based IM/Presence in a seamless manner submitted to=20 >>> IESG as Proposed Standard. >>>>> ----------------- >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >= From Markus.Isomaki@nokia.com Wed Sep 23 23:53:42 2009 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 461D13A68DE for ; Wed, 23 Sep 2009 23:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.218, 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 9p3sBzm-g6FA for ; Wed, 23 Sep 2009 23:53:41 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4AECB3A6824 for ; Wed, 23 Sep 2009 23:53:40 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8O6sQ1r015636; Thu, 24 Sep 2009 09:54:35 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 09:54:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 09:54:14 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 24 Sep 2009 08:54:05 +0200 From: To: , , , , Date: Thu, 24 Sep 2009 08:54:03 +0200 Thread-Topic: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgO+rxqAACPN20A= Message-ID: References: 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_B3F72E5548B10A4A8E6F4795430F84181ABA1FADB2NOKEUMSG02mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Sep 2009 06:54:14.0861 (UTC) FILETIME=[D42F8FD0:01CA3CE3] X-Nokia-AV: Clean Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/XMPP 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, 24 Sep 2009 06:53:42 -0000 --_000_B3F72E5548B10A4A8E6F4795430F84181ABA1FADB2NOKEUMSG02mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rifaat, In our proposal the correlation works so that: 1. UAs engaged in a SIP session/dialog exchange an identifier related to th= at session (as well as their XMPP full JIDs) 2. They insert them in the very first XMPP messages they subsequently excha= nge, in order to correlate that exchange to be related to the SIP session. The correlation identifier has to be end-to-end, otherwise the other end wo= n't be able to use it for correlation. Call-ID is often changed enroute. So= , if one endpoint puts it in an XMPP messages as a reference to a SIP sessi= on, the other endpoint won't recognize it as it has a different Call-ID for= the same session. Markus ________________________________ From: ext Rifaat Shekh-Yusef [mailto:rifatyu@nortel.com] Sent: 23 September, 2009 22:57 To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; Mary Barnes; g= onzalo.camarillo@ericsson.com Cc: Isomaki Markus (Nokia-CIC/Espoo) Subject: RE: [dispatch] New topic proposal for DISPATCH Simo, Markus, I am very interested in this work and I like your approach. I have a question regarding the open issue you have in section 5.2: Why do you require the correlation-value to be an end-to-end identifier? In the case where there is an SBC that creates a new dialog for the target,= would it not be enough for each endpoint to use the Call-ID of the other d= ialog as the correlation-value? Thanks, Rifaat ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Simo.Veikkolainen@nokia.com Sent: Friday, September 04, 2009 8:09 AM To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsso= n.com Cc: Markus.Isomaki@nokia.com Subject: [dispatch] New topic proposal for DISPATCH Hi, We would like to propose a new DISPATCH topic on how SIP and XMPP can be us= ed together in a complementary fashion. We have been working on a solution which combines SIP based VoIP and XMPP b= ased IM and Presence. The requirements and a proposed solution is outlined = in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01. The motivation for this work comes from experience which shows that most st= andards based VoIP deployments use SIP. At the same time, the Extensible Me= ssaging and Presence Protocol (XMPP) is widely used in instant messaging an= d presence services. An interesting scenario arises when a SIP based voice = (and video) service is combined together with an XMPP based instant messagi= ng and presence service. Note that the goal in this work is not SIP-XMPP protocol translation, but t= o define protocol extensions and best practises such that SIP based VoIP an= d XMPP based IM and presence could be seamlessly combined and offered to th= e end user. For rapid deployment, we assume no changes in the server infras= tructure, and instead impose new requirements and protocol extensions only = to the endpoints. We would like to get some discussion going on the use case itself as well a= s on the solution. Also, we would like to hear you thoughts on DISPATCH or = a new "dispatched" mini-WG as the home for such work. Exact charter proposal and problem statemen is to follow. Regards, Simo and Markus --_000_B3F72E5548B10A4A8E6F4795430F84181ABA1FADB2NOKEUMSG02mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rifaat,
 
In our proposal the correlation works so=20 that:
1. UAs engaged in a SIP session/dialog exchange = an=20 identifier related to that session (as well as their XMPP full=20 JIDs)
2. They insert them in the very first XMPP messa= ges=20 they subsequently exchange, in order to correlate that exchange to be relat= ed to=20 the SIP session.
 
The correlation identifier has to be end-to-end,= =20 otherwise the other end won't be able to use it for correlation. Call-ID is= =20 often changed enroute. So, if one endpoint puts it in an XMPP messages as a= =20 reference to a SIP session, the other endpoint won't recognize it as it has= a=20 different Call-ID for the same session.
 
Markus

From: ext Rifaat Shekh-Yusef=20 [mailto:rifatyu@nortel.com]
Sent: 23 September, 2009=20 22:57
To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.o= rg;=20 Mary Barnes; gonzalo.camarillo@ericsson.com
Cc: Isomaki Markus= =20 (Nokia-CIC/Espoo)
Subject: RE: [dispatch] New topic proposal fo= r=20 DISPATCH

Simo, Markus,
 
I am=20 very interested in this work and I like your approach.
 
I=20 have a question regarding the open issue you have in section=20 5.2:
Why=20 do you require the correlation-value to be an end-to-end=20 identifier?
In=20 the case where there is an SBC that creates a new dialog for the tar= get,=20 would it not be enough for each endpoint to use the Call-ID of th= e other=20 dialog as the correlation-value?
 
Thanks,
 Rifaat
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 Simo.Veikkolainen@nokia.com
Sent: Friday, September 04, 200= 9=20 8:09 AM
To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Cc:=20 Markus.Isomaki@nokia.com
Subject: [dispatch] New topic proposal= for=20 DISPATCH

Hi,
 
We would like to propose a new DISPATCH topic on how SIP and XMPP ca= n be=20 used together in a complementary fashion.
 
We have been working on a solution which combines SIP based VoIP and= XMPP=20 based IM and Presence. The requirements and a proposed solution is outlin= ed in=20 http://tools.ietf.org/html/draft-veikkolainen-sip-voip= -xmpp-im-01.
 
The motivation for this work comes from experience which shows that = most=20 standards based VoIP deployments use SIP. At the same time, the Extensibl= e=20 Messaging and Presence Protocol (XMPP) is widely used in instant messagin= g and=20 presence services. An interesting scenario arises when a SIP based voice = (and=20 video) service is combined together with an XMPP based instant messaging = and=20 presence service.
 
Note that the goal in this work is not SIP-XMPP protocol translation= , but=20 to define protocol extensions and best practises such that SIP based VoIP= and=20 XMPP based IM and presence could be seamlessly combined and offered to th= e end=20 user. For rapid deployment, we assume no changes in the server infrastruc= ture,=20 and instead impose new requirements and protocol extensions only to the=20 endpoints.
 
We would like to get some discussion going on the use case itself as= well=20 as on the solution. Also, we would like to hear you thoughts on DISPATCH = or a=20 new "dispatched" mini-WG as the home for such work.
 
Exact charter proposal and problem statemen is to follow.
 
Regards,
Simo and Markus
 
 
--_000_B3F72E5548B10A4A8E6F4795430F84181ABA1FADB2NOKEUMSG02mgd_-- From gunnar.hellstrom@omnitor.se Thu Sep 24 02:49:17 2009 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 8F33F3A687F for ; Thu, 24 Sep 2009 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=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 59lNeo1VhgPO for ; Thu, 24 Sep 2009 02:49:16 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 9E0F63A6950 for ; Thu, 24 Sep 2009 02:49:15 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id F1499289F29 for ; Thu, 24 Sep 2009 11:50:24 +0200 (CEST) Received: (qmail 64307 invoked from network); 24 Sep 2009 09:50:21 -0000 Received: from 136.240.13.217.in-addr.dgcsystems.net (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[217.13.240.136]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with SMTP for ; 24 Sep 2009 09:50:21 -0000 From: "Gunnar Hellstrom" To: , References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com><4ABA18A0.5070603@sip-communicator.org> Date: Thu, 24 Sep 2009 11:50:29 +0200 Message-ID: <038101ca3cfc$738b13c0$e800a8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Aco8S+cMO7KxnhegR5GAnpgsgLQBZgAku7GgAAZbXmA= In-Reply-To: Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 09:49:17 -0000 There is another aspect of text communication that I would like to propose to bring into this charter. It is to provide a more "real-timish" text conversational mode, where the text is sent time-sampled in short chunks during its composition rather than waiting on user command to send a completed message. The presentation should then present the chunks consecutively until a delimiter is received. We have defined the real-time text mode for transmission with RTP, in RFC 4103, and want of course continue supporting that transport. With RTP it is realistic to get real real-time transmission, with transmission in 300 ms intervals. With XMPP, the overead makes it perhaps more realistic to transmit only once per second, but still get a quite useable real-timish result, that would be appreciated by the users. So, I suggest to bring real-timish text transmission of XMPP into this charter. Gunnar -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com Sent: Thursday, September 24, 2009 8:34 AM To: emcho@sip-communicator.org Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence >-----Original Message----- >From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of ext >Emil Ivov >Sent: 23 September, 2009 15:46 >To: Veikkolainen Simo (Nokia-D/Helsinki) >Cc: pkyzivat@cisco.com; dispatch@ietf.org >Subject: Re: [dispatch] Charter proposal on combining SIP voice with >XMPP IM and presence > >Hey Simo, > >Simo.Veikkolainen@nokia.com wrote: >> As has been pointed out in earlier emails, there is no automatic >> correlation of SIP and XMPP user id's and thus an AOR >> alice@example.com may not belong to the same person as the JID >> alice@example.com. This rules out the possibility of responding to a >> SIP MESSAGE with an XMPP stanza without some a priori >> knowledge on Alice's identity in XMPP domain. > >I understand why we would not want to rely on an implicit correlation >like for example JID == AOR. However an explicit correlation such as an >XMPP contact header in SIP messages and a SIP URI in the XMPP vcards >would be very helpful. A XMPP+SIP user receiving a call from someone >not on their contact list is likely to wish to add the remote party to >their roster or send them instant messages. Not being able to do so >would feel awkward to the user. Yes. Explicit correlation (carrying SIP identities in XMPP or vice versa) is what we proposed in our draft, and we think could indeed be useful. > >> From an end user's point of view it makes no difference >which protocol >> is used. Personally, I would not mind having all my messaging (IM's >> via different service providers, SMS, email etc.) visible in >a single >> application view, and let the application hide some of the >complexity. > >Not sure I understand. Does this mean that you expect messages to be >traveling over both SIMPLE and XMPP? If yes, then we definitely need >some priority rules. What I meant was that from a UI point of view, all the end user needs to see is a contact name and possibility send a message (or call). A lot of the complexity of selecting the actual protocol *could* be hidden by the application. This may not be what all application developers wish, but for example the phonebooks in some mobile devices seem to be going to that direction, combining IM and SMS in one "conversation" view. So, for example, if a user wants the send an initial message to a contact whose both SIP and XMPP IDs are known, the app could do the selection of protocol, depending on the other user's presence information. However, when responding to a message in a conversation, it probably is better to use the same protocol that was used when sending, unless the client knows that the other client's UI can render the messages in the same conversation view. So, I'll I'm saying is we need to carefully consider making normative statements that could potentially limit the application design and usability. Simo >Cheers, >Emil > > >> >> Simo >> >>>> So, if you think the above are worth considering how about adding >>>> something along these lines: >>>> >>>> disambiguation: both XMPP and SIP define semantics that >>> allow each of >>>> the protocols to offer the complete set of services >>> discussed in this >>>> charter (i.e. voice, video, messaging, and presence). In >>> environments >>>> where one or more of these services are supported with both >>> protocols >>>> clients should be able to use a common procedure for >>> determining which >>>> one to use and under what conditions. >>>> >>>> half-failures: in cases where use of one of the protocols becomes >>>> impossible (e.g. due to a server failure) clients should >be able to >>>> follow clear procedures on how to behave, which services >could they >>>> try to reuse over the protocol that is still available and >>> under what >>>> conditions. >>>> >>>> WDYT? >>>> >>>> Emil >>>> >>>> >>>> Simo.Veikkolainen@nokia.com wrote: >>>>> Hello, >>>>> >>>>> Below is the draft charter text for our proposal on >>> combining SIP voice with XMPP IM and presence. >>>>> Comments are very welcome! >>>>> >>>>> Regards, Simo >>>>> >>>>> >>>>> ----------------- >>>>> >>>>> >>>>> Combining SIP VoIP and XMPP IM/Presence >>>>> ======================================= >>>>> >>>>> Currently most standards-based Voice over IP (VoIP) >>> deployments use the Session Initiation Protocol (SIP). In >addition >>> to providing basic voice service SIP has an extensive support for >>> more advanced telephony features including interworking with the >>> traditional Public Switched Telephone Network (PSTN). SIP is also >>> gaining popularity in the field of video communication. At >the same >>> time, the Extensible Messaging and Presence Protocol (XMPP) is >>> enjoying widespread usage in instant messaging and presence >services. >>>>> Both SIP and XMPP offer extensions for voice as well as IM >>> and presence (XMPP voice via the Jingle extension, and SIP >>> IM/presence via SIMPLE protocols). However, widespread >deployment of >>> these extensions has not so far taken place. In order to speed up >>> deployment of integrated VoIP and IM systems, SIP based voice and >>> XMPP based IM/Presence could be combined in endpoints to offer a >>> voice, IM and presence service without any changes to existing SIP >>> and XMPP service infrastrucure. >>>>> The objective of this Working Group is to develop solutions for >>>>> combining SIP based voice with XMPP based IM and Presence >>> such that a >>>>> unified user experience can be offered to end user. >>>>> Specifically, solutions are needed on - addressing; end users >>>>> should be able to initiate sessions >>> to a user identity in either SIP or XMPP domain. The corresponding >>> user identity in the other protocol domain needs to be learned >>> automatically. >>>>> - session correlation; endpoints need to be able to >correlate voice >>>>> sessions with IM/Presence such that they can be presented >>>>> >>>>> >>> to the end >>>>> user in a seamless fashion - presence; it should be possible to >>>>> change the XMPP >>> presence status based on the user's activity in the SIP domain. >>>>> The goal is to rely on existing service infrastructre, and >>> new requirements should be imposed only to the endpoint. >>>>> Protocol interworking, that is, translation from one >>> protocol to another, is out of scope of this WG. >>>>> Milestones Feb 2010 Problem statement and use cases submitted to >>>>> IESG as Informational Dec 2010 Specification on combining >SIP based >>> voice and XMPP based IM/Presence in a seamless manner submitted to >>> IESG as Proposed Standard. >>>>> ----------------- >>>>> _______________________________________________ dispatch mailing >>>>> list dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> > >-- >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 __________ NOD32 4452 (20090924) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com From emcho@sip-communicator.org Thu Sep 24 03:06:12 2009 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 A97C53A696E for ; Thu, 24 Sep 2009 03:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_43=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 B1Wem2K1DBvF for ; Thu, 24 Sep 2009 03:06:11 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id A56573A687F for ; Thu, 24 Sep 2009 03:06:10 -0700 (PDT) Received: by fxm27 with SMTP id 27so1206777fxm.42 for ; Thu, 24 Sep 2009 03:07:14 -0700 (PDT) Received: by 10.86.227.13 with SMTP id z13mr2732758fgg.72.1253786834494; Thu, 24 Sep 2009 03:07:14 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id e20sm1112479fga.22.2009.09.24.03.07.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Sep 2009 03:07:11 -0700 (PDT) Sender: Emil Ivov Message-ID: <4ABB44CD.6000708@sip-communicator.org> Date: Thu, 24 Sep 2009 12:07:09 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Gunnar Hellstrom References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com><4ABA18A0.5070603@sip-communicator.org> <038101ca3cfc$738b13c0$e800a8c0@GunnarH> In-Reply-To: <038101ca3cfc$738b13c0$e800a8c0@GunnarH> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 10:06:12 -0000 Hey Gunnar, I am not sure I understand how this fits the XMPP+SIP work. Isn't it something that would be better suited by a pure XMPP entity such as the XMPP WG or xmpp.org? Or do you think that there's some aspect in this that can only be handled with SIP and another with XMPP? IIRC, that's one of the features that appear in Google Wave's demos so maybe there's already some XMPP related work in that direction. Cheers, Emil Gunnar Hellstrom wrote: > There is another aspect of text communication that I would like to propose > to bring into this charter. > > It is to provide a more "real-timish" text conversational mode, where the > text is sent time-sampled in short chunks during its composition rather than > waiting on user command to send a completed message. The presentation should > then present the chunks consecutively until a delimiter is received. > > We have defined the real-time text mode for transmission with RTP, in RFC > 4103, and want of course continue supporting that transport. With RTP it is > realistic to get real real-time transmission, with transmission in 300 ms > intervals. With XMPP, the overead makes it perhaps more realistic to > transmit only once per second, but still get a quite useable real-timish > result, that would be appreciated by the users. > > So, I suggest to bring real-timish text transmission of XMPP into this > charter. > > Gunnar > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Simo.Veikkolainen@nokia.com > Sent: Thursday, September 24, 2009 8:34 AM > To: emcho@sip-communicator.org > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM > and presence > > > >> -----Original Message----- >> From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of ext >> Emil Ivov >> Sent: 23 September, 2009 15:46 >> To: Veikkolainen Simo (Nokia-D/Helsinki) >> Cc: pkyzivat@cisco.com; dispatch@ietf.org >> Subject: Re: [dispatch] Charter proposal on combining SIP voice with >> XMPP IM and presence >> >> Hey Simo, >> >> Simo.Veikkolainen@nokia.com wrote: >>> As has been pointed out in earlier emails, there is no automatic >>> correlation of SIP and XMPP user id's and thus an AOR >>> alice@example.com may not belong to the same person as the JID >>> alice@example.com. This rules out the possibility of responding to a >>> SIP MESSAGE with an XMPP stanza without some a priori >>> knowledge on Alice's identity in XMPP domain. >> I understand why we would not want to rely on an implicit correlation >> like for example JID == AOR. However an explicit correlation such as an >> XMPP contact header in SIP messages and a SIP URI in the XMPP vcards >> would be very helpful. A XMPP+SIP user receiving a call from someone >> not on their contact list is likely to wish to add the remote party to >> their roster or send them instant messages. Not being able to do so >> would feel awkward to the user. > > Yes. Explicit correlation (carrying SIP identities in XMPP or vice versa) is > what we proposed in our draft, and we think could indeed be useful. > >>> From an end user's point of view it makes no difference >> which protocol >>> is used. Personally, I would not mind having all my messaging (IM's >>> via different service providers, SMS, email etc.) visible in >> a single >>> application view, and let the application hide some of the >> complexity. >> >> Not sure I understand. Does this mean that you expect messages to be >> traveling over both SIMPLE and XMPP? If yes, then we definitely need >> some priority rules. > > What I meant was that from a UI point of view, all the end user needs to see > is a contact name and possibility send a message (or call). A lot of the > complexity of selecting the actual protocol *could* be hidden by the > application. This may not be what all application developers wish, but for > example the phonebooks in some mobile devices seem to be going to that > direction, combining IM and SMS in one "conversation" view. > > So, for example, if a user wants the send an initial message to a contact > whose both SIP and XMPP IDs are known, the app could do the selection of > protocol, depending on the other user's presence information. However, when > responding to a message in a conversation, it probably is better to use the > same protocol that was used when sending, unless the client knows that the > other client's UI can render the messages in the same conversation view. > > So, I'll I'm saying is we need to carefully consider making normative > statements that could potentially limit the application design and > usability. > > Simo > >> Cheers, >> Emil >> >> >>> Simo >>> >>>>> So, if you think the above are worth considering how about adding >>>>> something along these lines: >>>>> >>>>> disambiguation: both XMPP and SIP define semantics that >>>> allow each of >>>>> the protocols to offer the complete set of services >>>> discussed in this >>>>> charter (i.e. voice, video, messaging, and presence). In >>>> environments >>>>> where one or more of these services are supported with both >>>> protocols >>>>> clients should be able to use a common procedure for >>>> determining which >>>>> one to use and under what conditions. >>>>> >>>>> half-failures: in cases where use of one of the protocols becomes >>>>> impossible (e.g. due to a server failure) clients should >> be able to >>>>> follow clear procedures on how to behave, which services >> could they >>>>> try to reuse over the protocol that is still available and >>>> under what >>>>> conditions. >>>>> >>>>> WDYT? >>>>> >>>>> Emil >>>>> >>>>> >>>>> Simo.Veikkolainen@nokia.com wrote: >>>>>> Hello, >>>>>> >>>>>> Below is the draft charter text for our proposal on >>>> combining SIP voice with XMPP IM and presence. >>>>>> Comments are very welcome! >>>>>> >>>>>> Regards, Simo >>>>>> >>>>>> >>>>>> ----------------- >>>>>> >>>>>> >>>>>> Combining SIP VoIP and XMPP IM/Presence >>>>>> ======================================= >>>>>> >>>>>> Currently most standards-based Voice over IP (VoIP) >>>> deployments use the Session Initiation Protocol (SIP). In >> addition >>>> to providing basic voice service SIP has an extensive support for >>>> more advanced telephony features including interworking with the >>>> traditional Public Switched Telephone Network (PSTN). SIP is also >>>> gaining popularity in the field of video communication. At >> the same >>>> time, the Extensible Messaging and Presence Protocol (XMPP) is >>>> enjoying widespread usage in instant messaging and presence >> services. >>>>>> Both SIP and XMPP offer extensions for voice as well as IM >>>> and presence (XMPP voice via the Jingle extension, and SIP >>>> IM/presence via SIMPLE protocols). However, widespread >> deployment of >>>> these extensions has not so far taken place. In order to speed up >>>> deployment of integrated VoIP and IM systems, SIP based voice and >>>> XMPP based IM/Presence could be combined in endpoints to offer a >>>> voice, IM and presence service without any changes to existing SIP >>>> and XMPP service infrastrucure. >>>>>> The objective of this Working Group is to develop solutions for >>>>>> combining SIP based voice with XMPP based IM and Presence >>>> such that a >>>>>> unified user experience can be offered to end user. >>>>>> Specifically, solutions are needed on - addressing; end users >>>>>> should be able to initiate sessions >>>> to a user identity in either SIP or XMPP domain. The corresponding >>>> user identity in the other protocol domain needs to be learned >>>> automatically. >>>>>> - session correlation; endpoints need to be able to >> correlate voice >>>>>> sessions with IM/Presence such that they can be presented >>>>>> >>>>>> >>>> to the end >>>>>> user in a seamless fashion - presence; it should be possible to >>>>>> change the XMPP >>>> presence status based on the user's activity in the SIP domain. >>>>>> The goal is to rely on existing service infrastructre, and >>>> new requirements should be imposed only to the endpoint. >>>>>> Protocol interworking, that is, translation from one >>>> protocol to another, is out of scope of this WG. >>>>>> Milestones Feb 2010 Problem statement and use cases submitted to >>>>>> IESG as Informational Dec 2010 Specification on combining >> SIP based >>>> voice and XMPP based IM/Presence in a seamless manner submitted to >>>> IESG as Proposed Standard. >>>>>> ----------------- >>>>>> _______________________________________________ dispatch mailing >>>>>> list dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >> -- >> 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 > > __________ NOD32 4452 (20090924) Information __________ > > Detta meddelande dr genomsvkt av NOD32 Antivirus. > http://www.nod32.com > > > -- 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 stpeter@stpeter.im Thu Sep 24 06:51:14 2009 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 6EEEB3A69E2 for ; Thu, 24 Sep 2009 06:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_43=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 TIu7yyeQNk2R for ; Thu, 24 Sep 2009 06:51:13 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 864A23A677C for ; Thu, 24 Sep 2009 06:51:13 -0700 (PDT) Received: from squire.local (dsl-179-156.dynamic-dsl.frii.net [216.17.179.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7A7994007B; Thu, 24 Sep 2009 07:52:21 -0600 (MDT) Message-ID: <4ABB798C.2040108@stpeter.im> Date: Thu, 24 Sep 2009 07:52:12 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Emil Ivov References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com><4ABA18A0.5070603@sip-communicator.org> <038101ca3cfc$738b13c0$e800a8c0@GunnarH> <4ABB44CD.6000708@sip-communicator.org> In-Reply-To: <4ABB44CD.6000708@sip-communicator.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 13:51:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There are XMPP implementations that transmit character-by-character text, but no one has ever brought a proposal to standardize this feature to the XMPP Standards Foundation, and the XSF hasn't sought one out. That might change in the future with the Wave work. On 9/24/09 4:07 AM, Emil Ivov wrote: > Hey Gunnar, > > I am not sure I understand how this fits the XMPP+SIP work. > Isn't it something that would be better suited by a pure XMPP entity > such as the XMPP WG or xmpp.org? Or do you think that there's some > aspect in this that can only be handled with SIP and another with XMPP? > > IIRC, that's one of the features that appear in Google Wave's demos so > maybe there's already some XMPP related work in that direction. > > Cheers, > Emil > > Gunnar Hellstrom wrote: >> There is another aspect of text communication that I would like to propose >> to bring into this charter. >> >> It is to provide a more "real-timish" text conversational mode, where the >> text is sent time-sampled in short chunks during its composition rather than >> waiting on user command to send a completed message. The presentation should >> then present the chunks consecutively until a delimiter is received. >> >> We have defined the real-time text mode for transmission with RTP, in RFC >> 4103, and want of course continue supporting that transport. With RTP it is >> realistic to get real real-time transmission, with transmission in 300 ms >> intervals. With XMPP, the overead makes it perhaps more realistic to >> transmit only once per second, but still get a quite useable real-timish >> result, that would be appreciated by the users. >> >> So, I suggest to bring real-timish text transmission of XMPP into this >> charter. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq7eYwACgkQNL8k5A2w/vxOHwCguHLZqr2hON470Y0bRHtnRfjj u3gAn2YLKkO3S4gmrukZ0pSuzd5A3oQJ =dngy -----END PGP SIGNATURE----- From AVSHALOM@il.ibm.com Thu Sep 24 07:09:02 2009 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 2ACA03A68FE for ; Thu, 24 Sep 2009 07:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.078 X-Spam-Level: X-Spam-Status: No, score=-4.078 tagged_above=-999 required=5 tests=[AWL=-1.480, 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 sOf+wi+1JZoC for ; Thu, 24 Sep 2009 07:09:01 -0700 (PDT) Received: from mtagate6.de.ibm.com (mtagate6.de.ibm.com [195.212.17.166]) by core3.amsl.com (Postfix) with ESMTP id 9B39A3A6828 for ; Thu, 24 Sep 2009 07:09:00 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.1/8.13.1) with ESMTP id n8OEA7O7011005 for ; Thu, 24 Sep 2009 14:10:07 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8OEA6JO3338400 for ; Thu, 24 Sep 2009 16:10:06 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8OEA6Mf030921 for ; Thu, 24 Sep 2009 16:10:06 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8OEA6ke030918 for ; Thu, 24 Sep 2009 16:10:06 +0200 In-Reply-To: References: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 To: , From: Avshalom Houri Message-ID: Date: Thu, 24 Sep 2009 17:10:05 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 24/09/2009 17:10:06, Serialize complete at 24/09/2009 17:10:06 Content-Type: multipart/alternative; boundary="=_alternative 00451A45C2257638_=" Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 14:09:02 -0000 This is a multipart message in MIME format. --=_alternative 00451A45C2257638_= Content-Type: text/plain; charset="US-ASCII" I support this proposal and will be happy to assist in the work. --Avshalom From: To: Date: 21/09/2009 03:29 PM Subject: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Sent by: dispatch-bounces@ietf.org Hello, Below is the draft charter text for our proposal on combining SIP voice with XMPP IM and presence. Comments are very welcome! Regards, Simo ----------------- Combining SIP VoIP and XMPP IM/Presence ======================================= Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP). In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN). SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services. Both SIP and XMPP offer extensions for voice as well as IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastrucure. The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on - addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically. - session correlation; endpoints need to be able to correlate voice sessions with IM/Presence such that they can be presented to the end user in a seamless fashion - presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain. The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint. Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG. Milestones Feb 2010 Problem statement and use cases submitted to IESG as Informational Dec 2010 Specification on combining SIP based voice and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard. ----------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --=_alternative 00451A45C2257638_= Content-Type: text/html; charset="US-ASCII" I support this proposal and will be happy to assist in the work.

--Avshalom


From: <Simo.Veikkolainen@nokia.com>
To: <dispatch@ietf.org>
Date: 21/09/2009 03:29 PM
Subject: [dispatch] Charter proposal on combining SIP voice with XMPP IM and        presence
Sent by: dispatch-bounces@ietf.org




Hello,

Below is the draft charter text for our proposal on combining SIP voice with XMPP IM and presence.

Comments are very welcome!

Regards,
Simo


-----------------


Combining SIP VoIP and XMPP IM/Presence
=======================================

Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP).  In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN).  SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services.  

Both SIP and XMPP offer extensions for voice as well as IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastrucure.

The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on
- addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically.
- session correlation; endpoints need to be able to correlate voice sessions with IM/Presence such that they can be presented to the end user in a seamless fashion
- presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain.

The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint.

Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG.

Milestones
Feb 2010 Problem statement and use cases submitted to IESG as Informational
Dec 2010 Specification on combining SIP based voice and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard.

-----------------
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--=_alternative 00451A45C2257638_=-- From Sebastian.Schumann@t-com.sk Thu Sep 24 07:25:57 2009 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 10E633A695C for ; Thu, 24 Sep 2009 07:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 wuAX7Z8WQEia for ; Thu, 24 Sep 2009 07:25:55 -0700 (PDT) Received: from mail1.st.sk (mail1.st.sk [195.146.138.74]) by core3.amsl.com (Postfix) with ESMTP id 214833A6834 for ; Thu, 24 Sep 2009 07:25:54 -0700 (PDT) X-TM-IMSS-Message-ID: <056c281a0001cbd4@st.sk> Received: from EXCHANGE2.st.sk ([fe80::49e2:e6ce:946c:aa22]) by EXCHANGEPO2.st.sk ([fe80::9ca8:8d60:d904:6a0c%10]) with mapi; Thu, 24 Sep 2009 16:27:02 +0200 From: Schumann Sebastian To: 'Avshalom Houri' , "'Simo.Veikkolainen@nokia.com'" , "'dispatch@ietf.org'" Date: Thu, 24 Sep 2009 16:27:00 +0200 Thread-Topic: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: Aco9IMKw6PBbfYLZQpWu/gDaTi4h0gAAMw2A Message-ID: References: In-Reply-To: Accept-Language: en-US, sk-SK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sk-SK Content-Type: multipart/alternative; boundary="_000_A693B91C76085E49AA39C91A3E0AC7A0B02E0CFAEXCHANGE2stsk_" MIME-Version: 1.0 Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 14:25:57 -0000 --_000_A693B91C76085E49AA39C91A3E0AC7A0B02E0CFAEXCHANGE2stsk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Everyone >From SIP operator point of view, I see it very important to think about com= bined architecture exactly like Simo describes them: (More or less :) matur= e implementations of SIP and standardized and mature instant messaging/pres= ence where clients exist: XMPP. Both candidates are deployed massively out = there, however still separately. I see big Telco operator's not using XMPP = for voice in the future as well as Google and other large XMPP deployments = considering SIP for their IM services. >From interworking point of view, I think the efforts should not only go int= o the direction where several drafts are available (communicate as SIP/XMPP= user with XMPP/SIP user) but also the into the direction of merging identi= ties (what Simo describes: it should be possible to change the XMPP presenc= e status based on the user's activity in the SIP domain). It is more a prop= osal of users using both networks and "merging" their states. If you use, e= .g., XMPP for presence, you might want to merge the user's SIP device prese= nce state as an actual XMPP presence state (the phone as one resource, the = user being busy when in a call). In other cases, you do not want him to app= ear online in the XMPP client, if only a SIP hardphone is registered. It is= online, but cannot receive any IM communication... I think a lot of use cases and scenarios can be created, even more will ari= se in the future, as both infrastructures are growing. Yet, I see both grow= ing separately and in different "domains" (internet vs. Telco world). I would like to participate in moving the consolidation forward, hence I se= cond the proposal! Best regards Sebastian ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Avshalom Houri Sent: Thursday, 24. September 2009 16:10 To: Simo.Veikkolainen@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP I= M and presence I support this proposal and will be happy to assist in the work. --Avshalom From: To: Date: 21/09/2009 03:29 PM Subject: [dispatch] Charter proposal on combining SIP voice with XMP= P IM and presence Sent by: dispatch-bounces@ietf.org ________________________________ Hello, Below is the draft charter text for our proposal on combining SIP voice wit= h XMPP IM and presence. Comments are very welcome! Regards, Simo ----------------- Combining SIP VoIP and XMPP IM/Presence =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Currently most standards-based Voice over IP (VoIP) deployments use the Ses= sion Initiation Protocol (SIP). In addition to providing basic voice servi= ce SIP has an extensive support for more advanced telephony features includ= ing interworking with the traditional Public Switched Telephone Network (PS= TN). SIP is also gaining popularity in the field of video communication. A= t the same time, the Extensible Messaging and Presence Protocol (XMPP) is e= njoying widespread usage in instant messaging and presence services. Both SIP and XMPP offer extensions for voice as well as IM and presence (XM= PP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols= ). However, widespread deployment of these extensions has not so far taken = place. In order to speed up deployment of integrated VoIP and IM systems, S= IP based voice and XMPP based IM/Presence could be combined in endpoints to= offer a voice, IM and presence service without any changes to existing SIP= and XMPP service infrastrucure. The objective of this Working Group is to develop solutions for combining S= IP based voice with XMPP based IM and Presence such that a unified user exp= erience can be offered to end user. Specifically, solutions are needed on - addressing; end users should be able to initiate sessions to a user ident= ity in either SIP or XMPP domain. The corresponding user identity in the ot= her protocol domain needs to be learned automatically. - session correlation; endpoints need to be able to correlate voice session= s with IM/Presence such that they can be presented to the end user in a sea= mless fashion - presence; it should be possible to change the XMPP presence status based = on the user's activity in the SIP domain. The goal is to rely on existing service infrastructre, and new requirements= should be imposed only to the endpoint. Protocol interworking, that is, translation from one protocol to another, i= s out of scope of this WG. Milestones Feb 2010 Problem statement and use cases submitted to IESG as Informational Dec 2010 Specification on combining SIP based voice and XMPP based IM/Prese= nce in a seamless manner submitted to IESG as Proposed Standard. ----------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_A693B91C76085E49AA39C91A3E0AC7A0B02E0CFAEXCHANGE2stsk_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Everyone
 
From SIP operator point of view, I see it very imp= ortant=20 to think about combined architecture exactly like Simo desc= ribes=20 them: (More or less :) mature implementations of SIP and standardized and=20 mature instant messaging/presence where clients exist: XMPP. Both=20 candidates are deployed massively out there, however still separately. I se= e big=20 Telco operator's not using XMPP for voice in the future as well as Google a= nd=20 other large XMPP deployments considering SIP for their IM=20 services.
 
From interworking= point of=20 view, I think the efforts should not only go into the direction where sever= al=20 drafts are available (communicate as SIP/XMPP user with XMPP/SIP user) but = also=20 the into the direction of merging identities (what Simo describes: it shoul= d be=20 possible to change the XMPP presence status based on the user's activity in= the=20 SIP domain). It is more a proposal of users using both networks= and=20 "merging" their states. If you use, e.g., XMPP for presence, you might want= to=20 merge the user's SIP device presence state as an actual XMPP presence state= (the=20 phone as one resource, the user being busy when in a call). In other cases,= you=20 do not want him to appear online in the XMPP client, if only a SIP hardphon= e is=20 registered. It is online, but cannot receive any IM=20 communication...
 
I think a lot of = use cases=20 and scenarios can be created, even more will arise in the future, as b= oth=20 infrastructures are growing. Yet, I see both growing separately and in diff= erent=20 "domains" (internet vs. Telco world).
 
I would like to p= articipate=20 in moving the consolidation forward, hence I second the=20 proposal!
 
Best=20 regards
Sebastian
From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Avshalom=20 Houri
Sent: Thursday, 24. September 2009 16:10
To:=20 Simo.Veikkolainen@nokia.com; dispatch@ietf.org
Subject: Re:=20 [dispatch] Charter proposal on combining SIP voice with XMPP IM and=20 presence

I support this proposal and w= ill be=20 happy to assist in the work.

--Avshalom



From:=20 <Simo.Veikkolainen@nokia.com>=20
To:=20 <dispatch@ietf.org>= =20
Date:=20 21/09/2009 03:29 PM=20
Subject:= =20 [dispatch] Charter proposal on=20 combining SIP voice with XMPP IM and      =20  presence=20
Sent by:= =20 dispatch-bounces@ietf.org




Hello,

Below is the draft charter t= ext for=20 our proposal on combining SIP voice with XMPP IM and presence.

Com= ments=20 are very=20 welcome!

Regards,
Simo


-----------------


= Combining=20 SIP VoIP and XMPP=20 IM/Presence
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Current= ly most=20 standards-based Voice over IP (VoIP) deployments use the Session Initiati= on=20 Protocol (SIP).  In addition to providing basic voice service SIP ha= s an=20 extensive support for more advanced telephony features including interwor= king=20 with the traditional Public Switched Telephone Network (PSTN).  SIP = is=20 also gaining popularity in the field of video communication. At the same = time,=20 the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespr= ead=20 usage in instant messaging and presence services.  

Both SIP = and=20 XMPP offer extensions for voice as well as IM and presence (XMPP voice vi= a the=20 Jingle extension, and SIP IM/presence via SIMPLE protocols). However,=20 widespread deployment of these extensions has not so far taken place. In = order=20 to speed up deployment of integrated VoIP and IM systems, SIP based voice= and=20 XMPP based IM/Presence could be combined in endpoints to offer a voice, I= M and=20 presence service without any changes to existing SIP and XMPP service=20 infrastrucure.

The objective of this Working Group is to develop= =20 solutions for combining SIP based voice with XMPP based IM and Presence s= uch=20 that a unified user experience can be offered to end user. Specifically,= =20 solutions are needed on
- addressing; end users should be able to ini= tiate=20 sessions to a user identity in either SIP or XMPP domain. The correspondi= ng=20 user identity in the other protocol domain needs to be learned=20 automatically.
- session correlation; endpoints need to be able to=20 correlate voice sessions with IM/Presence such that they can be presented= to=20 the end user in a seamless fashion
- presence; it should be possible t= o=20 change the XMPP presence status based on the user's activity in the SIP=20 domain.

The goal is to rely on existing service infrastructre, and= new=20 requirements should be imposed only to the endpoint.

Protocol=20 interworking, that is, translation from one protocol to another, is out o= f=20 scope of this WG.

Milestones
Feb 2010 Problem statement and use= =20 cases submitted to IESG as Informational
Dec 2010 Specification on=20 combining SIP based voice and XMPP based IM/Presence in a seamless manner= =20 submitted to IESG as Proposed=20 Standard.

-----------------
___________________________________= ____________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_A693B91C76085E49AA39C91A3E0AC7A0B02E0CFAEXCHANGE2stsk_-- From AVSHALOM@il.ibm.com Thu Sep 24 07:50:27 2009 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 0A8A83A682E for ; Thu, 24 Sep 2009 07:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.797, 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 dtCZ64pYIdHE for ; Thu, 24 Sep 2009 07:50:24 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id 106583A6803 for ; Thu, 24 Sep 2009 07:50:23 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n8OEpRgl029996 for ; Thu, 24 Sep 2009 14:51:27 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8OEpR4h3039318 for ; Thu, 24 Sep 2009 16:51:27 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8OEpQLL028466 for ; Thu, 24 Sep 2009 16:51:26 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8OEpQlj028463; Thu, 24 Sep 2009 16:51:26 +0200 In-Reply-To: References: To: Schumann Sebastian MIME-Version: 1.0 X-KeepSent: B8454946:BCA7D94B-C225763B:0050F693; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Thu, 24 Sep 2009 17:51:25 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 24/09/2009 17:51:26, Serialize complete at 24/09/2009 17:51:26 Content-Type: multipart/alternative; boundary="=_alternative 00514BF2C225763B_=" Cc: "'Simo.Veikkolainen@nokia.com'" , "'dispatch@ietf.org'" Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 14:50:27 -0000 This is a multipart message in MIME format. --=_alternative 00514BF2C225763B_= Content-Type: text/plain; charset="US-ASCII" Quite agree with you. Seems that there should be integration also in the back end and not only on the clients. The use cases and the requirements work here will determine the direction of this work. --Avshalom From: Schumann Sebastian To: Avshalom Houri/Haifa/IBM@IBMIL, "'Simo.Veikkolainen@nokia.com'" , "'dispatch@ietf.org'" Date: 24/09/2009 05:27 PM Subject: RE: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Hello Everyone >From SIP operator point of view, I see it very important to think about combined architecture exactly like Simo describes them: (More or less :) mature implementations of SIP and standardized and mature instant messaging/presence where clients exist: XMPP. Both candidates are deployed massively out there, however still separately. I see big Telco operator's not using XMPP for voice in the future as well as Google and other large XMPP deployments considering SIP for their IM services. >From interworking point of view, I think the efforts should not only go into the direction where several drafts are available (communicate as SIP/XMPP user with XMPP/SIP user) but also the into the direction of merging identities (what Simo describes: it should be possible to change the XMPP presence status based on the user's activity in the SIP domain). It is more a proposal of users using both networks and "merging" their states. If you use, e.g., XMPP for presence, you might want to merge the user's SIP device presence state as an actual XMPP presence state (the phone as one resource, the user being busy when in a call). In other cases, you do not want him to appear online in the XMPP client, if only a SIP hardphone is registered. It is online, but cannot receive any IM communication... I think a lot of use cases and scenarios can be created, even more will arise in the future, as both infrastructures are growing. Yet, I see both growing separately and in different "domains" (internet vs. Telco world). I would like to participate in moving the consolidation forward, hence I second the proposal! Best regards Sebastian From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Avshalom Houri Sent: Thursday, 24. September 2009 16:10 To: Simo.Veikkolainen@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence I support this proposal and will be happy to assist in the work. --Avshalom From: To: Date: 21/09/2009 03:29 PM Subject: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Sent by: dispatch-bounces@ietf.org Hello, Below is the draft charter text for our proposal on combining SIP voice with XMPP IM and presence. Comments are very welcome! Regards, Simo ----------------- Combining SIP VoIP and XMPP IM/Presence ======================================= Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP). In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN). SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services. Both SIP and XMPP offer extensions for voice as well as IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastrucure. The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on - addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically. - session correlation; endpoints need to be able to correlate voice sessions with IM/Presence such that they can be presented to the end user in a seamless fashion - presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain. The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint. Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG. Milestones Feb 2010 Problem statement and use cases submitted to IESG as Informational Dec 2010 Specification on combining SIP based voice and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard. ----------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --=_alternative 00514BF2C225763B_= Content-Type: text/html; charset="US-ASCII" Quite agree with you. Seems that there should be integration also in the back end and not only on the clients.
The use cases and the requirements work here will determine the direction of this work.

--Avshalom


From: Schumann Sebastian <Sebastian.Schumann@t-com.sk>
To: Avshalom Houri/Haifa/IBM@IBMIL, "'Simo.Veikkolainen@nokia.com'" <Simo.Veikkolainen@nokia.com>, "'dispatch@ietf.org'" <dispatch@ietf.org>
Date: 24/09/2009 05:27 PM
Subject: RE: [dispatch] Charter proposal on combining SIP voice with XMPP IM        and        presence




Hello Everyone
 
From SIP operator point of view, I see it very important to think about combined architecture exactly like Simo describes them: (More or less :) mature implementations of SIP and standardized and mature instant messaging/presence where clients exist: XMPP. Both candidates are deployed massively out there, however still separately. I see big Telco operator's not using XMPP for voice in the future as well as Google and other large XMPP deployments considering SIP for their IM services.
 
From interworking point of view, I think the efforts should not only go into the direction where several drafts are available (communicate as SIP/XMPP user with XMPP/SIP user) but also the into the direction of merging identities (what Simo describes: it should be possible to change the XMPP presence status based on the user's activity in the SIP domain). It is more a proposal of users using both networks and "merging" their states. If you use, e.g., XMPP for presence, you might want to merge the user's SIP device presence state as an actual XMPP presence state (the phone as one resource, the user being busy when in a call). In other cases, you do not want him to appear online in the XMPP client, if only a SIP hardphone is registered. It is online, but cannot receive any IM communication...
 
I think a lot of use cases and scenarios can be created, even more will arise in the future, as both infrastructures are growing. Yet, I see both growing separately and in different "domains" (internet vs. Telco world).
 
I would like to participate in moving the consolidation forward, hence I second the proposal!
 
Best regards
Sebastian

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Avshalom Houri
Sent: Thursday, 24. September 2009 16:10
To: Simo.Veikkolainen@nokia.com; dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence
I support this proposal and will be happy to assist in the work.

--Avshalom
From: <Simo.Veikkolainen@nokia.com>
To: <dispatch@ietf.org>
Date: 21/09/2009 03:29 PM
Subject: [dispatch] Charter proposal on combining SIP voice with XMPP IM and        presence
Sent by: dispatch-bounces@ietf.org



Hello,

Below is the draft charter text for our proposal on combining SIP voice with XMPP IM and presence.

Comments are very welcome!

Regards,
Simo


-----------------


Combining SIP VoIP and XMPP IM/Presence
=======================================

Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP).  In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN).  SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services.  

Both SIP and XMPP offer extensions for voice as well as IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastrucure.

The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on
- addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically.
- session correlation; endpoints need to be able to correlate voice sessions with IM/Presence such that they can be presented to the end user in a seamless fashion
- presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain.

The goal is to rely on existing service infrastructre, and new requirements should be imposed only to the endpoint.

Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG.

Milestones
Feb 2010 Problem statement and use cases submitted to IESG as Informational
Dec 2010 Specification on combining SIP based voice and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard.

-----------------
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--=_alternative 00514BF2C225763B_=-- From RIFATYU@nortel.com Thu Sep 24 08:55:46 2009 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 E202128C122 for ; Thu, 24 Sep 2009 08:55:46 -0700 (PDT) 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 xDGjJTDRjKqe for ; Thu, 24 Sep 2009 08:55:44 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 108EA28C116 for ; Thu, 24 Sep 2009 08:55:43 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8OFumS24740; Thu, 24 Sep 2009 15:56:49 GMT 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_01CA3D2F.9FEB0EF0" Date: Thu, 24 Sep 2009 11:56:46 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgO+rxqAACPN20AAEur0kA== References: From: "Rifaat Shekh-Yusef" To: , , , "Mary Barnes" , Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/XMPP 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, 24 Sep 2009 15:55:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3D2F.9FEB0EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Simo, =20 If I add a B2BUA to the example that you have in section 7.2: =20 Bob B2BUA Alice | | | | (F1) INVITE | (F2) INVITE | |-------------------------------------------------- >|---------------------------------------------------> | | XMPP-Contact: Bob; call-id1 | XMPP-Contact: Bob; call-id1 | | | | | | | | (F4) 200 OK | (F3) 200 OK | |<-------------------------------------------------- |<-------------------------------------------------- | | XMPP-Contact: Alice; call-id2 | XMPP-Contact: Alice; call-id2 | | | | =20 =20 Let (F1) INVITE have the correlation-id as the Call-ID of the dialog between Bob and the B2BUA (call-id1),=20 and (F3) 200 OK have the correlation-id as the Call-ID of the dialog between the B2BUA and Alice (call-id2). =20 Would it not be enough for Bob to send call-id2 to Alice as the ? and for Alice to send call-id1 to Bob as the ? =20 Regards, Rifaat ________________________________ From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: Thursday, September 24, 2009 2:54 AM To: Shekh-Yusef, Rifaat (BVW:9T16); Simo.Veikkolainen@nokia.com; dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsson.com Subject: RE: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Hi Rifaat, =20 In our proposal the correlation works so that: 1. UAs engaged in a SIP session/dialog exchange an identifier related to that session (as well as their XMPP full JIDs) 2. They insert them in the very first XMPP messages they subsequently exchange, in order to correlate that exchange to be related to the SIP session. =20 The correlation identifier has to be end-to-end, otherwise the other end won't be able to use it for correlation. Call-ID is often changed enroute. So, if one endpoint puts it in an XMPP messages as a reference to a SIP session, the other endpoint won't recognize it as it has a different Call-ID for the same session. =20 Markus ________________________________ From: ext Rifaat Shekh-Yusef [mailto:rifatyu@nortel.com]=20 Sent: 23 September, 2009 22:57 To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; Mary Barnes; gonzalo.camarillo@ericsson.com Cc: Isomaki Markus (Nokia-CIC/Espoo) Subject: RE: [dispatch] New topic proposal for DISPATCH =09 =09 Simo, Markus, =20 I am very interested in this work and I like your approach. =20 I have a question regarding the open issue you have in section 5.2: Why do you require the correlation-value to be an end-to-end identifier? In the case where there is an SBC that creates a new dialog for the target, would it not be enough for each endpoint to use the Call-ID of the other dialog as the correlation-value? =20 Thanks, Rifaat =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com Sent: Friday, September 04, 2009 8:09 AM To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsson.com Cc: Markus.Isomaki@nokia.com Subject: [dispatch] New topic proposal for DISPATCH =09 =09 =09 Hi, =20 We would like to propose a new DISPATCH topic on how SIP and XMPP can be used together in a complementary fashion. =20 We have been working on a solution which combines SIP based VoIP and XMPP based IM and Presence. The requirements and a proposed solution is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 . =20 The motivation for this work comes from experience which shows that most standards based VoIP deployments use SIP. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is widely used in instant messaging and presence services. An interesting scenario arises when a SIP based voice (and video) service is combined together with an XMPP based instant messaging and presence service.=20 =20 Note that the goal in this work is not SIP-XMPP protocol translation, but to define protocol extensions and best practises such that SIP based VoIP and XMPP based IM and presence could be seamlessly combined and offered to the end user. For rapid deployment, we assume no changes in the server infrastructure, and instead impose new requirements and protocol extensions only to the endpoints. =20 We would like to get some discussion going on the use case itself as well as on the solution. Also, we would like to hear you thoughts on DISPATCH or a new "dispatched" mini-WG as the home for such work. =20 Exact charter proposal and problem statemen is to follow.=20 =20 Regards, Simo and Markus =20 =20 ------_=_NextPart_001_01CA3D2F.9FEB0EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Simo,

 

If = I add a B2BUA to the example that = you have in=20 section 7.2:

 

Bob           &nbs= p;            = ;            =             B2BUA           &nbs= p;            = ;            &nbs= p;     Alice

|           &nbs= p;            = ;            =            =        |           &nbs= p;            = ;            =                  |<= /P>

| (F1) = INVITE           &nbs= p;            = ;            | (F2) INVITE           &nbs= p;            = ;            |

|--------------------------------------------------=20 >|--------------------------------------------------->=20 |

| = XMPP-Contact: Bob;=20 call-id1           | XMPP-Contact: Bob; = call-id1          =20 |

|           &nbs= p;            = ;            =                 =20 |           &nbs= p;            = ;            =            =       =20 |

|           &nbs= p;            = ;            =             &= nbsp;   =20 |           &nbs= p;            = ;            =             &= nbsp;    =20 |

| (F4) 200 = OK           &nbs= p;            = ;          |=20 (F3) 200 OK           &nbs= p;            = ;          =20 |

|<--------------------------------------------------=20 |<-------------------------------------------------- |

| = XMPP-Contact:=20 Alice; call-id2         | = XMPP-Contact:=20 Alice;=20 call-id2          |

|           &nbs= p;            = ;            =             &= nbsp;   =20 |           &nbs= p;            = ;            =             &= nbsp;   =20 |

 

 

Let (F1) = INVITE have=20 the correlation-id as the = Call-ID of the=20 dialog between Bob and the B2BUA (call-id1),

and (F3) 200 = OK have=20 the correlation-id as the = Call-ID of the=20 dialog between the B2BUA and Alice (call-id2).

 

Would it not = be enough=20 for Bob to send call-id2 to Alice as the <sip-correlation>? and for Alice to send call-id1 to Bob as = the <sip-correlation>?

 

Regards,

 Rifaat


From: Markus.Isomaki@nokia.com=20 [mailto:Markus.Isomaki@nokia.com]
Sent: Thursday, September = 24, 2009=20 2:54 AM
To: Shekh-Yusef, Rifaat (BVW:9T16);=20 Simo.Veikkolainen@nokia.com; dispatch@ietf.org; Barnes, Mary = (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Subject: RE: [dispatch] New = topic=20 proposal for DISPATCH - SIP/XMPP

Hi Rifaat,
 
In our proposal the correlation works so=20 that:
1. UAs engaged in a SIP session/dialog = exchange an=20 identifier related to that session (as well as their XMPP full=20 JIDs)
2. They insert them in the very first XMPP = messages=20 they subsequently exchange, in order to correlate that exchange to be = related to=20 the SIP session.
 
The correlation identifier has to be = end-to-end,=20 otherwise the other end won't be able to use it for correlation. Call-ID = is=20 often changed enroute. So, if one endpoint puts it in an XMPP messages = as a=20 reference to a SIP session, the other endpoint won't recognize it as it = has a=20 different Call-ID for the same session.
 
Markus

From: ext Rifaat Shekh-Yusef=20 [mailto:rifatyu@nortel.com]
Sent: 23 September, 2009=20 22:57
To: Veikkolainen Simo (Nokia-D/Helsinki); = dispatch@ietf.org;=20 Mary Barnes; gonzalo.camarillo@ericsson.com
Cc: Isomaki = Markus=20 (Nokia-CIC/Espoo)
Subject: RE: [dispatch] New topic proposal = for=20 DISPATCH

Simo, Markus,
 
I am=20 very interested in this work and I like your = approach.
 
I=20 have a question regarding the open issue you have in section=20 5.2:
Why=20 do you require the correlation-value to be an end-to-end=20 identifier?
In=20 the case where there is an SBC that creates a new dialog for the = target,=20 would it not be enough for each endpoint to use the = Call-ID of the=20 other dialog as the correlation-value?
 
Thanks,
 Rifaat
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 Simo.Veikkolainen@nokia.com
Sent: Friday, September 04, = 2009=20 8:09 AM
To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Cc:=20 Markus.Isomaki@nokia.com
Subject: [dispatch] New topic = proposal for=20 DISPATCH

Hi,
 
We would like to propose a new DISPATCH topic on how SIP and XMPP = can be=20 used together in a complementary fashion.
 
We have been working on a solution which combines SIP based VoIP = and XMPP=20 based IM and Presence. The requirements and a proposed solution is = outlined in=20 http://tools.ietf.org/html/draft-veikkolainen-sip-voip= -xmpp-im-01.
 
The motivation for this work comes from experience which shows = that most=20 standards based VoIP deployments use SIP. At the same time, the = Extensible=20 Messaging and Presence Protocol (XMPP) is widely used in instant = messaging and=20 presence services. An interesting scenario arises when a SIP based = voice (and=20 video) service is combined together with an XMPP based instant = messaging and=20 presence service.
 
Note that the goal in this work is not SIP-XMPP protocol = translation, but=20 to define protocol extensions and best practises such that SIP based = VoIP and=20 XMPP based IM and presence could be seamlessly combined and offered to = the end=20 user. For rapid deployment, we assume no changes in the server = infrastructure,=20 and instead impose new requirements and protocol extensions only to = the=20 endpoints.
 
We would like to get some discussion going on the use case itself = as well=20 as on the solution. Also, we would like to hear you thoughts on = DISPATCH or a=20 new "dispatched" mini-WG as the home for such work.
 
Exact charter proposal and problem statemen is to follow.
 
Regards,
Simo and Markus
 
 
------_=_NextPart_001_01CA3D2F.9FEB0EF0-- From gunnar.hellstrom@omnitor.se Thu Sep 24 11:07:00 2009 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 D23C828C131 for ; Thu, 24 Sep 2009 11:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=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 ZRSn9mzMPIPa for ; Thu, 24 Sep 2009 11:06:59 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id C39A73A691B for ; Thu, 24 Sep 2009 11:06:58 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 728DA28D8CB for ; Thu, 24 Sep 2009 20:07:18 +0200 (CEST) Received: (qmail 4567 invoked from network); 24 Sep 2009 18:07:10 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with SMTP for ; 24 Sep 2009 18:07:10 -0000 From: "Gunnar Hellstrom" To: "'Emil Ivov'" References: <4AB8BC67.3080702@sip-communicator.org> <4AB8CFEC.8020703@cisco.com><4ABA18A0.5070603@sip-communicator.org> <038101ca3cfc$738b13c0$e800a8c0@GunnarH> <4ABB44CD.6000708@sip-communicator.org> Date: Thu, 24 Sep 2009 20:07:19 +0200 Message-ID: <003901ca3d41$dbc59c90$211ea8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aco8/sp8rM/y0yVUS+a/MdEDf/SrTwAG4oTA In-Reply-To: <4ABB44CD.6000708@sip-communicator.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: Simo.Veikkolainen@nokia.com, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 24 Sep 2009 18:07:00 -0000 Emil, The link with other real-time media in the SIP part of the call makes it valid to also discuss the real-time characteristics of the text part. It may look strange to arrange real-time communication in video and = audio, but leave the text part in message-wise performance level. Especially = now, when real-time text is appearing as a performance enhancement in various services as you have noticed yourself. However, you are right in principle, real-time is a general presentation function that could be defined in XMPP.=20 So, it could be of interest to define this presentation feature in XMPP, = and resolve any interoperability and media offer/answer issues with RFC 4103 = in the new group. For example, how would you express in SDP that you offer RFC 4013 in RTP = and real-timish mode of XMPP as equal alternatives to select from, in = contrast to offering RFC 4103 as the main real-time text medium in the session, = and message-based XMPP for side-bar discussion. Such aspects would need to = be defined under the new charter. Gunnar ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of Emil = Ivov Sent: Thursday, September 24, 2009 12:07 PM To: Gunnar Hellstrom Cc: Simo.Veikkolainen@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal on combining SIP voice with = XMPP IM and presence Hey Gunnar, I am not sure I understand how this fits the XMPP+SIP work. Isn't it something that would be better suited by a pure XMPP entity = such as the XMPP WG or xmpp.org? Or do you think that there's some aspect in = this that can only be handled with SIP and another with XMPP? IIRC, that's one of the features that appear in Google Wave's demos so = maybe there's already some XMPP related work in that direction. Cheers, Emil Gunnar Hellstrom wrote: > There is another aspect of text communication that I would like to=20 > propose to bring into this charter. >=20 > It is to provide a more "real-timish" text conversational mode, where=20 > the text is sent time-sampled in short chunks during its composition=20 > rather than waiting on user command to send a completed message. The=20 > presentation should then present the chunks consecutively until a delimiter is received. >=20 > We have defined the real-time text mode for transmission with RTP, in=20 > RFC 4103, and want of course continue supporting that transport. With=20 > RTP it is realistic to get real real-time transmission, with=20 > transmission in 300 ms intervals. With XMPP, the overead makes it=20 > perhaps more realistic to transmit only once per second, but still get = > a quite useable real-timish result, that would be appreciated by the users. >=20 > So, I suggest to bring real-timish text transmission of XMPP into this = > charter. >=20 > Gunnar >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Simo.Veikkolainen@nokia.com > Sent: Thursday, September 24, 2009 8:34 AM > To: emcho@sip-communicator.org > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal on combining SIP voice with=20 > XMPP IM and presence >=20 > =20 >=20 >> -----Original Message----- >> From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of ext=20 >> Emil Ivov >> Sent: 23 September, 2009 15:46 >> To: Veikkolainen Simo (Nokia-D/Helsinki) >> Cc: pkyzivat@cisco.com; dispatch@ietf.org >> Subject: Re: [dispatch] Charter proposal on combining SIP voice with=20 >> XMPP IM and presence >> >> Hey Simo, >> >> Simo.Veikkolainen@nokia.com wrote: >>> As has been pointed out in earlier emails, there is no automatic=20 >>> correlation of SIP and XMPP user id's and thus an AOR=20 >>> alice@example.com may not belong to the same person as the JID=20 >>> alice@example.com. This rules out the possibility of responding to a = >>> SIP MESSAGE with an XMPP stanza without some a priori=20 >>> knowledge on Alice's identity in XMPP domain. >> I understand why we would not want to rely on an implicit correlation = >> like for example JID =3D=3D AOR. However an explicit correlation such = as=20 >> an XMPP contact header in SIP messages and a SIP URI in the XMPP=20 >> vcards would be very helpful. A XMPP+SIP user receiving a call from=20 >> someone not on their contact list is likely to wish to add the remote = >> party to their roster or send them instant messages. Not being able=20 >> to do so would feel awkward to the user. >=20 > Yes. Explicit correlation (carrying SIP identities in XMPP or vice=20 > versa) is what we proposed in our draft, and we think could indeed be useful. >=20 >>> From an end user's point of view it makes no difference >> which protocol >>> is used. Personally, I would not mind having all my messaging (IM's=20 >>> via different service providers, SMS, email etc.) visible in >> a single >>> application view, and let the application hide some of the >> complexity. >> >> Not sure I understand. Does this mean that you expect messages to be=20 >> traveling over both SIMPLE and XMPP? If yes, then we definitely need=20 >> some priority rules. >=20 > What I meant was that from a UI point of view, all the end user needs=20 > to see is a contact name and possibility send a message (or call). A=20 > lot of the complexity of selecting the actual protocol *could* be=20 > hidden by the application. This may not be what all application=20 > developers wish, but for example the phonebooks in some mobile devices = > seem to be going to that direction, combining IM and SMS in one "conversation" view. >=20 > So, for example, if a user wants the send an initial message to a=20 > contact whose both SIP and XMPP IDs are known, the app could do the=20 > selection of protocol, depending on the other user's presence=20 > information. However, when responding to a message in a conversation,=20 > it probably is better to use the same protocol that was used when=20 > sending, unless the client knows that the other client's UI can render = the messages in the same conversation view. >=20 > So, I'll I'm saying is we need to carefully consider making normative=20 > statements that could potentially limit the application design and=20 > usability. >=20 > Simo >=20 >> Cheers, >> Emil >> >> >>> Simo >>> >>>>> So, if you think the above are worth considering how about adding=20 >>>>> something along these lines: >>>>> >>>>> disambiguation: both XMPP and SIP define semantics that >>>> allow each of >>>>> the protocols to offer the complete set of services >>>> discussed in this >>>>> charter (i.e. voice, video, messaging, and presence). In >>>> environments >>>>> where one or more of these services are supported with both >>>> protocols >>>>> clients should be able to use a common procedure for >>>> determining which >>>>> one to use and under what conditions. >>>>> >>>>> half-failures: in cases where use of one of the protocols becomes=20 >>>>> impossible (e.g. due to a server failure) clients should >> be able to >>>>> follow clear procedures on how to behave, which services >> could they >>>>> try to reuse over the protocol that is still available and >>>> under what >>>>> conditions. >>>>> >>>>> WDYT? >>>>> >>>>> Emil >>>>> >>>>> >>>>> Simo.Veikkolainen@nokia.com wrote: >>>>>> Hello, >>>>>> >>>>>> Below is the draft charter text for our proposal on >>>> combining SIP voice with XMPP IM and presence. >>>>>> Comments are very welcome! >>>>>> >>>>>> Regards, Simo >>>>>> >>>>>> >>>>>> ----------------- >>>>>> >>>>>> >>>>>> Combining SIP VoIP and XMPP IM/Presence=20 >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>> Currently most standards-based Voice over IP (VoIP) >>>> deployments use the Session Initiation Protocol (SIP). In >> addition >>>> to providing basic voice service SIP has an extensive support for=20 >>>> more advanced telephony features including interworking with the=20 >>>> traditional Public Switched Telephone Network (PSTN). SIP is also=20 >>>> gaining popularity in the field of video communication. At >> the same >>>> time, the Extensible Messaging and Presence Protocol (XMPP) is=20 >>>> enjoying widespread usage in instant messaging and presence >> services. >>>>>> Both SIP and XMPP offer extensions for voice as well as IM >>>> and presence (XMPP voice via the Jingle extension, and SIP=20 >>>> IM/presence via SIMPLE protocols). However, widespread >> deployment of >>>> these extensions has not so far taken place. In order to speed up=20 >>>> deployment of integrated VoIP and IM systems, SIP based voice and=20 >>>> XMPP based IM/Presence could be combined in endpoints to offer a=20 >>>> voice, IM and presence service without any changes to existing SIP=20 >>>> and XMPP service infrastrucure. >>>>>> The objective of this Working Group is to develop solutions for=20 >>>>>> combining SIP based voice with XMPP based IM and Presence >>>> such that a >>>>>> unified user experience can be offered to end user.=20 >>>>>> Specifically, solutions are needed on - addressing; end users=20 >>>>>> should be able to initiate sessions >>>> to a user identity in either SIP or XMPP domain. The corresponding=20 >>>> user identity in the other protocol domain needs to be learned=20 >>>> automatically. >>>>>> - session correlation; endpoints need to be able to >> correlate voice >>>>>> sessions with IM/Presence such that they can be presented >>>>>> >>>>>> >>>> to the end >>>>>> user in a seamless fashion - presence; it should be possible to=20 >>>>>> change the XMPP >>>> presence status based on the user's activity in the SIP domain. >>>>>> The goal is to rely on existing service infrastructre, and >>>> new requirements should be imposed only to the endpoint. >>>>>> Protocol interworking, that is, translation from one >>>> protocol to another, is out of scope of this WG. >>>>>> Milestones Feb 2010 Problem statement and use cases submitted to=20 >>>>>> IESG as Informational Dec 2010 Specification on combining >> SIP based >>>> voice and XMPP based IM/Presence in a seamless manner submitted to=20 >>>> IESG as Proposed Standard. >>>>>> ----------------- >>>>>> _______________________________________________ dispatch mailing=20 >>>>>> list dispatch@ietf.org=20 >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >> --=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 >=20 > __________ NOD32 4452 (20090924) Information __________ >=20 > Detta meddelande dr genomsvkt av NOD32 Antivirus. > http://www.nod32.com >=20 >=20 >=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 __________ NOD32 4452 (20090924) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com From AUDET@nortel.com Thu Sep 24 14:25:51 2009 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 121833A693A for ; Thu, 24 Sep 2009 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 a+T1D7xPfi9R for ; Thu, 24 Sep 2009 14:25:50 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E60A23A67DB for ; Thu, 24 Sep 2009 14:25:49 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8OLQpS04220; Thu, 24 Sep 2009 21:26:52 GMT 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, 24 Sep 2009 16:26:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF203EF56F@zrc2hxm0.corp.nortel.com> In-Reply-To: <4ABA2BFA.40209@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter Proposal for Disaggregated Media Thread-Index: Aco8XXvRdNs0UbfGRQCKohgDjYZG/QA/u/6Q References: <4AB75AC7.6080509@ericsson.com> <4AB79C7C.5010803@cisco.com> <4ABA2BFA.40209@ericsson.com> From: "Francois Audet" To: "Salvatore Loreto" Cc: IETF Dispatch , Gonzalo Camarillo Subject: Re: [dispatch] Charter Proposal for Disaggregated Media 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, 24 Sep 2009 21:25:51 -0000 I support this work, and as we have seen in the past, with multiple = proposals, the need is real. The charter generaly looks OK to me.=20 I am personally much more interested in the "loosely coupled" aspect to = this, as opposed to the MBUS/MEGACO/3PCC aspects, but I don't object to the=20 group covering both. -Francois > -----Original Message----- From: Salvatore Loreto To: IETF Dispatch Cc: Gonzalo Camarillo Date: Mon, 21 Sep 2009 13:51:51 +0300 Hi there, below is a charter proposal for a WG on Disaggregated Media. All comments, thoughts, feedbacks are very welcome! cheers Sal Disaggregated Media WG Charter -------------------------------=20 Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the media session. The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate the different devices under his control to involve them in the call. The different devices can communicate with one another using Mbus = messages, and then let only one device, a call control engine, to = initiate, manage and terminate call control relations to other SIP = endpoints. All the different user's devices need to support the Mbus = protocol. The Megaco [RFC3525] protocol can be used in a disaggregated media = scenario to let one of the user's devices act as a Media Gateway = Controller, coordinating all the other devices under the user's control, which in = this case will act as Media Gateways. In this case all the different user's = devices need to support the Megaco protocol. The SIP protocol provides 3pcc [RFC3725] as a possible mechanism to coordinate the exchange of media streams coming from different = devices under the control of the same user, in the case at least one = among the different devices under his control supports this mechanism = and is able to become a Controller for the other in the call. All the existing mechanisms only cover a subset of the interesting = scenarios that involve disaggregated media. Scenarios not covered by = existing mechanisms include the loosely-coupled one where none of the = nodes can act as a controller because it does not support the necessary functionality or because it = will not participate in the whole session. The objective of the proposed working group is to develop a framework for Disaggregated Media that include both improvements on existing = mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms = like a loosely coupled mechanism that does not require the = implementation of complex logic on any of the terminals. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key design = considerations for Disaggregated mediamechanism. 2. A specification for a loosely couple mechanism. 3. One or more specifications to improve existing mechanism to = coordinate disaggregated media. From ggb@tid.es Fri Sep 25 03:11:56 2009 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 A8FF33A6948 for ; Fri, 25 Sep 2009 03:11:56 -0700 (PDT) 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 jctmlDt-CiB8 for ; Fri, 25 Sep 2009 03:11:55 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by core3.amsl.com (Postfix) with ESMTP id 9C2EA3A686A for ; Fri, 25 Sep 2009 03:11:55 -0700 (PDT) Received: from vanvan (localhost [127.0.0.1]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQI007KOV1SLL@tid.hi.inet> for dispatch@ietf.org; Fri, 25 Sep 2009 12:13:05 +0200 (MEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0KQI007KFV1SLL@tid.hi.inet> for dispatch@ietf.org; Fri, 25 Sep 2009 12:13:04 +0200 (MEST) Received: from matrix.hi.inet (10.95.67.43) by htcasmad2.hi.inet (10.95.67.75) with Microsoft SMTP Server id 8.1.375.2; Fri, 25 Sep 2009 12:13:04 +0200 Date: Fri, 25 Sep 2009 12:13:03 +0200 From: ggb In-reply-to: <9066e39a-c329-445e-921c-a4941831e302@htcasmad1.hi.inet> To: Christer Holmberg Message-id: <4ABC97AF.1060802@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Lightning/1.0pre Thunderbird/3.0b3 References: <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> <4AAA5C98.1080502@sipstation.com> <9066e39a-c329-445e-921c-a4941831e302@htcasmad1.hi.inet> Cc: "dispatch@ietf.org" , Gonzalo Camarillo Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : CBUS 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: Fri, 25 Sep 2009 10:11:56 -0000 Hi, I've been reading the requirements draft, and I agree that it would be needed some work in the IETF in order to be able to provide this functionality making use of SIP events support. Somehow this feature is closer to searching than to filtering, and I tend to agree that RFC4660 does not fit well in this space (although the concept of triggers in RFC4660 could be reused). Defining other XML schema for expressing the query/conditions could be the simplest solution. BR, Gustavo García Telefónica I+D On 09/14/2009 10:58 AM, Christer Holmberg wrote: > Hi, > > Some time ago I submitted a requirement draft for the OMA work on CBUS. > > In short, the idea of CBUS is that a client provides a set of conditions (which can be related to presence, location etc etc) to a CBUS server. Based on the conditions, the CBUS server communicates with presence servers, locations servers etc in order to figure out which users fulfill the conditions. The CBUS server then provides the client with a list of the URIs which fulfilled the conditions. The CBUS can do that on a one-time bases, a time-based basis, or whenever the information changes (called evaluation parameters). In addition, the client can provide a set or URIs, or a reference to URIs, which the CBUS chooses from (called candidate URIs). > > The idea is to provide the URIs in a subscription event package, and the associated SUBSCRIBE would contain the conditions (most likely using an XML document). > > Dean raised a question whether it would be enough to define the new event package, and re-use RFC4660/1 to provide the conditions. > > Due to summer vacations etc it took a while to look into this, but me and some OMA people have now looked into this. > > Our initial conclusion is that it is NOT very feasible to re-use RFC 4660/1. > > RFC4660/1 provides a filtering mechanism, where the client specifies what type of information he wants to receive. However, in CBUS the type of information is always the same: the URI list. Instead, the CLIENT provides the type of information (conditions) on which the URIs shall be selected (and, in addition to that, the evaluation parameter(s) and candidate URI(s)). > > We did look at whether it would be possible to somehow re-use 4660/1, but we thought it would be rather hacky. Some of the 4660/1 XML elements would probably be unused, and there would be a need to define new extensions - so we thought it would be nicer to define a new XML schema instead. > > So, I would like to request DISPATCH time to discuss this. We plan to provide an updated version of the draft, with clarifications and more details etc. > > Regards, > > Christer > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From christer.holmberg@ericsson.com Fri Sep 25 03:16:38 2009 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 552993A6948 for ; Fri, 25 Sep 2009 03:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, HELO_EQ_SE=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 8FEyoLK0nkoA for ; Fri, 25 Sep 2009 03:16:37 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EB3383A68A5 for ; Fri, 25 Sep 2009 03:16:36 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-7a-4abc98ca09ac Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 99.80.22406.AC89CBA4; Fri, 25 Sep 2009 12:17:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 12:17:26 +0200 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, 25 Sep 2009 12:17:26 +0200 Message-ID: In-Reply-To: <4ABC97AF.1060802@tid.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-76 DISPATCH WG deadlines : CBUS Thread-Index: Aco9yMfMpEcXr4jpQeesJuR975rHYgAAEATw References: <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> <4AAA5C98.1080502@sipstation.com> <9066e39a-c329-445e-921c-a4941831e302@htcasmad1.hi.inet> <4ABC97AF.1060802@tid.es> From: "Christer Holmberg" To: "ggb" X-OriginalArrivalTime: 25 Sep 2009 10:17:27.0230 (UTC) FILETIME=[61D12DE0:01CA3DC9] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Gonzalo Camarillo Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : CBUS 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: Fri, 25 Sep 2009 10:16:38 -0000 Hi Gustavo, Thanks you for your feeback! We did look into using RFC4660, and we came to the same conclusion as = you. Yes, perhaps it would be possible to use SOME part of 4660, but = many things would not be needed, and there would be a need to define new = things anyway. We thought that could become rather hacky and messy. Regards, Christer =20 > -----Original Message----- > From: ggb [mailto:ggb@tid.es]=20 > Sent: 25. syyskuuta 2009 13:13 > To: Christer Holmberg > Cc: dispatch@ietf.org; Gonzalo Camarillo > Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : CBUS >=20 > Hi, >=20 > I've been reading the requirements draft, and I agree that it=20 > would be needed some work in the IETF in order to be able to=20 > provide this functionality making use of SIP events support. >=20 > Somehow this feature is closer to searching than to=20 > filtering, and I tend to agree that RFC4660 does not fit well=20 > in this space (although the concept of triggers in RFC4660=20 > could be reused). Defining other XML schema for expressing=20 > the query/conditions could be the simplest solution. >=20 > BR, >=20 > Gustavo Garc=EDa > Telef=F3nica I+D >=20 > On 09/14/2009 10:58 AM, Christer Holmberg wrote: > > Hi, > > > > Some time ago I submitted a requirement draft for the OMA=20 > work on CBUS. > > > > In short, the idea of CBUS is that a client provides a set=20 > of conditions (which can be related to presence, location etc=20 > etc) to a CBUS server. Based on the conditions, the CBUS=20 > server communicates with presence servers, locations servers=20 > etc in order to figure out which users fulfill the=20 > conditions. The CBUS server then provides the client with a=20 > list of the URIs which fulfilled the conditions. The CBUS can=20 > do that on a one-time bases, a time-based basis, or whenever=20 > the information changes (called evaluation parameters). In=20 > addition, the client can provide a set or URIs, or a=20 > reference to URIs, which the CBUS chooses from (called=20 > candidate URIs). > > > > The idea is to provide the URIs in a subscription event=20 > package, and the associated SUBSCRIBE would contain the=20 > conditions (most likely using an XML document). > > > > Dean raised a question whether it would be enough to define=20 > the new event package, and re-use RFC4660/1 to provide the conditions. > > > > Due to summer vacations etc it took a while to look into=20 > this, but me and some OMA people have now looked into this. > > > > Our initial conclusion is that it is NOT very feasible to=20 > re-use RFC 4660/1. > > > > RFC4660/1 provides a filtering mechanism, where the client=20 > specifies what type of information he wants to receive.=20 > However, in CBUS the type of information is always the same:=20 > the URI list. Instead, the CLIENT provides the type of=20 > information (conditions) on which the URIs shall be selected=20 > (and, in addition to that, the evaluation parameter(s) and=20 > candidate URI(s)). > > > > We did look at whether it would be possible to somehow=20 > re-use 4660/1, but we thought it would be rather hacky. Some=20 > of the 4660/1 XML elements would probably be unused, and=20 > there would be a need to define new extensions - so we=20 > thought it would be nicer to define a new XML schema instead. > > > > So, I would like to request DISPATCH time to discuss this.=20 > We plan to provide an updated version of the draft, with=20 > clarifications and more details etc. > > > > Regards, > > > > Christer > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > =20 >=20 >=20 >=20 From salvatore.loreto@ericsson.com Fri Sep 25 03:32:13 2009 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 32FC53A6A13 for ; Fri, 25 Sep 2009 03:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=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 97RtHUpwo9Kf for ; Fri, 25 Sep 2009 03:32:12 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9761A3A68FF for ; Fri, 25 Sep 2009 03:32:11 -0700 (PDT) X-AuditID: c1b4fb3e-b7c03ae0000055e7-eb-4abc9c704ded Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A8.10.21991.07C9CBA4; Fri, 25 Sep 2009 12:33:21 +0200 (CEST) Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 12:33:20 +0200 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, 25 Sep 2009 12:32:11 +0200 Message-ID: <10CEDD6D91C2AD4F87003AB2D31631AC01D48F33@esealmw103.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter Proposal for Disaggregated Media Thread-Index: Aco8XXvRdNs0UbfGRQCKohgDjYZG/QA/u/6QABvBOL0= References: <4AB75AC7.6080509@ericsson.com> <4AB79C7C.5010803@cisco.com> <4ABA2BFA.40209@ericsson.com> <1ECE0EB50388174790F9694F77522CCF203EF56F@zrc2hxm0.corp.nortel.com> From: "Salvatore Loreto" To: "Francois Audet" X-OriginalArrivalTime: 25 Sep 2009 10:33:20.0768 (UTC) FILETIME=[9A2B8800:01CA3DCB] X-Brightmail-Tracker: AAAAAA== Cc: IETF Dispatch , Gonzalo Camarillo Subject: Re: [dispatch] Charter Proposal for Disaggregated Media 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: Fri, 25 Sep 2009 10:32:13 -0000 Hi Francois, thanks for the support to the work. the idea for the eventual wg is to focus on both the "loosely coupled" = aspects and the improvements for a centralized approach using 3PCC or other protocols. /Sal -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Fri 9/25/2009 12:26 AM To: Salvatore Loreto Cc: IETF Dispatch; Gonzalo Camarillo Subject: RE: [dispatch] Charter Proposal for Disaggregated Media =20 I support this work, and as we have seen in the past, with multiple = proposals, the need is real. The charter generaly looks OK to me.=20 I am personally much more interested in the "loosely coupled" aspect to = this, as opposed to the MBUS/MEGACO/3PCC aspects, but I don't object to the=20 group covering both. -Francois > -----Original Message----- From: Salvatore Loreto To: IETF Dispatch Cc: Gonzalo Camarillo Date: Mon, 21 Sep 2009 13:51:51 +0300 Hi there, below is a charter proposal for a WG on Disaggregated Media. All comments, thoughts, feedbacks are very welcome! cheers Sal Disaggregated Media WG Charter -------------------------------=20 Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the media session. The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate the different devices under his control to involve them in the call. The different devices can communicate with one another using Mbus = messages, and then let only one device, a call control engine, to = initiate, manage and terminate call control relations to other SIP = endpoints. All the different user's devices need to support the Mbus = protocol. The Megaco [RFC3525] protocol can be used in a disaggregated media = scenario to let one of the user's devices act as a Media Gateway = Controller, coordinating all the other devices under the user's control, which in = this case will act as Media Gateways. In this case all the different user's = devices need to support the Megaco protocol. The SIP protocol provides 3pcc [RFC3725] as a possible mechanism to coordinate the exchange of media streams coming from different = devices under the control of the same user, in the case at least one = among the different devices under his control supports this mechanism = and is able to become a Controller for the other in the call. All the existing mechanisms only cover a subset of the interesting = scenarios that involve disaggregated media. Scenarios not covered by = existing mechanisms include the loosely-coupled one where none of the = nodes can act as a controller because it does not support the necessary functionality or because it = will not participate in the whole session. The objective of the proposed working group is to develop a framework for Disaggregated Media that include both improvements on existing = mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms = like a loosely coupled mechanism that does not require the = implementation of complex logic on any of the terminals. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key design = considerations for Disaggregated mediamechanism. 2. A specification for a loosely couple mechanism. 3. One or more specifications to improve existing mechanism to = coordinate disaggregated media. From lorenzo@meetecho.com Fri Sep 25 03:49:22 2009 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 6E5BE3A6932 for ; Fri, 25 Sep 2009 03:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=0.604, 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 rwHUN9mDjQqp for ; Fri, 25 Sep 2009 03:49:21 -0700 (PDT) Received: from smtp7.aruba.it (smtpd2.aruba.it [62.149.128.207]) by core3.amsl.com (Postfix) with SMTP id 8970D3A689F for ; Fri, 25 Sep 2009 03:49:20 -0700 (PDT) Received: (qmail 19860 invoked by uid 89); 25 Sep 2009 10:50:27 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.172) by smtp7.aruba.it with SMTP; 25 Sep 2009 10:50:27 -0000 Date: Fri, 25 Sep 2009 12:49:57 +0200 From: Lorenzo Miniero To: Salvatore Loreto Message-Id: <20090925124957.cb301540.lorenzo@meetecho.com> In-Reply-To: <4AB75AC7.6080509@ericsson.com> References: <4AB75AC7.6080509@ericsson.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: smtp7.aruba.it 1.6.2 0/1000/N Cc: IETF Dispatch , Gonzalo Camarillo Subject: Re: [dispatch] Charter Proposal for Disaggregated Media 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: Fri, 25 Sep 2009 10:49:22 -0000 Hi Salvatore, I definitely support this proposal, and can see many use cases for it. Be it just guidelines on the existing solutions, or new mechanisms to support the required scenarios, we need something to address disaggregated media, and my feeling is that the charter already looks quite fine. Talking about it in Hiroshima will probably help refining it. L. On Mon, 21 Sep 2009 13:51:51 +0300 Salvatore Loreto wrote: > Hi there, > > below is a charter proposal for a WG on Disaggregated Media. > > All comments, thoughts, feedbacks are very welcome! > > cheers > Sal > > > > Disaggregated Media WG Charter > ------------------------------- > Disaggregated media refers to the ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are treated > by the far end of the session as a single media session. > > Generally, a given participant uses a single device to establish (or > participate in) a given multimedia session. Consequently, the SIP > signaling to manage the multimedia session and the actual media > streams are typically co-located in the same device. In scenarios > involving disaggregated media, a user wants to establish a single > multimedia session combining different media streams coming from > different devices under his or her control. This creates a need to > coordinate the exchange of the those media streams within the media > session. > > The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate > the different devices under his control to involve them in the call. > The different devices can communicate with one another using Mbus > messages, and then let only one device, a call control engine, to > initiate, manage and terminate call control relations to other SIP endpoints. > All the different user's devices need to support the Mbus protocol. > > The Megaco [RFC3525] protocol can be used in a disaggregated media > scenario to let one of the user's devices act as a Media Gateway Controller, > coordinating all the other devices under the user's control, which in this case > will act as Media Gateways. In this case all the different user's devices > need to support the Megaco protocol. > > The SIP protocol provides 3pcc [RFC3725] as a possible mechanism > to coordinate the exchange of media streams coming from different > devices under the control of the same user, in the case at least > one among the different devices under his control supports this > mechanism and is able to become a Controller for the other in the call. > > > All the existing mechanisms only cover a subset of the interesting scenarios > that involve disaggregated media. Scenarios not covered by existing mechanisms > include the loosely-coupled one where none of the nodes can act as a controller > because it does not support the necessary functionality or because it will not > participate in the whole session. > > > The objective of the proposed working group is to develop a framework > for Disaggregated Media that include both improvements on existing > mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms > like a loosely coupled mechanism that does not require the implementation > of complex logic on any of the terminals. > > > Specifically, the proposed working group will develop the following > deliverables: > 1. A framework document describing key design considerations for Disaggregated > mediamechanism. > 2. A specification for a loosely couple mechanism. > 3. One or more specifications to improve existing mechanism to coordinate > disaggregated media. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Lorenzo Miniero From victor.pascual.avila@gmail.com Mon Sep 28 09:39:58 2009 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 3B3103A694D for ; Mon, 28 Sep 2009 09:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlBsjJSsKsda for ; Mon, 28 Sep 2009 09:39:57 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id EA2F83A659B for ; Mon, 28 Sep 2009 09:39:56 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so511873eyf.5 for ; Mon, 28 Sep 2009 09:41:12 -0700 (PDT) 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=3tVW01ksPRVmGJwETMbizVG2D4HKp7tTImlXC7hlwTM=; b=O0eqqJ/GtbyYEWwO5MI3EWtWlbwWYrbqxNecYu0yoPHQ1Mu0hCzuUXF3QGKO8hY/wE +3g+N5e0G49M9v7Cg0HTod4AKOBmQ8ahO+FDIYp5KfS+FUto8m4iz9u0zYCBg5WvOJK2 pdwoFZm5mtT7szEp7I7YCry1fllwfEKvQLYYQ= 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=qpf/OmPc16Ystb/biYCB6pUaxRmJ+AyZuznlr1UcmJz8reiNwUC+E9CFKw4FmoPBRL 4LPOyCrSCBdj4lEb0SPMAsmc3/GINll9gt/RQI5F27ZXs+8Ai088IlwKKL2MJLeYvQvH cWuMQg99SX+ax1QVGMR8PiGk5bg2/quXUut3o= MIME-Version: 1.0 Received: by 10.216.18.209 with SMTP id l59mr803445wel.7.1254156071921; Mon, 28 Sep 2009 09:41:11 -0700 (PDT) In-Reply-To: <52D749FD-BE59-4370-9517-D328FD4B0C3B@voxeo.com> References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.com> <52D749FD-BE59-4370-9517-D328FD4B0C3B@voxeo.com> Date: Mon, 28 Sep 2009 18:41:11 +0200 Message-ID: <618e24240909280941n13e630d3re706a32480e7a798@mail.gmail.com> From: Victor Pascual Avila To: Dan York Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 28 Sep 2009 16:39:58 -0000 Dan, thanks for your support. We encourage folks to take a look at it and provide comments over the coming weeks so that we can address them before the next IETF meeting. Cheers, -Victor On Thu, Sep 3, 2009 at 5:19 PM, Dan York wrote: > Victor and John, > > In getting caught up on all that's been going on in DISPATCH over the pas= t > bit, I will only say that *yes*, I think this is both helpful and going i= n > the right direction. =C2=A0Please do continue your work on it. =C2=A0I do= not > currently have further feedback beyond saying that. > > Thanks for doing this, > Dan > On Jul 21, 2009, at 12:17 PM, Victor Pascual Avila wrote: > >> As mentioned in the below message, the authors would appreciate >> feedback as to whether this is helpful and going in the right >> direction. >> >> Thanks, >> -Victor >> >> 2009/6/29 Elwell, John : >>> >>> There was an extensive discussion at IETF#74 on SIP Identity, where a >>> good many views were put forward. The only consensus seemed to be to >>> continue to discuss the topic. >>> >>> One of the themes during that discussion was to focus more on >>> requirements, which the authors have attempted to do in this new draft: >>> >>> http://www.ietf.org/internet-drafts/draft-elwell-dispatch-identity-reqs= -00.txt >>> >>> We would appreciate feedback as to whether this is helpful and going in >>> the right direction, as well as detailed comments. >>> >>> I had hoped to do this a lot earlier, to trigger a discussion in time t= o >>> get something set up for DISPATCH at IETF#75, but I failed, and also I >>> failed to talk to the many of you who have interest in the topic and >>> expressed opinions in the past. But since the deadline is approaching, = I >>> thought it best to post the draft and let discussion continue on that b= asis. >>> >>> John >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > -- > Dan York, Director of Conversations > Voxeo Corporation =C2=A0 http://www.voxeo.com =C2=A0dyork@voxeo.com > Phone: +1-407-455-5859 =C2=A0 =C2=A0Skype: danyork > > Join the Voxeo conversation: > Blogs: http://blogs.voxeo.com > Twitter: http://twitter.com/voxeo =C2=A0http://twitter.com/danyork > Facebook: http://www.facebook.com/voxeo > > > > > > > > > --=20 Victor Pascual =C3=81vila From dworley@nortel.com Mon Sep 28 13:21:44 2009 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 582753A6A00 for ; Mon, 28 Sep 2009 13:21:44 -0700 (PDT) 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 HjnwLOiDQTnP for ; Mon, 28 Sep 2009 13:21:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1FEEC3A6933 for ; Mon, 28 Sep 2009 13:21:43 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8SKMuq06850 for ; Mon, 28 Sep 2009 20:22:56 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 16:22:56 -0400 From: "Dale Worley" To: DISPATCH In-Reply-To: <4AB75AC7.6080509@ericsson.com> References: <4AB75AC7.6080509@ericsson.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 28 Sep 2009 16:22:55 -0400 Message-Id: <1254169375.3866.28.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: 28 Sep 2009 20:22:56.0126 (UTC) FILETIME=[76C409E0:01CA4079] Subject: Re: [dispatch] Charter Proposal for Disaggregated Media 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, 28 Sep 2009 20:21:44 -0000 The general approach of the charter looks good to me, but there seem to be too many words used to describe the existing methods (which may or may not be solutions to the problem), and a lack of sharpness in describing the area we are focusing on. Let me propose some alternative text. I think that this does not change the intention of any of the text. Disaggregated Media WG Charter ------------------------------- Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. OK Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the media session. OK The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate the different devices under his control to involve them in the call. The different devices can communicate with one another using Mbus messages, and then let only one device, a call control engine, to initiate, manage and terminate call control relations to other SIP endpoints. All the different user's devices need to support the Mbus protocol. The Megaco [RFC3525] protocol can be used in a disaggregated media scenario to let one of the user's devices act as a Media Gateway Controller, coordinating all the other devices under the user's control, which in this case will act as Media Gateways. In this case all the different user's devices need to support the Megaco protocol. The SIP protocol provides 3pcc [RFC3725] as a possible mechanism to coordinate the exchange of media streams coming from different devices under the control of the same user, in the case at least one among the different devices under his control supports this mechanism and is able to become a Controller for the other in the call. All the existing mechanisms only cover a subset of the interesting scenarios that involve disaggregated media. Scenarios not covered by existing mechanisms include the loosely-coupled one where none of the nodes can act as a controller because it does not support the necessary functionality or because it will not participate in the whole session. There are a number of protocols now used that are used to coordinate a number of devices (e.g., Mbus, Megaco, SIP 3pcc), but the common methods of using those protocols all require a "master" device that must remain involved in the user's session for its entire duration. The objective of the proposed working group is to develop a framework for Disaggregated Media that include both improvements on existing mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms like a loosely coupled mechanism that does not require the implementation of complex logic on any of the terminals. The objective of the proposed working group is to develop a framework for Disaggregated Media in "loosely-coupled" scenarios, where no single device can remain in the session for its entire duration and/or no single device has the necessary functionality to coordinate all of the media streams. The framework may include improvements on existing mechanisms (e.g. 3pcc), the development of one or more new mechanisms, and/or new methods of utilizing mechanisms. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key design considerations for Disaggregated mediamechanism. 2. A specification for a loosely couple mechanism. 3. One or more specifications to improve existing mechanism to coordinate disaggregated media. Specifically, the proposed working group will develop the following deliverables: 1. Use cases and functional requirements for the mechanism(s) 2. A framework document describing key design considerations for disaggregated media mechanism(s) 3. One or more specifications for new mechanism(s), to improve existing mechanism(s), and/or improve their utilization(s) to coordinate disaggregated media Dale From dworley@nortel.com Mon Sep 28 13:36:14 2009 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 7C9583A6A0F for ; Mon, 28 Sep 2009 13:36:14 -0700 (PDT) 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 q+5aAaWTO6gq for ; Mon, 28 Sep 2009 13:36:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8DCB93A63EC for ; Mon, 28 Sep 2009 13:36:13 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8SKbTq09551; Mon, 28 Sep 2009 20:37:29 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 16:37:28 -0400 From: "Dale Worley" To: Alan Johnston In-Reply-To: <4AAA5C98.1080502@sipstation.com> References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> <4AAA5C98.1080502@sipstation.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 28 Sep 2009 16:37:28 -0400 Message-Id: <1254170248.3866.35.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: 28 Sep 2009 20:37:28.0883 (UTC) FILETIME=[7EF83030:01CA407B] Cc: dispatch@ietf.org Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic Domain Registration 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, 28 Sep 2009 20:36:14 -0000 The whole "problem" seems strange to me. There is the question of getting the SIP domain properly mapped to the IP address, but we have dynamic DNS for that, and our prototypical PBX could coordinate that with the service provider. As for "it is impractical and cost-prohibitive to manually provision their IP Addresses in every SIP node along the path which needs to reach the SMB IP-PBX customer", of course you don't manually provision that information: The Domain Name System automagically propagates the domain-to-IP-address mapping to the entire Internet, and the various routing protocols automagically propagate the IP routing information to "every node along the path". On Fri, 2009-09-11 at 09:20 -0500, Alan Johnston wrote: > The plan is to standardize a function that has been shown to be needed > in the marketplace for the deployment of SIP in certain applications. > > And yes, dynamic DNS is an alternative, it does work, but again, there > are reasons why it is not being used in this certain application. Might you be able to reveal those reasons? The techniques I've described are the ones used by the people I know. Dale From dworley@nortel.com Mon Sep 28 13:49:06 2009 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 E638D3A680A for ; Mon, 28 Sep 2009 13:49:06 -0700 (PDT) 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 CvMM7Dbjjd0g for ; Mon, 28 Sep 2009 13:49:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 19F4A3A677C for ; Mon, 28 Sep 2009 13:49:05 -0700 (PDT) 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 n8SKoIq11340; Mon, 28 Sep 2009 20:50:19 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 16:50:15 -0400 From: "Dale Worley" To: R.Jesske@telekom.de In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404EE1E67@S4DE8PSAAQB.mitte.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD404EE1E67@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 28 Sep 2009 16:50:15 -0400 Message-Id: <1254171015.3866.37.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: 28 Sep 2009 20:50:16.0168 (UTC) FILETIME=[484E9680:01CA407D] Cc: dispatch@ietf.org Subject: Re: [dispatch] New draft version of draft-jesske-dispatch-reason-in-responses-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, 28 Sep 2009 20:49:07 -0000 On Mon, 2009-09-14 at 13:10 +0200, R.Jesske@telekom.de wrote: > A since a couple of weeks a new version of the Reason in Responses > draft is now available. > > http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-00 > > I have incorporated all comments and the discussion conclusions > received for this draft. There seems to be quite a bit of duplicated text in the Abstract. Dale From dean.willis@softarmor.com Mon Sep 28 21:33:24 2009 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 AA78828C119 for ; Mon, 28 Sep 2009 21:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 l-iSYYU0cS88 for ; Mon, 28 Sep 2009 21:33:23 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id BD8A228C107 for ; Mon, 28 Sep 2009 21:33:23 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8T4YevI009035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2009 23:34:42 -0500 Message-Id: <8F191E7F-8D3E-4A2C-902C-CF8351129377@softarmor.com> From: Dean Willis To: Dale Worley In-Reply-To: <1254170248.3866.35.camel@khone.us.nortel.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: Mon, 28 Sep 2009 23:34:35 -0500 References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> <019d01ca2d99$67f0a1f0$37d1e5d0$@us> <0F05CF0C-0956-4D32-BD4D-1DEB59DF13FB@softarmor.com> <4AAA5C98.1080502@sipstation.com> <1254170248.3866.35.camel@khone.us.nortel.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic Domain Registration 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, 29 Sep 2009 04:33:24 -0000 On Sep 28, 2009, at 3:37 PM, Dale Worley wrote: > The whole "problem" seems strange to me. There is the question of > getting the SIP domain properly mapped to the IP address, but we have > dynamic DNS for that, and our prototypical PBX could coordinate that > with the service provider. As for "it is impractical and > cost-prohibitive to manually provision their IP Addresses in every SIP > node along the path which needs to reach the SMB IP-PBX customer", of > course you don't manually provision that information: The Domain Name > System automagically propagates the domain-to-IP-address mapping to > the > entire Internet, and the various routing protocols automagically > propagate the IP routing information to "every node along the path". I struggled with this as well. But now that I'm thinking about the problem as trying to dynamically construct a SIP route between the proxy-of-record (as indicated by DNS) and a local proxy or multi-user UA (read "PBX"), I'm finding the problem significantly more tractable. The reason DDNS doesn't work for this is that there might be private topography between the proxy-of-record and the multiuser UA (think "outbound". Now think massively-shared outbound connections). -- Dean From Simo.Veikkolainen@nokia.com Wed Sep 30 02:07:57 2009 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 4953528C121 for ; Wed, 30 Sep 2009 02:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 jr5HvI3CrLcZ for ; Wed, 30 Sep 2009 02:07:55 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DC3483A6A37 for ; Wed, 30 Sep 2009 02:07:54 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8U99212007851; Wed, 30 Sep 2009 12:09:12 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 12:09:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 12:09:03 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 30 Sep 2009 11:09:02 +0200 From: To: , , , , Date: Wed, 30 Sep 2009 11:09:01 +0200 Thread-Topic: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Thread-Index: AcotWH8228L9+UCaSe+ExJ7BE/QIsgO+rxqAACPN20AAEur0kAEfzNzQ Message-ID: References: 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_B23B311878A0B4438F5F09F47E01AAE03B18AD248DNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2009 09:09:03.0512 (UTC) FILETIME=[A7E04180:01CA41AD] X-Nokia-AV: Clean Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/XMPP 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, 30 Sep 2009 09:07:57 -0000 --_000_B23B311878A0B4438F5F09F47E01AAE03B18AD248DNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rifaat, sorry for the late reply. If I understood your scenario correctly, you are proposing to use separete = correlation id's in each direction. That would work as well, but I don't se= e the reason why Alice would choose call-id2 as her correlation id, if in a= ny case call-id1 gets to her UA in F2. Simo ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Rifaat Shekh-Yusef Sent: 24 September, 2009 18:57 To: Isomaki Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia-D/Helsinki);= dispatch@ietf.org; Mary Barnes; gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Simo, If I add a B2BUA to the example that you have in section 7.2: Bob B2BUA = Alice | | = | | (F1) INVITE | (F2) INVITE = | |-------------------------------------------------- >|---------------------= ------------------------------> | | XMPP-Contact: Bob; call-id1 | XMPP-Contact: Bob; call-id1 = | | | = | | | = | | (F4) 200 OK | (F3) 200 OK = | |<-------------------------------------------------- |<--------------------= ------------------------------ | | XMPP-Contact: Alice; call-id2 | XMPP-Contact: Alice; call-id2 = | | | = | Let (F1) INVITE have the correlation-id as the Call-ID of the dialog betwee= n Bob and the B2BUA (call-id1), and (F3) 200 OK have the correlation-id as the Call-ID of the dialog betwee= n the B2BUA and Alice (call-id2). Would it not be enough for Bob to send call-id2 to Alice as the ? and for Alice to send call-id1 to Bob as the ? Regards, Rifaat ________________________________ From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, September 24, 2009 2:54 AM To: Shekh-Yusef, Rifaat (BVW:9T16); Simo.Veikkolainen@nokia.com; dispatch@i= etf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsson.com Subject: RE: [dispatch] New topic proposal for DISPATCH - SIP/XMPP Hi Rifaat, In our proposal the correlation works so that: 1. UAs engaged in a SIP session/dialog exchange an identifier related to th= at session (as well as their XMPP full JIDs) 2. They insert them in the very first XMPP messages they subsequently excha= nge, in order to correlate that exchange to be related to the SIP session. The correlation identifier has to be end-to-end, otherwise the other end wo= n't be able to use it for correlation. Call-ID is often changed enroute. So= , if one endpoint puts it in an XMPP messages as a reference to a SIP sessi= on, the other endpoint won't recognize it as it has a different Call-ID for= the same session. Markus ________________________________ From: ext Rifaat Shekh-Yusef [mailto:rifatyu@nortel.com] Sent: 23 September, 2009 22:57 To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf.org; Mary Barnes; g= onzalo.camarillo@ericsson.com Cc: Isomaki Markus (Nokia-CIC/Espoo) Subject: RE: [dispatch] New topic proposal for DISPATCH Simo, Markus, I am very interested in this work and I like your approach. I have a question regarding the open issue you have in section 5.2: Why do you require the correlation-value to be an end-to-end identifier? In the case where there is an SBC that creates a new dialog for the target,= would it not be enough for each endpoint to use the Call-ID of the other d= ialog as the correlation-value? Thanks, Rifaat ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Simo.Veikkolainen@nokia.com Sent: Friday, September 04, 2009 8:09 AM To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00); gonzalo.camarillo@ericsso= n.com Cc: Markus.Isomaki@nokia.com Subject: [dispatch] New topic proposal for DISPATCH Hi, We would like to propose a new DISPATCH topic on how SIP and XMPP can be us= ed together in a complementary fashion. We have been working on a solution which combines SIP based VoIP and XMPP b= ased IM and Presence. The requirements and a proposed solution is outlined = in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01. The motivation for this work comes from experience which shows that most st= andards based VoIP deployments use SIP. At the same time, the Extensible Me= ssaging and Presence Protocol (XMPP) is widely used in instant messaging an= d presence services. An interesting scenario arises when a SIP based voice = (and video) service is combined together with an XMPP based instant messagi= ng and presence service. Note that the goal in this work is not SIP-XMPP protocol translation, but t= o define protocol extensions and best practises such that SIP based VoIP an= d XMPP based IM and presence could be seamlessly combined and offered to th= e end user. For rapid deployment, we assume no changes in the server infras= tructure, and instead impose new requirements and protocol extensions only = to the endpoints. We would like to get some discussion going on the use case itself as well a= s on the solution. Also, we would like to hear you thoughts on DISPATCH or = a new "dispatched" mini-WG as the home for such work. Exact charter proposal and problem statemen is to follow. Regards, Simo and Markus --_000_B23B311878A0B4438F5F09F47E01AAE03B18AD248DNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Rifaat,
 
sorry for the late reply.
 
If I understood your scenario correctly, you are p= roposing=20 to use separete correlation id's in each direction. That would work as well= , but=20 I don't see the reason why Alice would choose call-id2 as her correlation i= d, if=20 in any case call-id1 gets to her UA in F2.
 
Simo

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Rifaat=20 Shekh-Yusef
Sent: 24 September, 2009 18:57
To: Isomak= i=20 Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia-D/Helsinki);=20 dispatch@ietf.org; Mary Barnes;=20 gonzalo.camarillo@ericsson.com
Subject: Re: [dispatch] New topi= c=20 proposal for DISPATCH - SIP/XMPP

Simo,

 

If I add a B2BUA to the example that yo= u have=20 in section 7.2:

 

Bob       &nbs= p;            &= nbsp;           &nbs= p;               B2B= UA       &nbs= p;            &= nbsp;           &nbs= p;         Alice

|       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        |       &nbs= p;            &= nbsp;           &nbs= p;                 &nbs= p;  |<= /P>

| (F1) INVITE<= SPAN=20 style=3D"mso-tab-count: 4">       &nbs= p;            &= nbsp;           &nbs= p;   | (F2) INVITE       &nbs= p;            &= nbsp;           &nbs= p;   |

|-------------= -------------------------------------=20 >|--------------------------------------------------->=20 |

| XMPP-Contact= : Bob;=20 call-id1           | XMPP-Contact: Bob; call-id1          =20 |

|       &nbs= p;            &= nbsp;           &nbs= p;               &nbs= p;   =20 |       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       =20 |

|       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      =20 |       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       =20 |

| (F4) 200 OK<= SPAN=20 style=3D"mso-tab-count: 4">       &nbs= p;            &= nbsp;           &nbs= p; |=20 (F3) 200 OK       &nbs= p;            &= nbsp;           &nbs= p; =20 |

|<---------= -----------------------------------------=20 |<-------------------------------------------------- |

| XMPP-Contact= :=20 Alice; call-id2         | XMPP-Contact= :=20 Alice= ;=20 call-id2    <= SPAN=20 style=3D"mso-tab-count: 1">      |

|       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      =20 |       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      =20 |

 

 

Let (F1) INVIT= E have=20 the correlation-id as the Call-ID= of the=20 dialog between Bob and the B2BUA (call-id1),

and (F3) 200 O= K have=20 the correlation-id as the Call-ID= of the=20 dialog between the B2BUA and Alice (call-id2).

 

Would it not b= e=20 enough for Bob to send call-id2 to Alice as the <sip-correlation>? and for Alice to send call-id1 to Bob as=20 the <sip-correlation>?

 

Regards,<= /o:p>

 Rifaat


From: Markus.Isomaki@nokia.com=20 [mailto:Markus.Isomaki@nokia.com]
Sent: Thursday, September 24= ,=20 2009 2:54 AM
To: Shekh-Yusef, Rifaat (BVW:9T16);=20 Simo.Veikkolainen@nokia.com; dispatch@ietf.org; Barnes, Mary (RICH2:AR00)= ;=20 gonzalo.camarillo@ericsson.com
Subject: RE: [dispatch] New topi= c=20 proposal for DISPATCH - SIP/XMPP

<= SPAN=20 class=3D705224406-24092009>Hi Rifaat,
<= SPAN=20 class=3D705224406-24092009> 
<= SPAN=20 class=3D705224406-24092009>In our proposal the correlation works so=20 that:
<= SPAN=20 class=3D705224406-24092009>1. UAs engaged in a SIP session/dialog exchang= e an=20 identifier related to that session (as well as their XMPP full=20 JIDs)
<= SPAN=20 class=3D705224406-24092009>2. They insert them in the very first XMPP mes= sages=20 they subsequently exchange, in order to correlate that exchange to be rel= ated=20 to the SIP session.
<= SPAN=20 class=3D705224406-24092009> 
<= SPAN=20 class=3D705224406-24092009>The correlation identifier has to be end-to-en= d,=20 otherwise the other end won't be able to use it for correlation. Call-ID = is=20 often changed enroute. So, if one endpoint puts it in an XMPP messages as= a=20 reference to a SIP session, the other endpoint won't recognize it as it h= as a=20 different Call-ID for the same session.
<= SPAN=20 class=3D705224406-24092009> 
<= SPAN=20 class=3D705224406-24092009>Markus

From: ext Rifaat Shekh-Yusef=20 [mailto:rifatyu@nortel.com]
Sent: 23 September, 2009=20 22:57
To: Veikkolainen Simo (Nokia-D/Helsinki); dispatch@ietf= .org;=20 Mary Barnes; gonzalo.camarillo@ericsson.com
Cc: Isomaki Marku= s=20 (Nokia-CIC/Espoo)
Subject: RE: [dispatch] New topic proposal = for=20 DISPATCH

Simo, Markus,
 
I=20 am very interested in this work and I like your=20 approach.
 
I=20 have a question regarding the open issue you have in section=20 5.2:
Why do you require the correlation-value to be an end-to-end=20 identifier?
In=20 the case where there is an SBC that creates a new dialog for the=20 target, would it not be enough for each endpoint to use= the=20 Call-ID of the other dialog as the correlation-value?
 
Thanks,
 Rifaat
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 Simo.Veikkolainen@nokia.com
Sent: Friday, September 04, 2= 009=20 8:09 AM
To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00);=20 gonzalo.camarillo@ericsson.com
Cc:=20 Markus.Isomaki@nokia.com
Subject: [dispatch] New topic propos= al=20 for DISPATCH

Hi,
 
We would like to propose a new DISPATCH topic on how SIP and XMPP = can=20 be used together in a complementary fashion.
 
We have been working on a solution which combines SIP based VoIP a= nd=20 XMPP based IM and Presence. The requirements and a proposed solution is= =20 outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-vo= ip-xmpp-im-01.
 
The motivation for this work comes from experience which shows tha= t=20 most standards based VoIP deployments use SIP. At the same time, the=20 Extensible Messaging and Presence Protocol (XMPP) is widely used in ins= tant=20 messaging and presence services. An interesting scenario arises when a = SIP=20 based voice (and video) service is combined together with an XMPP based= =20 instant messaging and presence service.
 
Note that the goal in this work is not SIP-XMPP protocol translati= on,=20 but to define protocol extensions and best practises such that SIP base= d=20 VoIP and XMPP based IM and presence could be seamlessly combined and of= fered=20 to the end user. For rapid deployment, we assume no changes in the serv= er=20 infrastructure, and instead impose new requirements and protocol extens= ions=20 only to the endpoints.
 
We would like to get some discussion going on the use case itself = as=20 well as on the solution. Also, we would like to hear you thoughts on=20 DISPATCH or a new "dispatched" mini-WG as the home for such work.
 
Exact charter proposal and problem statemen is to follow.
 
Regards,
Simo and Markus
 
 
--_000_B23B311878A0B4438F5F09F47E01AAE03B18AD248DNOKEUMSG01mgd_-- From smythc@avaya.com Wed Sep 30 11:53:44 2009 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 B58053A686B for ; Wed, 30 Sep 2009 11:53:44 -0700 (PDT) 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 2JDj2zfZPM5q for ; Wed, 30 Sep 2009 11:53:43 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 9E9493A691D for ; Wed, 30 Sep 2009 11:53:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,481,1249272000"; d="scan'208";a="175193449" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 30 Sep 2009 14:55:05 -0400 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Sep 2009 14:55:04 -0400 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, 30 Sep 2009 19:54:39 +0100 Message-ID: <4C607BEA097DF048BEA625B974A36618D40443@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence Thread-Index: AcpB/kMei4fohwxwSvafRVa9tsOYRQAAJz+w From: "Smyth, Colm (Colm)" To: Cc: Simo.Veikkolainen@nokia.com Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence 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, 30 Sep 2009 18:53:44 -0000 Hi, =20 I'm interested in contributing to this working group. =20 The charter looks good, I'd like to tweak or clarify some aspects of the description. =20 I agree that it's useful to focus is on the user experience of a hybrid SIP/XMPP client, and leave out aspects of protocol-level interworking (for example to define how to achieve an end-to-end voice session between an XMPP/Jingle client and a SIP voice endpoint). =20 1. addressing A hybrid SIP/XMPP client must have addresses in both protocols, but it's not clear to me that it's mandatory that a hybrid SIP/XMPP client must be able to automatically learn the corresponding address of other users in the other protocol. It may be sufficient in simple clients for the user to manually associate the other address with one of their contacts. The other address could be discovered in a shared directory, or in a private contacts store. It might also define ways for a user to "publish" their address in the other protocol (e.g. sending an XMPP message that contains their SIP address), that might allow the client to discover and (automatically or at the user's discretion) register that address. =20 2. session correlation This topic seems to be entirely around operations and elements in the UI. It's not so much about sessions as about allowing some operations to span the two protocols (e.g. create/join/exit a conference that spans SIP voice and XMPP chat, or "escalating" a conference in one protocol to include the other, or "downgrading" it to exclude the other). =20 3. presence It would make sense to be able to change session in either protocol based on activity in the other, at the discretion of the client and the user. I agree with the view that the WG should exclude details of protocol-level aspects, but to be useful, I think the WG should address the user experience but also provide concrete guidelines on implementing cross-protocol presence spanning or synchronization, including mapping parts of an XMPP presence stanza to/from a (SIP) PIDF document. This group should address if the SIP and XMPP endpoints are to be considered as separate points of presence, or if they are to be 100% synchronized. Ideally we would cover both scenarios (e.g. discrete PIDF elements and possibly a second XMPP session to a different resource for the same JID). Peter St Andre referred to several drafts that do relate to SIP/XMPP protocol inter-working: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media I would also like to see these drafts progress to RFCs, but I think that is outside the charter of this group. Related to presence, I would like to see this group agree on a richer mapping than the one in Table 6 of draft-saintandre-sip-xmpp-presence, specifically to define a standard way to map bidirectionally between the different states and PIDF elements. =20 Colm. From dworley@nortel.com Wed Sep 30 14:00:50 2009 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 ABF7D3A68FB for ; Wed, 30 Sep 2009 14:00:50 -0700 (PDT) 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 If8Vca3SvPXW for ; Wed, 30 Sep 2009 14:00:50 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BD9513A689F for ; Wed, 30 Sep 2009 14:00:49 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8UL28N26275 for ; Wed, 30 Sep 2009 21:02:08 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 17:02:07 -0400 From: "Dale Worley" To: DISPATCH In-Reply-To: <1254169375.3866.28.camel@khone.us.nortel.com> References: <4AB75AC7.6080509@ericsson.com> <1254169375.3866.28.camel@khone.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 30 Sep 2009 17:02:06 -0400 Message-Id: <1254344526.4375.29.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: 30 Sep 2009 21:02:07.0557 (UTC) FILETIME=[45276F50:01CA4211] Subject: Re: [dispatch] Charter Proposal for Disaggregated Media 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, 30 Sep 2009 21:00:50 -0000 On Mon, 2009-09-28 at 16:22 -0400, Dale Worley wrote: > The objective of the proposed working group is to develop a framework > for Disaggregated Media that include both improvements on existing > mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms > like a loosely coupled mechanism that does not require the implementation > of complex logic on any of the terminals. > > The objective of the proposed working group is to develop a > framework for Disaggregated Media in "loosely-coupled" scenarios, > where no single device can remain in the session for its entire > duration and/or no single device has the necessary functionality > to coordinate all of the media streams. We could add "and/or the session is discontinuous in time" to that list -- that was a case discussed in the past, although we may have decided to exclude that from consideration. Dale From dworley@nortel.com Wed Sep 30 14:30:45 2009 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 2CC103A677C; Wed, 30 Sep 2009 14:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 b-O8offLJgWT; Wed, 30 Sep 2009 14:30:44 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 26E663A6359; Wed, 30 Sep 2009 14:30:44 -0700 (PDT) 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 n8ULVvN21238; Wed, 30 Sep 2009 21:31:57 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 17:31:56 -0400 From: "Dale Worley" To: "Szilagyi, Mike" In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Organization: Nortel Networks Date: Wed, 30 Sep 2009 17:31:56 -0400 Message-Id: <1254346316.4375.48.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 30 Sep 2009 21:31:56.0994 (UTC) FILETIME=[6FBDDA20:01CA4215] Cc: "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [dispatch] [sipcore] Requests sent within early dialog -- CSeq mgmt 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, 30 Sep 2009 21:30:45 -0000 On Wed, 2009-08-26 at 17:10 -0400, Szilagyi, Mike wrote: > I=E2=80=99ve not been able to find definitive text regarding this issue s= o I=E2=80=99m > hoping someone can provide clarification. If a request (INFO or > UPDATE) is sent on a dialog in the early state, how are the CSeq > numbers managed by the UAS. Here=E2=80=99s an example to demonstrate my > confusion: The model is that a CANCEL is not an independent transaction from the INVITE, in the way that the UPDATE is an independent transaction from the INVITE. Indeed, CANCEL isn't even routed the same way that the UPDATE is. A CANCEL transaction is sort of a "second half" of the INVITE transaction that it is canceling. That is why the CANCEL has the same CSeq as the INVITE. (Also, your example shows the UPDATE being sent by the UAC before it receives a non-100 response. That can't be done, since the UAC doesn't know the to-tag to use; there isn't an early dialog established at that point.) Dale From fluffy@cisco.com Wed Sep 30 15:56:31 2009 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 68DBA28B23E for ; Wed, 30 Sep 2009 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 nkNttDRn3OLa for ; Wed, 30 Sep 2009 15:56:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 87A0E3A6784 for ; Wed, 30 Sep 2009 15:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1648; q=dns/txt; s=sjiport06001; t=1254351474; x=1255561074; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[dispatch]=20draft-elwell-dispatch-identity-reqs -00=20posted|Date:=20Wed,=2030=20Sep=202009=2015:57:55=20 -0700|Message-Id:=20|To:=20John=20Elwell=20|Cc:=20dispatch@ietf.org|Mime-Version:=201.0 =20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<618e24 240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.com> |References:=20=20< 0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.g b002.siemens.net>=20<618e24240907210917h61ce9a62jc5e078db 2dda0934@mail.gmail.com>; bh=OgdKPWqaHfOahloHX26bTxrsMHeLIxxHl6JVqWSEnRo=; b=UtbEASZNPOoiQAVVlvPNX59xu4K54VgaBTtdJLyKZsLDDG7fyUr4Rw0R nnhNFE22BkZsAAcSUbnhksaaTnO9HIGv2wZCl20wVKX8swMhipjfywoHc syJywlzXOo4pzku9eIeqBgeLEI+pnVcm/psV6SlLCPVDIW6lVJSsB129z k=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM9/w0qrR7MV/2dsb2JhbAC/OYhbAZABBoIxgXY X-IronPort-AV: E=Sophos;i="4.44,482,1249257600"; d="scan'208";a="399627461" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Sep 2009 22:57:54 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8UMvsQP018923; Wed, 30 Sep 2009 15:57:54 -0700 Received: from dhcp-171-68-21-115.cisco.com (dhcp-171-68-21-115.cisco.com [171.68.21.115]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8UMvsKI005965; Wed, 30 Sep 2009 22:57:54 GMT Message-Id: From: Cullen Jennings To: John Elwell In-Reply-To: <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.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: Wed, 30 Sep 2009 15:57:55 -0700 References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1648; t=1254351474; x=1255215474; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[dispatch]=20draft-elwell-dispatch-iden tity-reqs-00=20posted |Sender:=20; bh=OgdKPWqaHfOahloHX26bTxrsMHeLIxxHl6JVqWSEnRo=; b=KxFsrB+pzlGpBIqI5V9PKjp4oN3s4S8aI/DbimelKW+6l43s0l5Cj82lgi QckP8Wr95JpbnRnAY9nUEYy635Ql/eU7NJybWy5Q9MKGHjENfwYzNtHggpPQ 36IlyXaDgxjcIlc3W8mgfNHff2WH5rfDCP7lp3g5LxVjRIp2bdmW0=; Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 30 Sep 2009 22:56:31 -0000 John, I think this is going the right direction, but few comments. Req 5 is too vague to be of any use. If this was replaced with something like "The solution must allow for media steering", that would make sense to me On Req 4 - I don't think it is just the sink/source of the media. It seems that just about anything that is meant to be end to end you want bound to the identity. Imagine an page mode IM. In that case the "media" is the message and you want that bound to the caller id. On Jul 21, 2009, at 9:17 , Victor Pascual Avila wrote: > > 2009/6/29 Elwell, John : >> There was an extensive discussion at IETF#74 on SIP Identity, where >> a good many views were put forward. The only consensus seemed to be >> to continue to discuss the topic. >> >> One of the themes during that discussion was to focus more on >> requirements, which the authors have attempted to do in this new >> draft: >> http://www.ietf.org/internet-drafts/draft-elwell-dispatch-identity-reqs-00.txt >> >> We would appreciate feedback as to whether this is helpful and >> going in the right direction, as well as detailed comments. >> >> I had hoped to do this a lot earlier, to trigger a discussion in >> time to get something set up for DISPATCH at IETF#75, but I failed, >> and also I failed to talk to the many of you who have interest in >> the topic and expressed opinions in the past. But since the >> deadline is approaching, I thought it best to post the draft and >> let discussion continue on that basis. >> >> John >> > _____________________ From fluffy@cisco.com Wed Sep 30 16:16:14 2009 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 4DD073A69ED for ; Wed, 30 Sep 2009 16:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ApbINZJHH1SO for ; Wed, 30 Sep 2009 16:16:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3D7373A69D8 for ; Wed, 30 Sep 2009 16:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2203; q=dns/txt; s=sjiport06001; t=1254352657; x=1255562257; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[dispatch]=20TCP=20and=20SCTP=20connection=20reu se=20draft|Date:=20Wed,=2030=20Sep=202009=2016:17:37=20-0 700|Message-Id:=20<7DE54C6D-63A5-45C1-A618-129BB4F3BE73@c isco.com>|To:=20"Vijay=20K.=20Gurbani"=20|Cc:=20"dispatch@ietf.org"=20, =0D=0A=20=20=20=20=20=20=20=20"Jain,=20Rajnish"=20,=0D=0A=20=20=20=20=20=20=20=20Hadriel=20K aplan=20|Mime-Version:=201.0=20(A pple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4AA7D3 4C.2030804@alcatel-lucent.com>|References:=20<4AA7D34C.20 30804@alcatel-lucent.com>; bh=kKCJNKAXm6IA1L8aVGf9+XUlQuzqGtNvYCAmWeM1RS0=; b=ABSAG9kbPVb1VyhkduMxL8tA64TlRn2ZCFBKb+f1XRJi222lORrJP3gQ HslTPkjkrZKH00NnMDJjDv2EOyoD25VSkUzOHJFLWI1LKiQaxC4aHZh+M 1Mo3D7bJX+0J/s74SjSb/Ftm5GH+79OM4XmZFEDL1mcBVYF5bOHyMSZOF I=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFKDw0qrR7MV/2dsb2JhbAC/CYhbAZADBoQn X-IronPort-AV: E=Sophos;i="4.44,482,1249257600"; d="scan'208";a="399635288" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Sep 2009 23:17:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8UNHbvN019688; Wed, 30 Sep 2009 16:17:37 -0700 Received: from dhcp-171-68-21-115.cisco.com (dhcp-171-68-21-115.cisco.com [171.68.21.115]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8UNHbfY029968; Wed, 30 Sep 2009 23:17:37 GMT Message-Id: <7DE54C6D-63A5-45C1-A618-129BB4F3BE73@cisco.com> From: Cullen Jennings To: "Vijay K. Gurbani" In-Reply-To: <4AA7D34C.2030804@alcatel-lucent.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: Wed, 30 Sep 2009 16:17:37 -0700 References: <4AA7D34C.2030804@alcatel-lucent.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2203; t=1254352657; x=1255216657; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[dispatch]=20TCP=20and=20SCTP=20connect ion=20reuse=20draft |Sender:=20; bh=kKCJNKAXm6IA1L8aVGf9+XUlQuzqGtNvYCAmWeM1RS0=; b=pa+p0F7rMiAtN6e8GCs7ujtWRSiNuQoed/H2795xNlT919pleOHUGSk9eU rgqLpC11gbK2JU/hcC1V8QBYW6enjFtTc/arakJuXtPJZrF63rFAtVYuxdL4 XSXrqZep/QBNN+LsK4GthPLiXeLP9p5Rpsi6Wx5Nvcn0CogOTZACM=; Cc: "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] TCP and SCTP connection reuse 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: Wed, 30 Sep 2009 23:16:14 -0000 The security of this draft seems, uh, bad. It's so bad that I am having a really hard time believing I actually am understanding it correctly. Help me make sure that I have this right. Cisco and ACME are part of the AT&T trust domain and get sip trunking from AT&T. Cisco sends a via that has ACME on the alias to AT&T. There is nothing AT&T can do to validate this. Now Cisco has hijacked all of ACME's call. If the trust domain consisted of just one party, well I see how this might be secure, sort of, but it seems to fall apart as the trust domain expands. Cullen On Sep 9, 2009, at 9:09 , Vijay K. Gurbani wrote: > Folks: Before the summer, we had released a new > TCP/SCTP connection reuse draft in the (now defunct) SIP > WG. With the formation of dispatch, we were advised to > submit it to dispatch for a decision on where to handle > this work. > > Essentially, the draft documents the practice of reusing TCP > (and SCTP) connections that is employed by some SIP > implementations today. TCP and SCTP transport reuse were > originally a part of the draft-ietf-sip-connect-reuse draft, > but were taken out before we progressed that draft to the IESG. > > Can we kindly ask the dispatch WG to review and comment on > the the TCP and SCTP connection reuse draft? All comments > received from the first iteration of the draft in the SIP WG > have been duly addressed in this version. > > It will also be helpful if the WG and chairs could provide > some guidance on how to move this work forward (i.e., > AD-sponsored individual draft, take it to sipcore, etc.) > > The draft can be retrieved from: > > http://tools.ietf.org/html/draft-jain-dispatch-sip-transport-connection-reuse-00 > > Thank you, > > - 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 mdolly@att.com Wed Sep 30 18:59:26 2009 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 2BA493A6878 for ; Wed, 30 Sep 2009 18:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.157 X-Spam-Level: X-Spam-Status: No, score=-106.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, 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 JbI7n1hCnLJS for ; Wed, 30 Sep 2009 18:59:25 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id E78B93A690E for ; Wed, 30 Sep 2009 18:59:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-2.tower-167.messagelabs.com!1254362447!13228499!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28838 invoked from network); 1 Oct 2009 02:00:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2009 02:00:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9120lOU004678 for ; Wed, 30 Sep 2009 22:00:47 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9120hMO004651 for ; Wed, 30 Sep 2009 22:00:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 30 Sep 2009 22:00:42 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4AB3@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] TCP and SCTP connection reuse draft Thread-Index: AcpCJDlS1NZNxUbbQOujIG7IIXVy+AAFsHSx From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: dispatch@ietf.org, Rajnish.Jain@ipc.com, HKaplan@acmepacket.com Subject: Re: [dispatch] TCP and SCTP connection reuse 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: Thu, 01 Oct 2009 01:59:26 -0000 Q3VsbGVuLA0KDQpDb3VsZCB5b3UgcGxlYXNlIGJlIG1vcmUgc3BlY2lmaWMgYmVjYXVzZSBteSBm aXJzdCByZWFjdGlvbiB3YXMgdG8gc2F5IHlvdXIgYXNzdW1wdGlvbiBvbiB0cnVzdCBkb21haW5z IGlzIG5vdCBhY2N1cmF0ZQ0KDQpUaGFua3MNCg0KTWFydGluDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgPGRpc3BhdGNoLWJv dW5jZXNAaWV0Zi5vcmc+DQpUbzogVmlqYXkgSy4gR3VyYmFuaSA8dmtnQGFsY2F0ZWwtbHVjZW50 LmNvbT4NCkNjOiBkaXNwYXRjaEBpZXRmLm9yZyA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBKYWluLFJh am5pc2ggPFJham5pc2guSmFpbkBpcGMuY29tPjsgSGFkcmllbCBLYXBsYW4gPEhLYXBsYW5AYWNt ZXBhY2tldC5jb20+DQpTZW50OiBXZWQgU2VwIDMwIDE5OjE3OjM3IDIwMDkNClN1YmplY3Q6IFJl OiBbZGlzcGF0Y2hdIFRDUCBhbmQgU0NUUCBjb25uZWN0aW9uIHJldXNlIGRyYWZ0DQoNCg0KVGhl IHNlY3VyaXR5IG9mIHRoaXMgZHJhZnQgc2VlbXMsIHVoLCBiYWQuIEl0J3Mgc28gYmFkIHRoYXQg SSBhbSAgDQpoYXZpbmcgYSByZWFsbHkgaGFyZCB0aW1lIGJlbGlldmluZyBJIGFjdHVhbGx5IGFt IHVuZGVyc3RhbmRpbmcgaXQgIA0KY29ycmVjdGx5LiBIZWxwIG1lIG1ha2Ugc3VyZSB0aGF0IEkg aGF2ZSB0aGlzIHJpZ2h0Lg0KDQpDaXNjbyBhbmQgQUNNRSBhcmUgcGFydCBvZiB0aGUgQVQmVCB0 cnVzdCBkb21haW4gYW5kIGdldCBzaXAgdHJ1bmtpbmcgIA0KZnJvbSBBVCZULiBDaXNjbyBzZW5k cyBhIHZpYSB0aGF0IGhhcyBBQ01FIG9uIHRoZSBhbGlhcyB0byBBVCZULiBUaGVyZSAgDQppcyBu b3RoaW5nIEFUJlQgY2FuIGRvIHRvIHZhbGlkYXRlIHRoaXMuIE5vdyBDaXNjbyBoYXMgaGlqYWNr ZWQgYWxsIG9mICANCkFDTUUncyBjYWxsLiBJZiB0aGUgdHJ1c3QgZG9tYWluIGNvbnNpc3RlZCBv ZiBqdXN0IG9uZSBwYXJ0eSwgd2VsbCBJICANCnNlZSBob3cgdGhpcyBtaWdodCBiZSBzZWN1cmUs IHNvcnQgb2YsIGJ1dCBpdCBzZWVtcyB0byBmYWxsIGFwYXJ0IGFzICANCnRoZSB0cnVzdCBkb21h aW4gZXhwYW5kcy4NCg0KQ3VsbGVuIDx3aXRoIG15IGluZGl2aWR1YWwgY29udHJpYnV0b3IgaGF0 IG9uPg0KDQoNCk9uIFNlcCA5LCAyMDA5LCBhdCA5OjA5ICwgVmlqYXkgSy4gR3VyYmFuaSB3cm90 ZToNCg0KPiBGb2xrczogQmVmb3JlIHRoZSBzdW1tZXIsIHdlIGhhZCByZWxlYXNlZCBhIG5ldw0K PiBUQ1AvU0NUUCBjb25uZWN0aW9uIHJldXNlIGRyYWZ0IGluIHRoZSAobm93IGRlZnVuY3QpIFNJ UA0KPiBXRy4gIFdpdGggdGhlIGZvcm1hdGlvbiBvZiBkaXNwYXRjaCwgd2Ugd2VyZSBhZHZpc2Vk IHRvDQo+IHN1Ym1pdCBpdCB0byBkaXNwYXRjaCBmb3IgYSBkZWNpc2lvbiBvbiB3aGVyZSB0byBo YW5kbGUNCj4gdGhpcyB3b3JrLg0KPg0KPiBFc3NlbnRpYWxseSwgdGhlIGRyYWZ0IGRvY3VtZW50 cyB0aGUgcHJhY3RpY2Ugb2YgcmV1c2luZyBUQ1ANCj4gKGFuZCBTQ1RQKSBjb25uZWN0aW9ucyB0 aGF0IGlzIGVtcGxveWVkIGJ5IHNvbWUgU0lQDQo+IGltcGxlbWVudGF0aW9ucyB0b2RheS4gIFRD UCBhbmQgU0NUUCB0cmFuc3BvcnQgcmV1c2Ugd2VyZQ0KPiBvcmlnaW5hbGx5IGEgcGFydCBvZiB0 aGUgZHJhZnQtaWV0Zi1zaXAtY29ubmVjdC1yZXVzZSBkcmFmdCwNCj4gYnV0IHdlcmUgdGFrZW4g b3V0IGJlZm9yZSB3ZSBwcm9ncmVzc2VkIHRoYXQgZHJhZnQgdG8gdGhlIElFU0cuDQo+DQo+IENh biB3ZSBraW5kbHkgYXNrIHRoZSBkaXNwYXRjaCBXRyB0byByZXZpZXcgYW5kIGNvbW1lbnQgb24N Cj4gdGhlIHRoZSBUQ1AgYW5kIFNDVFAgY29ubmVjdGlvbiByZXVzZSBkcmFmdD8gIEFsbCBjb21t ZW50cw0KPiByZWNlaXZlZCBmcm9tIHRoZSBmaXJzdCBpdGVyYXRpb24gb2YgdGhlIGRyYWZ0IGlu IHRoZSBTSVAgV0cNCj4gaGF2ZSBiZWVuIGR1bHkgYWRkcmVzc2VkIGluIHRoaXMgdmVyc2lvbi4N Cj4NCj4gSXQgd2lsbCBhbHNvIGJlIGhlbHBmdWwgaWYgdGhlIFdHIGFuZCBjaGFpcnMgY291bGQg cHJvdmlkZQ0KPiBzb21lIGd1aWRhbmNlIG9uIGhvdyB0byBtb3ZlIHRoaXMgd29yayBmb3J3YXJk IChpLmUuLA0KPiBBRC1zcG9uc29yZWQgaW5kaXZpZHVhbCBkcmFmdCwgdGFrZSBpdCB0byBzaXBj b3JlLCBldGMuKQ0KPg0KPiBUaGUgZHJhZnQgY2FuIGJlIHJldHJpZXZlZCBmcm9tOg0KPg0KPiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qYWluLWRpc3BhdGNoLXNpcC10cmFuc3Bv cnQtY29ubmVjdGlvbi1yZXVzZS0wMA0KPg0KPiBUaGFuayB5b3UsDQo+DQo+IC0gdmlqYXkNCj4g LS0gDQo+IFZpamF5IEsuIEd1cmJhbmksIEJlbGwgTGFib3JhdG9yaWVzLCBBbGNhdGVsLUx1Y2Vu dA0KPiAxOTYwIEx1Y2VudCBMYW5lLCBSbS4gOUMtNTMzLCBOYXBlcnZpbGxlLCBJbGxpbm9pcyA2 MDU2NiAoVVNBKQ0KPiBFbWFpbDogdmtnQHthbGNhdGVsLWx1Y2VudC5jb20sYmVsbC1sYWJzLmNv bSxhY20ub3JnfQ0KPiBXZWI6ICAgaHR0cDovL2VjdC5iZWxsLWxhYnMuY29tL3doby92a2cvDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3Bh dGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNo QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo DQo=