From sip-bounces@ietf.org Mon Jun 2 13:45:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1E33A6950; Mon, 2 Jun 2008 13:45:02 -0700 (PDT) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 852783A68AF; Mon, 2 Jun 2008 13:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080602204501.852783A68AF@core3.amsl.com> Date: Mon, 2 Jun 2008 13:45:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-media-security-requirements-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Requirements and Analysis of Media Security Management Protocols Author(s) : D. Wing, et al. Filename : draft-ietf-sip-media-security-requirements-07.txt Pages : 47 Date : 2008-06-02 This document describes requirements for a protocol to negotiate a security context for SIP-signaled SRTP media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-media-security-requirements-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-02133046.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jun 2 13:58:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118C73A6947; Mon, 2 Jun 2008 13:58:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419C23A6840 for ; Mon, 2 Jun 2008 13:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=1.050, 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 az4AoKP-wPcl for ; Mon, 2 Jun 2008 13:58:39 -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 72C693A6836 for ; Mon, 2 Jun 2008 13:58:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,578,1204531200"; d="scan'208";a="37876030" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Jun 2008 13:58:41 -0700 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 m52KwfaQ015480 for ; Mon, 2 Jun 2008 13:58:41 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m52KweVO010205 for ; Mon, 2 Jun 2008 20:58:41 GMT From: "Dan Wing" To: References: <20080602204501.852783A68AF@core3.amsl.com> Date: Mon, 2 Jun 2008 13:58:40 -0700 Message-ID: <08f001c8c4f3$6fda8cb0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20080602204501.852783A68AF@core3.amsl.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjE8cTr23d2rfrGSXC9TLuvfkWvCQAASLfA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1602; t=1212440321; x=1213304321; 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:=20draft-ietf-sip-media-security-requirements-07.t xt |Sender:=20; bh=XxB84joNIV5dYYIvn4aDbMYQdE2mJJ/+vCU8rMu72Yk=; b=BQDHriRr/4ZIgrIt33xbxK/gW7eAJF8MhCB+h/IFpt+I3uwTuGHbImAG2D OEcVVyOslaoiqfG0pJSxQ03jH8xyezvdAYJQSiFHqD68y+MSTlhih8JDALY5 tc/8TRuI7YEE5UD2U15/PjS6CS7DHe+2+nOjpA6qrlMWxy2TqSNNM=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Sip] draft-ietf-sip-media-security-requirements-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just posted draft-ietf-sip-media-security-requirements-07.txt which incorporates the text suggested by Eric in and Steffen's change to Eric's text described in . With these changes, we now have: ... 4.9. Certificates The discussion in this section relates to R-CERTS. On the Internet and on some private networks, validating another peer's certificate is often done through a trust anchor -- a list of Certificate Authorities that are trusted. It can be difficult or expensive for a peer to obtain these certificates. In all cases, both parties to the call would need to trust the same trust anchor (i.e., "certificate authority"). For these reasons, it is important that the media plane key management protocol offer a mechanism that allows end-users who have no prior association to authenticate to each other without acquiring credentials from a third party trust point. Note that this does not rule out mechanisms in which servers have certificates and attest to the identities of end-users. ... 5.2. Security Requirements ... R-CERTS: The key management protocol MUST NOT require that end-users obtain credentials (certificates or private keys) from a third- party trust anchor. ... Side-by-side diffs: http://tinyurl.com/3kc85k This closes the open issues with this document and it is now ready to forward to the IESG. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 3 01:13:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC603A6A19; Tue, 3 Jun 2008 01:13:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F41E3A6784 for ; Tue, 3 Jun 2008 01:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.902 X-Spam-Level: X-Spam-Status: No, score=0.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO20zAn7gEhf for ; Tue, 3 Jun 2008 01:13:04 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 71C8A3A68AB for ; Tue, 3 Jun 2008 01:13:00 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so1184484fkq.5 for ; Tue, 03 Jun 2008 01:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=PTrG576a0dePlH+ipHQOq+df/Tu7KLoFFA9HO6PWjT8=; b=tYBz7ESeIGjhZIg7z5ikPFadAlTIwLJb7WVemPfI3CmSBfbFLTS+sssjueBUDYXjQNeiCrqwHl4t9SE0NWCFqv81zk6W+k250RQ0ZryyABWxImyEevnpm993NKJZRB/h85GZn65UpOqBKuN5TBu+4hEFX4gjX4e6DlGnJVmH6Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Gh1yKJoIfZ3MBCfstp9FJo1hhen/Wp7Y1EiazM4LGVjjG1hA6DtDyMmJNQzzZyBjVvEA+C6tXKggK1Wp8ZtC03dW2MlOqB9dAtiIxsqbs5kZLjvz1uq3r6tfixf0/IcEIR4RcBgarao8Q303mTSje/xUpGmFOnrCOS8BA9rcmGo= Received: by 10.82.120.18 with SMTP id s18mr273490buc.82.1212480782693; Tue, 03 Jun 2008 01:13:02 -0700 (PDT) Received: by 10.82.149.18 with HTTP; Tue, 3 Jun 2008 01:13:02 -0700 (PDT) Message-ID: <2374a5fb0806030113v2049961cufbc7a4988bb005a0@mail.gmail.com> Date: Tue, 3 Jun 2008 16:13:02 +0800 From: "=?GB2312?B?y+/TwLni?=" To: sip@ietf.org, "IETF Sipping List" MIME-Version: 1.0 Subject: [Sip] rtp seq and timestamp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1546956562==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1546956562== Content-Type: multipart/alternative; boundary="----=_Part_533_14713905.1212480782684" ------=_Part_533_14713905.1212480782684 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Guys I have a question as following A and B are already connented , A sent a re-invite to B, and the three-way handshake is ok after it, the rtp (A to B)'s seq no is larger than the before and the SSRC is different I think it is ok , but the timestamp is samller than the before I do not know whther it is ok or not can anyone give me some advices Thanks Samman 2008-6-3 -- msn:yongguangsun@hotmail.com ------=_Part_533_14713905.1212480782684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Guys
 
   I have a question as following
 
A and B are already connented , A sent a re-invite to B, and the three-way handshake  is ok
after it, the rtp (A to B)'s seq no is larger than the before  and the SSRC is different I think it is ok , but the   timestamp is samller than
the before I do not know whther it is ok or not
 
can anyone give me some advices
 
Thanks
 
Samman
 
------=_Part_533_14713905.1212480782684-- --===============1546956562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1546956562==-- From siozzynv@nai.com Tue Jun 3 03:41:32 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1409A3A6AC0 for ; Tue, 3 Jun 2008 03:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.307 X-Spam-Level: X-Spam-Status: No, score=-25.307 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, SUBJ_ALL_CAPS=2.077, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, 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 Hif0qe8KZ1r1 for ; Tue, 3 Jun 2008 03:41:32 -0700 (PDT) Received: from ppp-124-120-97-60.revip2.asianet.co.th (ppp-124-120-97-60.revip2.asianet.co.th [124.120.97.60]) by core3.amsl.com (Postfix) with SMTP id 132DC3A6988 for ; Tue, 3 Jun 2008 03:40:15 -0700 (PDT) Message-Id: <20080603124016.2137.qmail@ppp-124-120-97-60.revip2.asianet.co.th> To: Subject: RE: SALE 89% OFF From: VIAGRA INC MIME-Version: 1.0 Content-Type: text/html Date: Tue, 3 Jun 2008 03:40:15 -0700 (PDT)
Click Here!

©2007 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From sip-bounces@ietf.org Tue Jun 3 23:50:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3024B3A69BD; Tue, 3 Jun 2008 23:50:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525B53A6AB5; Tue, 3 Jun 2008 23:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+gZ3W3IPk4Y; Tue, 3 Jun 2008 23:50:17 -0700 (PDT) Received: from mail.alcatel-sbell.com.cn (cnrelay03.alcatel-sbell.com.cn [211.144.215.19]) by core3.amsl.com (Postfix) with ESMTP id 0776A3A681B; Tue, 3 Jun 2008 23:50:16 -0700 (PDT) Received: from cnshgsbhs01.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id m546n3da032553; Wed, 4 Jun 2008 14:49:09 +0800 Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.174]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 4 Jun 2008 14:50:09 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 14:50:08 +0800 Message-ID: <689BFA4B1AF50745893A3DE0F99673A84B3B79@CNSHGSMBS01.ad4.ad.alcatel.com> In-Reply-To: <2374a5fb0806030113v2049961cufbc7a4988bb005a0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] rtp seq and timestamp Thread-Index: AcjFUxA+C3XKXS+uRcamQmJNsPLnKQAuXi3Q References: <2374a5fb0806030113v2049961cufbc7a4988bb005a0@mail.gmail.com> From: "CHEN JIANBIN" To: =?gb2312?B?y+/TwLni?= , , "IETF Sipping List" X-OriginalArrivalTime: 04 Jun 2008 06:50:09.0757 (UTC) FILETIME=[3B0CE8D0:01C8C60F] X-imss-version: 2.050 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn Subject: Re: [Sip] rtp seq and timestamp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1173835386==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1173835386== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C60F.3AD5D0AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C60F.3AD5D0AF Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Samman, =20 According to RFC3550, SSRC means Synchronization Source. "All packets from a synchronization source form part of the same timing and sequence number space, so a receiver groups packets by synchronization source for playback. " =20 For the SSRC is changed as you mentioned, the "seq no" and "timestamp" = has no relationship with the previous one. Different SSRC means different timing and sequence number space. It has no meaning to compare seq no and timestamp with different SSRC.=20 =20 BR Ben ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = =CB=EF=D3=C0=B9=E2 Sent: 2008=C4=EA6=D4=C23=C8=D5 16:13 To: sip@ietf.org; IETF Sipping List Subject: [Sip] rtp seq and timestamp Hi Guys =20 I have a question as following =20 A and B are already connented , A sent a re-invite to B, and the = three-way handshake is ok=20 after it, the rtp (A to B)'s seq no is larger than the before and the = SSRC is different I think it is ok , but the timestamp is samller than = the before I do not know whther it is ok or not=20 =20 can anyone give me some advices =20 Thanks =20 Samman =20 2008-6-3 --=20 msn:yongguangsun@hotmail.com =20 ------_=_NextPart_001_01C8C60F.3AD5D0AF Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Samman,
 
According to RFC3550, SSRC means = Synchronization=20 Source.
     "All packets from a = synchronization=20 source form part of the same
      timing = and=20 sequence number space, so a receiver groups packets=20 by
      synchronization source for=20 playback. "
 
For the SSRC is changed as you mentioned, the "seq no" = and=20 "timestamp" has no relationship with the previous = one.
Different SSRC means different timing and sequence = number=20 space.
It has no meaning to compare seq no and = timestamp with=20 different SSRC. 
 
BR
Ben
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of = =CB=EF=D3=C0=B9=E2
Sent: 2008=C4=EA6=D4=C23=C8=D5=20 16:13
To: sip@ietf.org; IETF Sipping List
Subject: = [Sip] rtp=20 seq and timestamp

Hi Guys
 
   I have a question as following
 
A and B are already connented , A sent a re-invite to = B, and the=20 three-way handshake  is ok
after it, the rtp (A to B)'s seq no is larger than = the=20 before  and the SSRC is different I think it is ok , but the=20   timestamp is samller than
the before I do not know whther it is ok or not
 
can anyone give me some advices
 
Thanks
 
Samman
 
2008-6-3

--
msn:yongguangsun@hotmail.c= om=20
------_=_NextPart_001_01C8C60F.3AD5D0AF-- --===============1173835386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1173835386==-- From sip-bounces@ietf.org Wed Jun 4 02:51:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BCC3A6C63; Wed, 4 Jun 2008 02:51:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B442A3A695F for ; Wed, 4 Jun 2008 02:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 5TE+jMRoBDvZ for ; Wed, 4 Jun 2008 02:51:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 2A5793A6C85 for ; Wed, 4 Jun 2008 02:49:11 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m549mxKC013985 for ; Wed, 4 Jun 2008 04:49:14 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 04:48:26 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 11:48:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 11:48:23 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1Cg References: From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 04 Jun 2008 09:48:23.0679 (UTC) FILETIME=[211FE8F0:01C8C628] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) This has been raised in the SIP group a couple of times, and we have not yet gained an idea of whether to proceed with it in the SIP WG or not. There have been a couple of technical comments raised in the past from the security experts; my understanding is that these have now been clarified. I believe in the past there has been an interested community that says this is useful. It has also been clarified that 3GPP would like to use it in their specifications. So could I ask the WG to look at this document, and formally to indicate whether they believe some work with this scope should be progressed as a SIP WG item. http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-02.txt So if you support it please indicate to the SIP WG chairs. If you have technical concerns (i.e. it should not proceed because it is technically flawed beyond fixing) then please ideally mail the list, although the SIP WG chairs will also accept input. Responses please in 1 calendar week from this date. Regards Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Stuart Hoggan Sent: Friday, May 02, 2008 5:15 PM To: sip@ietf.org Subject: [Sip] draft-dotson-sip-mutual-auth-02 Folks, Based on the feedback received in Philadelphia, we have updated draft-dotson-sip-mutual-auth. The changes clarify the usage of the Proxy-Authentication-Info header, including support for multiple values. Any further comments or suggestions will be appreciated. It would also be nice to obtain WG feedback on pursuing this I-D as a WG document. Regards, Stuart _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 03:11:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4450E3A6C77; Wed, 4 Jun 2008 03:11:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5DD3A6B83 for ; Wed, 4 Jun 2008 03:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[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 lpDW6s9-1WFQ for ; Wed, 4 Jun 2008 03:10:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4E5E93A6C8B for ; Wed, 4 Jun 2008 03:10:56 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7D7B320B0D; Wed, 4 Jun 2008 12:10:58 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-03-48466a3280c5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 594A1209F2; Wed, 4 Jun 2008 12:10:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 12:10:58 +0200 Received: from emyklmw102.eapac.ericsson.se ([150.236.92.102]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 12:10:57 +0200 Received: from ecnbjmw513.eapac.ericsson.se ([150.236.34.26]) by emyklmw102.eapac.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 18:10:15 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 18:10:13 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What is the port number in "Invite" request-line? Thanks Thread-Index: Aci7y8Ccu2ENUpcER8SVd+I4biihjwAHYouwAABEjdACjSM50A== References: From: "Yuantao Zhang" To: , X-OriginalArrivalTime: 04 Jun 2008 10:10:15.0132 (UTC) FILETIME=[2ECFC1C0:01C8C62B] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0143964206==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0143964206== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C62B.2DAA9B9A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C62B.2DAA9B9A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all =20 INVITE sip:bob@biloxi.com SIP/2.0:5555 INVITE sip:bob@biloxi.com SIP/2.0 =20 Above are 2 "Invite" request-line examples. In example one, it indicates a port number, 5555. What does the port number mean?=20 =20 Is it the port number of SIP proxy? Why we include port number here? The SIP proxy(biloxi.com) application layer who receives this "Invite" should receive this via port 5555 from lowe layer(UDP). Therefore, The SIP proxy(biloxi.com) application layer already know the port is 5555. Actualy, the SIP proxy application layer keeps listening port 5555.=20 =20 The second "Invite" request-line example is from RFC3261 and does not include port number. Can I say the port number is useless? So why example one includes a useless part in "Invite" request-line URL?=20 =20 Or is the port number is which the UAS is listening to? How the UAC knows it is 5555 if so?=20 =20 Any standard on this port number issue? Thanks.=20 =20 Best regards Steven ------_=_NextPart_001_01C8C62B.2DAA9B9A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MUST 200 OK contain SDP? Thanks

Dear = all

 

INVITE sip:bob@biloxi.com = SIP/2.0:5555

INVITE sip:bob@biloxi.com = SIP/2.0

 

Above are 2 “Invite” = request-line examples. In example one, it indicates a port number, 5555. What does = the port number mean?

 

Is it the port number of SIP proxy? = Why we include port number here? The SIP proxy(biloxi.com) application layer = who receives this "Invite" should receive this via port 5555 from = lowe layer(UDP). Therefore, The SIP proxy(biloxi.com) application layer = already know the port is 5555. Actualy, the SIP proxy application layer keeps = listening port 5555.

 

The second “Invite” = request-line example is from RFC3261 and does not include port number. Can I say the = port number is useless? So why example one includes a useless part in “Invite” request-line URL?

 

Or is the port number is which the = UAS is listening to? How the UAC knows it is 5555 if so? =

 

Any standard on this port number = issue? Thanks.

 

Best = regards

Steven

------_=_NextPart_001_01C8C62B.2DAA9B9A-- --===============0143964206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0143964206==-- From sip-bounces@ietf.org Wed Jun 4 03:23:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CF13A6923; Wed, 4 Jun 2008 03:23:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B387C3A6801 for ; Wed, 4 Jun 2008 03:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 b5Sv-TWdnR6q for ; Wed, 4 Jun 2008 03:23:39 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.119.2.190]) by core3.amsl.com (Postfix) with ESMTP id BE2613A6923 for ; Wed, 4 Jun 2008 03:23:37 -0700 (PDT) Received: from rly30f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly30f.srv.mailcontrol.com (MailControl) with ESMTP id m54ANWGn009446 for ; Wed, 4 Jun 2008 11:23:34 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly30f.srv.mailcontrol.com (MailControl) id m54AMho9005220 for sip@ietf.org; Wed, 4 Jun 2008 11:22:43 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly30f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id m54AM87O002796; Wed, 04 Jun 2008 11:22:43 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 11:24:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 11:22:26 +0100 Message-ID: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What is the port number in "Invite" request-line? Thanks Thread-Index: Aci7y8Ccu2ENUpcER8SVd+I4biihjwAHYouwAABEjdACjSM50AADOkAw From: "Attila Sipos" To: "Yuantao Zhang" , , X-OriginalArrivalTime: 04 Jun 2008 10:24:00.0504 (UTC) FILETIME=[1AC58780:01C8C62D] X-Scanned-By: MailControl A-08-50-03 (www.mailcontrol.com) on 10.70.1.140 Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1808765677==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1808765677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C62D.1515E203" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C62D.1515E203 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 It is possible to have two instances of a UA (for example) on one unit. So using the port is theoretically one way to differentiate between instances. =20 It's not useless. If you get a Contact header with a port then you have to send to that port (discounting NAT traversal scenarios) otherwise everything will break. =20 >>Or is the port number is which the UAS is listening to? How the UAC knows it is 5555 if so?=20 =20 A UAC might not know but a proxy/registrar might - for example if a user was registered with the Contact as port 5555, then requests to that user will get forwarded to port 5555. Another user using, for example, port 5556 will register using a Contact with 5556 and so will receive requests to that port. =20 Regards, Attila =20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Yuantao Zhang Sent: 04 June 2008 11:10 To: sip@ietf.org; discussion@sipforum.org Subject: [Sip] What is the port number in "Invite" request-line? Thanks Dear all INVITE sip:bob@biloxi.com SIP/2.0:5555 INVITE sip:bob@biloxi.com SIP/2.0 Above are 2 "Invite" request-line examples. In example one, it indicates a port number, 5555. What does the port number mean?=20 Is it the port number of SIP proxy? Why we include port number here? The SIP proxy(biloxi.com) application layer who receives this "Invite" should receive this via port 5555 from lowe layer(UDP). Therefore, The SIP proxy(biloxi.com) application layer already know the port is 5555. Actualy, the SIP proxy application layer keeps listening port 5555.=20 The second "Invite" request-line example is from RFC3261 and does not include port number. Can I say the port number is useless? So why example one includes a useless part in "Invite" request-line URL?=20 Or is the port number is which the UAS is listening to? How the UAC knows it is 5555 if so?=20 Any standard on this port number issue? Thanks.=20 Best regards Steven ------_=_NextPart_001_01C8C62D.1515E203 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable MUST 200 = OK contain SDP? Thanks
 
It is possible to have two instances of a UA (for = example)=20 on one unit.

So using the port is = ;theoretically one way to=20 differentiate between=20 instances.
 
It's not useless.  If you get a Contact heade= r=20 with a port then you have
to send to that port (discounting NAT traversal sc= enarios)=20 otherwise everything will break.
 
>>Or is the port number is which th= e UAS=20 is listening to? How the UAC knows it is 5555 if so? <= /DIV>
 
A UAC might not know but a proxy/registrar might -= for=20 example if a user was registered with
the Contact as port 5555, then requests to that us= er will=20 get forwarded to port 5555.
Another user using, for example, port 5556 wi= ll=20 register using a Contact with 5556
and so will receive requests to that=20 port.
 
Regards,
<= SPAN=20 class=3D390501410-04062008>

Attila
 
 
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Yuantao Zhang
Sent:= =20 04 June 2008 11:10
To: sip@ietf.org;=20 discussion@sipforum.org
Subject: [Sip] What is the port number in= =20 "Invite" request-line? Thanks

Dear=20 all

INVITE=20 sip:bob@biloxi.com SIP/2.0:5555

INVITE=20 sip:bob@biloxi.com SIP/2.0

Above are 2 R= 20;Invite”=20 request-line examples. In example one, it indicates a port number, 5555. Wh= at=20 does the port number mean?

Is it the port n= umber=20 of SIP proxy? Why we include port number here? The SIP proxy(biloxi.com)=20 application layer who receives this "Invite" should receive this via port 5= 555=20 from lowe layer(UDP). Therefore, The SIP proxy(biloxi.com) application laye= r=20 already know the port is 5555. Actualy, the SIP proxy application layer kee= ps=20 listening port 5555.

The second ̶= 0;Invite”=20 request-line example is from RFC3261 and does not include port number. Can = I say=20 the port number is useless? So why example one includes a useless part in= =20 “Invite” request-line URL? =

Or is the port n= umber=20 is which the UAS is listening to? How the UAC knows it is 5555 if so?=20

Any standard on = this=20 port number issue? Thanks.

Best=20 regards

Steven



.

------_=_NextPart_001_01C8C62D.1515E203-- --===============1808765677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1808765677==-- From sip-bounces@ietf.org Wed Jun 4 05:46:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80913A6CA9; Wed, 4 Jun 2008 05:46:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2664F28C128 for ; Wed, 4 Jun 2008 05:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 mHiwcjLAOrxo for ; Wed, 4 Jun 2008 05:46:15 -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 879DF3A6B12 for ; Wed, 4 Jun 2008 05:43:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,589,1204520400"; d="scan'208";a="10076203" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Jun 2008 08:43:59 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m54ChxxB008956; Wed, 4 Jun 2008 08:43:59 -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.13.8) with ESMTP id m54ChxMx005351; Wed, 4 Jun 2008 12:43:59 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.1830); Wed, 4 Jun 2008 08:43:59 -0400 Received: from [10.86.240.74] ([10.86.240.74]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 08:43:59 -0400 Message-ID: <48468E37.40603@cisco.com> Date: Wed, 04 Jun 2008 08:44:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Attila Sipos References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> In-Reply-To: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> X-OriginalArrivalTime: 04 Jun 2008 12:43:59.0515 (UTC) FILETIME=[A8F8E6B0:01C8C640] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1611; t=1212583439; x=1213447439; 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[Sip]=20What=20is=20the=20port=20number =20in=20=22Invite=22=20request-line?=20Thanks |Sender:=20 |To:=20Attila=20Sipos=20; bh=asIGq3dHYfRwMsFQMgj+LTImjLA9zB0tj31x/RSV5d0=; b=QwDUOUMyN63PPH2wtztYJryxD5r5p3FSZ1KQiQ0ko45m9CLwm5/JhigFdn oFMEKfj8/56HM2VG2vyuhGW7El6NyQNNWWyQFHiNQmQk9VfzzuK5C2p/0jh9 kiasDWzLwG; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, discussion@sipforum.org, Yuantao Zhang Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Attila Sipos wrote: > > It is possible to have two instances of a UA (for example) on one unit. > > So using the port is theoretically one way to differentiate between > instances. > > It's not useless. If you get a Contact header with a port then you have > to send to that port (discounting NAT traversal scenarios) otherwise > everything will break. > >> >Or is the port number is which the UAS is listening to? How the UAC > knows it is 5555 if so? > > A UAC might not know but a proxy/registrar might - for example if a user > was registered with > the Contact as port 5555, then requests to that user will get forwarded > to port 5555. > Another user using, for example, port 5556 will register using a Contact > with 5556 > and so will receive requests to that port. Right. This illustrates a good point: In general a UAC should not be expected to know "what port a UAS listens on". All A UAC should be doing is sending requests to URIs that it has been given. If the URI it is given contains a port number, then it should honor that. This gets bent out of shape a bit by numeric dialing, where the UAC is only given a dial string and must derive a URI from it. The "standard" way to do this is via ENUM, where effectively the numeric address is looked up in a DB to obtain a URI. In that case again the UAC has been "given" the URI, which may have a port or not. In the non-standard but common case where the UAC *constructs* a URI from a dial string, the UAC must still be *told* what to use for the remainder of the URI. Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 11:08:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1075A3A6CEC; Wed, 4 Jun 2008 11:08:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1153A6CF3 for ; Wed, 4 Jun 2008 11:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_WANT=2.3, 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 cHdRrIfWM5ER for ; Wed, 4 Jun 2008 11:08:07 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id C962B3A6CEC for ; Wed, 4 Jun 2008 11:08:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m54I85S09722 for ; Wed, 4 Jun 2008 18:08:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 13:07:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF172DB7E4@zrc2hxm0.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgADaBcvA= References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I do not believe that this document provide enought justification of what is the problem that is being attempted to be solved, and why it isn't already solved by existing mechanism that are widely implemented (such as TLS). Section 9 (Security Considerations) I believe touches on it a little bit, but it seems both incomplete and out of place. The problem statement needs to be brough forward in the document (say to section 3 or a new section). The scope of applicability of the solution should also be described up-front). I wan't to clarfiy I'm not necessarily against this: I just want the justification to be clearer. The onus should be on this document to clearly demonstrate why what we currently have is broken. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Wednesday, June 04, 2008 02:48 > To: sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > (As SIP WG cochair) > > This has been raised in the SIP group a couple of times, and > we have not yet gained an idea of whether to proceed with it > in the SIP WG or not. > > There have been a couple of technical comments raised in the > past from the security experts; my understanding is that > these have now been clarified. > > I believe in the past there has been an interested community > that says this is useful. It has also been clarified that > 3GPP would like to use it in their specifications. > > So could I ask the WG to look at this document, and formally > to indicate whether they believe some work with this scope > should be progressed as a SIP WG item. > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > th-02.txt > > So if you support it please indicate to the SIP WG chairs. > > If you have technical concerns (i.e. it should not proceed > because it is technically flawed beyond fixing) then please > ideally mail the list, although the SIP WG chairs will also > accept input. > > Responses please in 1 calendar week from this date. > > Regards > > Keith > > > ________________________________ > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of Stuart Hoggan > Sent: Friday, May 02, 2008 5:15 PM > To: sip@ietf.org > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > > > Folks, > > > > Based on the feedback received in Philadelphia, we have > updated draft-dotson-sip-mutual-auth. The changes clarify the > usage of the Proxy-Authentication-Info header, including > support for multiple values. > > > > > Any further comments or suggestions will be > appreciated. It would also be nice to obtain WG feedback on > pursuing this I-D as a WG document. > > > > Regards, > > Stuart > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 11:33:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D980D3A6CFB; Wed, 4 Jun 2008 11:33:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0B63A6D04 for ; Wed, 4 Jun 2008 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.837 X-Spam-Level: * X-Spam-Status: No, score=1.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MANGLED_WANT=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUiDyEIE2r7q for ; Wed, 4 Jun 2008 11:33:26 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A86493A6CFA for ; Wed, 4 Jun 2008 11:33:26 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m54IXT9V017803; Wed, 4 Jun 2008 12:33:29 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 4 Jun 2008 12:33:29 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 12:33:26 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601215BDB@srvxchg3.cablelabs.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF172DB7E4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgADaBcvAAARD1EA== References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF172DB7E4@zrc2hxm0.corp.nortel.com> From: "Sumanth Channabasappa" To: "Francois Audet" , "DRAGE, Keith (Keith)" , X-Approved: ondar Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois, Thanks for your thoughts. We can certainly add more details if it is unclear. As a clarification, I don't think we are saying that the current mechanism is necessarily broken (which is why it is not an essential correction, as discussed earlier in the WG). However, we want to allow for the use of this header in deployments that use Digest (with or without TLS; e.g., when integrity protection is provided by other means) and can benefit from its advantages (mutual auth, nextnonce). - S -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Francois Audet Sent: Wednesday, June 04, 2008 12:08 PM To: DRAGE, Keith (Keith); sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 I do not believe that this document provide enought justification of what is the problem that is being attempted to be solved, and why it isn't already solved by existing mechanism that are widely implemented (such as TLS). Section 9 (Security Considerations) I believe touches on it a little bit, but it seems both incomplete and out of place. The problem statement needs to be brough forward in the document (say to section 3 or a new section). The scope of applicability of the solution should also be described up-front). I wan't to clarfiy I'm not necessarily against this: I just want the justification to be clearer. The onus should be on this document to clearly demonstrate why what we currently have is broken. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Wednesday, June 04, 2008 02:48 > To: sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > (As SIP WG cochair) > > This has been raised in the SIP group a couple of times, and > we have not yet gained an idea of whether to proceed with it > in the SIP WG or not. > > There have been a couple of technical comments raised in the > past from the security experts; my understanding is that > these have now been clarified. > > I believe in the past there has been an interested community > that says this is useful. It has also been clarified that > 3GPP would like to use it in their specifications. > > So could I ask the WG to look at this document, and formally > to indicate whether they believe some work with this scope > should be progressed as a SIP WG item. > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > th-02.txt > > So if you support it please indicate to the SIP WG chairs. > > If you have technical concerns (i.e. it should not proceed > because it is technically flawed beyond fixing) then please > ideally mail the list, although the SIP WG chairs will also > accept input. > > Responses please in 1 calendar week from this date. > > Regards > > Keith > > > ________________________________ > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of Stuart Hoggan > Sent: Friday, May 02, 2008 5:15 PM > To: sip@ietf.org > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > > > Folks, > > > > Based on the feedback received in Philadelphia, we have > updated draft-dotson-sip-mutual-auth. The changes clarify the > usage of the Proxy-Authentication-Info header, including > support for multiple values. > > > > > Any further comments or suggestions will be > appreciated. It would also be nice to obtain WG feedback on > pursuing this I-D as a WG document. > > > > Regards, > > Stuart > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 11:36:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7712B28C244; Wed, 4 Jun 2008 11:36:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876D728C23E for ; Wed, 4 Jun 2008 11:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 To5tmAfcULce for ; Wed, 4 Jun 2008 11:36:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5F8CD28C1EA for ; Wed, 4 Jun 2008 11:35:39 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m54IZHtY004638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jun 2008 13:35:19 -0500 Message-Id: <187B015D-0876-4E07-9339-9C8ECB9CCD3C@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 4 Jun 2008 13:35:12 -0500 X-Mailer: Apple Mail (2.924) Cc: Cullen Jennings , Rohan Mahy , Francois Audet , Keith Drage Subject: [Sip] Conclusion of WGLC for Outbound: draft-ietf-sip-outbound-14 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The latest Outbound draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-14.txt supposedly accounts for all issues raised in the rather lengthy (it started July 9, 2007) working group last call of the draft. I expect to be writing this up and sending it to the IESG shortly (as in the end of this week), so if you have any last comments, get them in now. -- Dean (as chair and assigned shepherd of this wayward sheep) _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 12:04:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A57328C254; Wed, 4 Jun 2008 12:04:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D58128C234 for ; Wed, 4 Jun 2008 12:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.305 X-Spam-Level: X-Spam-Status: No, score=-5.305 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, MANGLED_WANT=2.3, 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 woj4kg3Qxv41 for ; Wed, 4 Jun 2008 12:04:11 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A635828C254 for ; Wed, 4 Jun 2008 12:02:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m54J2RS16807; Wed, 4 Jun 2008 19:02:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 14:01:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF172DB9E1@zrc2hxm0.corp.nortel.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601215BDB@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgADaBcvAAARD1EAABJiQQ References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF172DB7E4@zrc2hxm0.corp.nortel.com> <9AAEDF491EF7CA48AB587781B8F5D7C601215BDB@srvxchg3.cablelabs.com> From: "Francois Audet" To: "Sumanth Channabasappa" , "DRAGE, Keith (Keith)" , Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ok, thanks. I would like the begining of the document (say section 3, or a Scope, Applicability statement or similar section) to explains when and why this is useful. The purpose is really for an implementor to be able by reading this section to be in a position to determine if it's somthing that should he needs to worry about or not. So, say if I'm developping a UA for an IMS environment versus an Enteprise SIP UA, or an Enteprise SIP access to a service provider network, I'll know if this applies to me or not. Cheers. > -----Original Message----- > From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] > Sent: Wednesday, June 04, 2008 11:33 > To: Audet, Francois (SC100:3055); DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > > Francois, > > Thanks for your thoughts. We can certainly add more details > if it is unclear. > > As a clarification, I don't think we are saying that the > current mechanism is necessarily broken (which is why it is > not an essential correction, as discussed earlier in the WG). > However, we want to allow for the use of this header in > deployments that use Digest (with or without TLS; e.g., when > integrity protection is provided by other means) and can > benefit from its advantages (mutual auth, nextnonce). > > - S > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Wednesday, June 04, 2008 12:08 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > I do not believe that this document provide enought > justification of what is the problem that is being attempted > to be solved, and why it isn't already solved by existing > mechanism that are widely implemented (such as TLS). > > Section 9 (Security Considerations) I believe touches on it a > little bit, but it seems both incomplete and out of place. > > The problem statement needs to be brough forward in the > document (say to section 3 or a new section). The scope of > applicability of the solution should also be described up-front). > > I wan't to clarfiy I'm not necessarily against this: I just > want the justification to be clearer. The onus should be on > this document to clearly demonstrate why what we currently > have is broken. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 04, 2008 02:48 > > To: sip@ietf.org > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > > > (As SIP WG cochair) > > > > This has been raised in the SIP group a couple of times, > and we have > > not yet gained an idea of whether to proceed with it in the > SIP WG or > > not. > > > > There have been a couple of technical comments raised in > the past from > > the security experts; my understanding is that these have now been > > clarified. > > > > I believe in the past there has been an interested > community that says > > this is useful. It has also been clarified that 3GPP would > like to use > > it in their specifications. > > > > So could I ask the WG to look at this document, and formally to > > indicate whether they believe some work with this scope should be > > progressed as a SIP WG item. > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > > th-02.txt > > > > So if you support it please indicate to the SIP WG chairs. > > > > If you have technical concerns (i.e. it should not proceed > because it > > is technically flawed beyond fixing) then please ideally mail the > > list, although the SIP WG chairs will also accept input. > > > > Responses please in 1 calendar week from this date. > > > > Regards > > > > Keith > > > > > > ________________________________ > > > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On Behalf Of Stuart Hoggan > > Sent: Friday, May 02, 2008 5:15 PM > > To: sip@ietf.org > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > > > > > > > Folks, > > > > > > > > Based on the feedback received in Philadelphia, we have updated > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the > > Proxy-Authentication-Info header, including support for multiple > > values. > > > > > > > > > > Any further comments or suggestions will be > appreciated. It would > > also be nice to obtain WG feedback on pursuing this I-D as a WG > > document. > > > > > > > > Regards, > > > > Stuart > > > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 12:42:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E8828C231; Wed, 4 Jun 2008 12:42:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC82128C231 for ; Wed, 4 Jun 2008 12:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.837 X-Spam-Level: * X-Spam-Status: No, score=1.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MANGLED_WANT=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A-LBHZKA6-w for ; Wed, 4 Jun 2008 12:42:44 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 304DE3A6B31 for ; Wed, 4 Jun 2008 12:42:44 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m54JglGd022856; Wed, 4 Jun 2008 13:42:47 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 4 Jun 2008 13:42:47 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 13:42:47 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601215BEE@srvxchg3.cablelabs.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF172DB9E1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgADaBcvAAARD1EAABJiQQAAEcpDA= References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF172DB7E4@zrc2hxm0.corp.nortel.com> <9AAEDF491EF7CA48AB587781B8F5D7C601215BDB@srvxchg3.cablelabs.com> <1ECE0EB50388174790F9694F77522CCF172DB9E1@zrc2hxm0.corp.nortel.com> From: "Sumanth Channabasappa" To: "Francois Audet" , "DRAGE, Keith (Keith)" , X-Approved: ondar Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sounds fair, we can provide additional information in a revision (probably when the WG decides to pursue this effort?). Thanks! - S -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Wednesday, June 04, 2008 1:02 PM To: Sumanth Channabasappa; DRAGE, Keith (Keith); sip@ietf.org Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 Ok, thanks. I would like the begining of the document (say section 3, or a Scope, Applicability statement or similar section) to explains when and why this is useful. The purpose is really for an implementor to be able by reading this section to be in a position to determine if it's somthing that should he needs to worry about or not. So, say if I'm developping a UA for an IMS environment versus an Enteprise SIP UA, or an Enteprise SIP access to a service provider network, I'll know if this applies to me or not. Cheers. > -----Original Message----- > From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] > Sent: Wednesday, June 04, 2008 11:33 > To: Audet, Francois (SC100:3055); DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > > Francois, > > Thanks for your thoughts. We can certainly add more details > if it is unclear. > > As a clarification, I don't think we are saying that the > current mechanism is necessarily broken (which is why it is > not an essential correction, as discussed earlier in the WG). > However, we want to allow for the use of this header in > deployments that use Digest (with or without TLS; e.g., when > integrity protection is provided by other means) and can > benefit from its advantages (mutual auth, nextnonce). > > - S > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Wednesday, June 04, 2008 12:08 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > I do not believe that this document provide enought > justification of what is the problem that is being attempted > to be solved, and why it isn't already solved by existing > mechanism that are widely implemented (such as TLS). > > Section 9 (Security Considerations) I believe touches on it a > little bit, but it seems both incomplete and out of place. > > The problem statement needs to be brough forward in the > document (say to section 3 or a new section). The scope of > applicability of the solution should also be described up-front). > > I wan't to clarfiy I'm not necessarily against this: I just > want the justification to be clearer. The onus should be on > this document to clearly demonstrate why what we currently > have is broken. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 04, 2008 02:48 > > To: sip@ietf.org > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > > > (As SIP WG cochair) > > > > This has been raised in the SIP group a couple of times, > and we have > > not yet gained an idea of whether to proceed with it in the > SIP WG or > > not. > > > > There have been a couple of technical comments raised in > the past from > > the security experts; my understanding is that these have now been > > clarified. > > > > I believe in the past there has been an interested > community that says > > this is useful. It has also been clarified that 3GPP would > like to use > > it in their specifications. > > > > So could I ask the WG to look at this document, and formally to > > indicate whether they believe some work with this scope should be > > progressed as a SIP WG item. > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > > th-02.txt > > > > So if you support it please indicate to the SIP WG chairs. > > > > If you have technical concerns (i.e. it should not proceed > because it > > is technically flawed beyond fixing) then please ideally mail the > > list, although the SIP WG chairs will also accept input. > > > > Responses please in 1 calendar week from this date. > > > > Regards > > > > Keith > > > > > > ________________________________ > > > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On Behalf Of Stuart Hoggan > > Sent: Friday, May 02, 2008 5:15 PM > > To: sip@ietf.org > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > > > > > > > Folks, > > > > > > > > Based on the feedback received in Philadelphia, we have updated > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the > > Proxy-Authentication-Info header, including support for multiple > > values. > > > > > > > > > > Any further comments or suggestions will be > appreciated. It would > > also be nice to obtain WG feedback on pursuing this I-D as a WG > > document. > > > > > > > > Regards, > > > > Stuart > > > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 22:51:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAA53A6B7C; Wed, 4 Jun 2008 22:51:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38C73A6B78 for ; Wed, 4 Jun 2008 22:51:15 -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 mj+t2iOhlfuV for ; Wed, 4 Jun 2008 22:51:14 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id AADC03A6B7C for ; Wed, 4 Jun 2008 22:51:14 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA06.westchester.pa.mail.comcast.net with comcast id a5pE1Z0010QuhwU5600600; Thu, 05 Jun 2008 05:51:18 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA02.westchester.pa.mail.comcast.net with comcast id a5rH1Z00202AVH03N00000; Thu, 05 Jun 2008 05:51:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=VD5dLLCCbDMA:10 a=64JZM-cx2HsA:10 a=idmpyZOY_ykf0O8pEoEA:9 a=ZSfR5o3IGyZU5dkHuPriO69G_U8A:4 a=f7GxY0FH8QIA:10 a=kM3d1GINNy4A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m555pHPO006999; Thu, 5 Jun 2008 01:51:17 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m555pH05006995; Thu, 5 Jun 2008 01:51:17 -0400 Date: Thu, 5 Jun 2008 01:51:17 -0400 Message-Id: <200806050551.m555pH05006995@dragon.ariadne.com> To: sip@ietf.org, discussion@sipforum.org From: Dale.Worley@comcast.net In-reply-to: (yuantao.zhang@ericsson.com) References: Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Yuantao Zhang" INVITE sip:bob@biloxi.com SIP/2.0:5555 This is syntactically invalid. Do you mean INVITE sip:bob@biloxi.com:5555 SIP/2.0 ? Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 4 23:50:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005663A6957; Wed, 4 Jun 2008 23:50:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4762E3A6957 for ; Wed, 4 Jun 2008 23:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_WANT=2.3, 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 AJElQz3r-0s6 for ; Wed, 4 Jun 2008 23:50:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 799893A6802 for ; Wed, 4 Jun 2008 23:50:13 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 85FFC207B0; Thu, 5 Jun 2008 08:50:17 +0200 (CEST) X-AuditID: c1b4fb3e-ad196bb000004ec0-f2-48478ca9f522 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F31B203AB; Thu, 5 Jun 2008 08:50:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 08:50:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 08:50:14 +0200 Message-ID: In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601215BEE@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgADaBcvAAARD1EAABJiQQAAEcpDAAF78DYA== References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF172DB7E4@zrc2hxm0.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C601215BDB@srvxchg3.cablelabs.com><1ECE0EB50388174790F9694F77522CCF172DB9E1@zrc2hxm0.corp.nortel.com> <9AAEDF491EF7CA48AB587781B8F5D7C601215BEE@srvxchg3.cablelabs.com> From: "Christer Holmberg" To: "Sumanth Channabasappa" , "Francois Audet" , "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 05 Jun 2008 06:50:17.0075 (UTC) FILETIME=[69D34C30:01C8C6D8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I think it would be good to provide a revision, with the addtional informat= ion, asap. It will be easier to make a decission whether to move the draft = forward, and it will hopefully reduce the what-is-this-needed-for type of q= uestions. Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Suman= th Channabasappa Sent: 4. kes=E4kuuta 2008 22:43 To: Francois Audet; DRAGE, Keith (Keith); sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 Sounds fair, we can provide additional information in a revision (probably = when the WG decides to pursue this effort?). Thanks! - S -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Wednesday, June 04, 2008 1:02 PM To: Sumanth Channabasappa; DRAGE, Keith (Keith); sip@ietf.org Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 Ok, thanks. I would like the begining of the document (say section 3, or a Scope, Appli= cability statement or similar section) to explains when and why this is use= ful. The purpose is really for an implementor to be able by reading this section= to be in a position to determine if it's somthing that should he needs to = worry about or not. = So, say if I'm developping a UA for an IMS environment versus an Enteprise = SIP UA, or an Enteprise SIP access to a service provider network, I'll know= if this applies to me or not. Cheers. = > -----Original Message----- > From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] > Sent: Wednesday, June 04, 2008 11:33 > To: Audet, Francois (SC100:3055); DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > = > Francois, > = > Thanks for your thoughts. We can certainly add more details if it is = > unclear. > = > As a clarification, I don't think we are saying that the current = > mechanism is necessarily broken (which is why it is not an essential = > correction, as discussed earlier in the WG). > However, we want to allow for the use of this header in deployments = > that use Digest (with or without TLS; e.g., when integrity protection = > is provided by other means) and can benefit from its advantages = > (mutual auth, nextnonce). > = > - S > = > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = > Francois Audet > Sent: Wednesday, June 04, 2008 12:08 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > = > I do not believe that this document provide enought justification of = > what is the problem that is being attempted to be solved, and why it = > isn't already solved by existing mechanism that are widely implemented = > (such as TLS). > = > Section 9 (Security Considerations) I believe touches on it a little = > bit, but it seems both incomplete and out of place. > = > The problem statement needs to be brough forward in the document (say = > to section 3 or a new section). The scope of applicability of the = > solution should also be described up-front). > = > I wan't to clarfiy I'm not necessarily against this: I just want the = > justification to be clearer. The onus should be on this document to = > clearly demonstrate why what we currently have is broken. > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 04, 2008 02:48 > > To: sip@ietf.org > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > (As SIP WG cochair) > > = > > This has been raised in the SIP group a couple of times, > and we have > > not yet gained an idea of whether to proceed with it in the > SIP WG or > > not. > > = > > There have been a couple of technical comments raised in > the past from > > the security experts; my understanding is that these have now been = > > clarified. > > = > > I believe in the past there has been an interested > community that says > > this is useful. It has also been clarified that 3GPP would > like to use > > it in their specifications. > > = > > So could I ask the WG to look at this document, and formally to = > > indicate whether they believe some work with this scope should be = > > progressed as a SIP WG item. > > = > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > > th-02.txt > > = > > So if you support it please indicate to the SIP WG chairs. > > = > > If you have technical concerns (i.e. it should not proceed > because it > > is technically flawed beyond fixing) then please ideally mail the = > > list, although the SIP WG chairs will also accept input. > > = > > Responses please in 1 calendar week from this date. > > = > > Regards > > = > > Keith > > = > > = > > ________________________________ > > = > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On Behalf Of Stuart Hoggan > > Sent: Friday, May 02, 2008 5:15 PM > > To: sip@ietf.org > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > = > > = > > Folks, > > = > > = > > = > > Based on the feedback received in Philadelphia, we have updated = > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the = > > Proxy-Authentication-Info header, including support for multiple = > > values. > > = > > = > > = > > = > > Any further comments or suggestions will be > appreciated. It would > > also be nice to obtain WG feedback on pursuing this I-D as a WG = > > document. > > = > > = > > = > > Regards, > > = > > Stuart > > = > > = > > = > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use = > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > sipping@ietf.org for new developments on the application of sip > > = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 5 14:34:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCA63A68AF; Thu, 5 Jun 2008 14:34:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B3A3A68AF for ; Thu, 5 Jun 2008 14:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 cGpyt3tNvUVx for ; Thu, 5 Jun 2008 14:34:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 728BA3A686B for ; Thu, 5 Jun 2008 14:34:26 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m55LYTYL013240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 5 Jun 2008 16:34:33 -0500 Message-Id: <12C57E3E-6E1A-4944-956A-7ACDB1027B0A@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 5 Jun 2008 16:34:24 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] What's happening with Outbound? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We found a couple of typos and other nits in draft-ietf-sip- outbound-14. The authors are working on a -15 that I expect to be "final", so if you have any other changes you want in there, get them to the list NOW. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 5 20:03:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B773A6ABD; Thu, 5 Jun 2008 20:03:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28EB3A6AD8 for ; Thu, 5 Jun 2008 20:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.192, 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 uBltrjEBJN2G for ; Thu, 5 Jun 2008 20:03:51 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 141943A6AC6 for ; Thu, 5 Jun 2008 20:03:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FD2320F12; Fri, 6 Jun 2008 05:03:54 +0200 (CEST) X-AuditID: c1b4fb3e-af19abb000004ec0-5c-4848a91ac443 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 21C44200ED; Fri, 6 Jun 2008 05:03:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 05:03:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 05:03:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What's happening with Outbound? Thread-Index: AcjHVAvnOPRrybrHSnyJ5FnM8CqjhQALE0B+ References: <12C57E3E-6E1A-4944-956A-7ACDB1027B0A@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , X-OriginalArrivalTime: 06 Jun 2008 03:03:53.0705 (UTC) FILETIME=[F3EB4590:01C8C781] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] What's happening with Outbound? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, One minor editorial issue: Chapter 4.2.2 says: "Re-registrations and single Contact de-registrations use the same instance-id and reg-id values as the corresponding initial registration." Other than the "Contact de-registrations" wording, I can't find any text about explicitly removing flows (using REGISTER with "0" expiration interval). Would it be possible to add some extra words about that? Maybe simply saying: "Re-registrations and single Contact de-registrations (i.e. explicit removal of flows) use the same..." Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Dean Willis Sent: Thu 05/06/2008 23:34 To: sip@ietf.org Subject: [Sip] What's happening with Outbound? We found a couple of typos and other nits in draft-ietf-sip- outbound-14. The authors are working on a -15 that I expect to be "final", so if you have any other changes you want in there, get them to the list NOW. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 5 20:31:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905B128C103; Thu, 5 Jun 2008 20:31:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4282E3A6AB2 for ; Thu, 5 Jun 2008 20:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.581 X-Spam-Level: X-Spam-Status: No, score=-4.581 tagged_above=-999 required=5 tests=[AWL=-1.668, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh87DxV3rCX8 for ; Thu, 5 Jun 2008 20:31:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E80A43A69C8 for ; Thu, 5 Jun 2008 20:31:45 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4FC0A20758; Fri, 6 Jun 2008 05:31:52 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-91-4848afa8e15c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 00FFE2023F; Fri, 6 Jun 2008 05:31:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 05:31:51 +0200 Received: from emyklmw102.eapac.ericsson.se ([150.236.92.102]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 05:31:51 +0200 Received: from ecnbjmw513.eapac.ericsson.se ([150.236.34.26]) by emyklmw102.eapac.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 11:31:44 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 11:30:48 +0800 Message-ID: In-Reply-To: <48468E37.40603@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What is the port number in "Invite" request-line? Thanks Thread-Index: AcjGQL5lJEM9Za9hSmypkOEO3tHLxABP1APg References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> From: "Yuantao Zhang" To: "Paul Kyzivat" , "Attila Sipos" , , X-OriginalArrivalTime: 06 Jun 2008 03:31:44.0764 (UTC) FILETIME=[D7F2A3C0:01C8C785] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1492752840==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1492752840== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C785.D65DAEA0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C785.D65DAEA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear all=20 Thanks for your reply. Please let me ask my question in another way. =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UDP: Src port: 5060 Dst port: 5555 *<-------------- =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIP: INVITE sip:123101@192.168.100.100:5555 SIP/2.0 *<-------------- Via: SIP/2.0/UDP 192.168.100.3:5060;rport;branch=3Dz9hG4bK27195 From: ;tag=3D27266 To: Call-ID: 24658@192.168.100.3 CSeq: 20 INVITE Contact: =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The above "Invite" message is over UDP. In the UDP part (Transport = layer), the Destination port is 5555. In the SIP part (application = layer), the port in the "Invite" request-line URL is 5555 too. Both of = them are same. In which case the port in "Invite" request-line URL is = different from the Destination port in lower layer UDP? Furthermore, if = they are always same why we include redundant information (the port = number) in "Invite" request-line URL? What happens if the port in = "Invite" request-line URL is different from the Destination port in = lower layer UDP?=20 Thank you very much Best Regards Yuantao -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 2008=C4=EA6=D4=C24=C8=D5 20:45 To: Attila Sipos Cc: Yuantao Zhang; sip@ietf.org; discussion@sipforum.org Subject: Re: [Sip] What is the port number in "Invite" request-line? = Thanks Attila Sipos wrote: > =20 > It is possible to have two instances of a UA (for example) on one = unit. >=20 > So using the port is theoretically one way to differentiate between=20 > instances. > =20 > It's not useless. If you get a Contact header with a port then you = have > to send to that port (discounting NAT traversal scenarios) otherwise=20 > everything will break. > =20 >> >Or is the port number is which the UAS is listening to? How the UAC=20 > knows it is 5555 if so? > =20 > A UAC might not know but a proxy/registrar might - for example if a = user=20 > was registered with > the Contact as port 5555, then requests to that user will get = forwarded=20 > to port 5555. > Another user using, for example, port 5556 will register using a = Contact=20 > with 5556 > and so will receive requests to that port. Right. This illustrates a good point: In general a UAC should not be expected to know "what port a UAS listens = on". All A UAC should be doing is sending requests to URIs that it has=20 been given. If the URI it is given contains a port number, then it=20 should honor that. This gets bent out of shape a bit by numeric dialing, where the UAC is=20 only given a dial string and must derive a URI from it. The "standard"=20 way to do this is via ENUM, where effectively the numeric address is=20 looked up in a DB to obtain a URI. In that case again the UAC has been=20 "given" the URI, which may have a port or not. In the non-standard but common case where the UAC *constructs* a URI=20 from a dial string, the UAC must still be *told* what to use for the=20 remainder of the URI. Paul From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Yuantao Zhang Sent: 04 June 2008 11:10 To: sip@ietf.org; discussion@sipforum.org Subject: [Sip] What is the port number in "Invite" request-line? Thanks Dear all INVITE sip:bob@biloxi.com SIP/2.0:5555 INVITE sip:bob@biloxi.com SIP/2.0 Above are 2 =A1=B0Invite=A1=B1 request-line examples. In example one, it = indicates a port number, 5555. What does the port number mean?=20 Is it the port number of SIP proxy? Why we include port number here? The = SIP proxy(biloxi.com) application layer who receives this "Invite" = should receive this via port 5555 from lowe layer(UDP). Therefore, The = SIP proxy(biloxi.com) application layer already know the port is 5555. = Actualy, the SIP proxy application layer keeps listening port 5555.=20 The second =A1=B0Invite=A1=B1 request-line example is from RFC3261 and = does not include port number. Can I say the port number is useless? So = why example one includes a useless part in =A1=B0Invite=A1=B1 = request-line URL?=20 Or is the port number is which the UAS is listening to? How the UAC = knows it is 5555 if so?=20 Any standard on this port number issue? Thanks.=20 Best regards Steven ------_=_NextPart_001_01C8C785.D65DAEA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable RE: [Sip] What is the port number in "Invite" = request-line? Thanks

Dear all

Thanks for your reply. Please = let me ask my question in another way.

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

UDP:

Src = port: 5060

Dst = port: 5555        *ß------------

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SIP:

INVITE sip:123101@192.168.100.100:5555 SIP/2.0  *ß------------

Via: SIP/2.0/UDP = 192.168.100.3:5060;rport;branch=3Dz9hG4bK27195

From: <sip:123102@192.168.100.100>;tag=3D27266

To: <sip:123101@192.168.100.100:5555>

Call-ID: 24658@192.168.100.3

CSeq: 20 INVITE

Contact: <sip:123102@192.168.100.3:5060>

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The above = "Invite" = message is = over UDP. In the = UDP part (Transport layer), the Destination port is 5555. In the SIP part = (application layer), the port in the = "Invite" request-line URL is 5555 too. Both of them are same. In which case = the port in "Invite" request-line URL is different from the Destination = port in lower layer = UDP? Furthermore, if they are always same why we = include redundant information (the port = number) in = "Invite" request-line URL? What happens if the port in "Invite" request-line URL is different from the Destination port in lower layer UDP?

Thank you very much

Best Regards

Yuantao

-----Original Message-----

From: Paul Kyzivat [mailto:pkyzivat@cisco.com] =

Sent: 2008=C4=EA6=D4=C24=C8=D5 20:45

To: Attila Sipos

Cc: Yuantao Zhang; sip@ietf.org; = discussion@sipforum.org

Subject: Re: [Sip] What is the port number in "Invite" = request-line? Thanks



Attila Sipos wrote:

> 

> It is possible to have two instances of a UA (for example) on = one unit.

>

> So using the port = is theoretically one way to differentiate between

> instances.

> 

> It's not useless.  If you get a Contact header with a = port then you have

> to send to that port (discounting NAT traversal scenarios) = otherwise

> everything will break.

> 

>> >Or is the = port number is which the UAS is listening to? How the UAC =

> knows it is 5555 if so?

> 

> A UAC might not know but a proxy/registrar might - for example = if a user

> was registered with

> the Contact as port 5555, then requests to that user will get = forwarded

> to port 5555.

> Another user using, for example, port 5556 will register using = a Contact

> with 5556

> and so will receive requests to that port.

Right. This illustrates a good point:

In = general a UAC should not be expected to know "what port a UAS = listens

on". All A UAC should be doing is sending requests to URIs = that it has

been given. If the URI it is given contains a port number, then it =

should honor that.

This gets bent out of = shape a bit by numeric dialing, where the UAC is

only given a dial string and must derive a URI from it. The = "standard"

way to do this is via ENUM, where effectively the numeric address = is

looked up in a DB to obtain a URI. In that case again = the UAC has been =

"given" the URI, which may have a port or = not.

In = the non-standard but common case where the UAC *constructs* a URI =

from a dial string, the UAC must still be *told* what to use for = the

remainder of the URI.

        Paul

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf Of Yuantao Zhang
Sent: 04 June 2008 11:10
To: sip@ietf.org; = discussion@sipforum.org
Subject: [Sip] What is the port number in "Invite" = request-line? Thanks

Dear all

INVITE = sip:bob@biloxi.com SIP/2.0:5555

INVITE sip:bob@biloxi.com = SIP/2.0

Above are 2 =A1=B0Invite=A1=B1 request-line examples. In = example one, it indicates a port number, 5555. What does the port number = mean?

Is it the port number of SIP = proxy? Why we include port number here? The SIP proxy(biloxi.com) application = layer who receives this "Invite" should receive this via port = 5555 from lowe layer(UDP). Therefore, The SIP proxy(biloxi.com) application layer already = know the port is 5555. Actualy, the SIP proxy application layer keeps = listening port = 5555.

The second =A1=B0Invite=A1=B1 request-line example is from = RFC3261 and does not include port number. Can I say the port number is = useless? So why example one includes a useless part in = =A1=B0Invite=A1=B1 request-line URL?

Or is the port number = is which the UAS is = listening to? How the UAC knows it is 5555 if so?

Any standard on this port = number issue? Thanks.

Best regards

Steven

------_=_NextPart_001_01C8C785.D65DAEA0-- --===============1492752840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1492752840==-- From sip-bounces@ietf.org Thu Jun 5 22:46:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4AC3A6B60; Thu, 5 Jun 2008 22:46:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F008A3A6B60 for ; Thu, 5 Jun 2008 22:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VMznw+9bJOc for ; Thu, 5 Jun 2008 22:46:06 -0700 (PDT) Received: from web8408.mail.in.yahoo.com (web8408.mail.in.yahoo.com [202.43.219.156]) by core3.amsl.com (Postfix) with SMTP id D4FBF3A6CC9 for ; Thu, 5 Jun 2008 22:45:56 -0700 (PDT) Received: (qmail 19457 invoked by uid 60001); 6 Jun 2008 05:46:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ywa5Hhak3wXNy8IFC6F8qZSFTbZ3lc3l0hFLkzZF5TkrhF2tu3N+rHQpqJcOe8nfVt3wCcJtW8VcbJa06MlPnQIAqcR3IAg7YZ0OisarJnxIYscYHwQFfXZG63C2vHiUMu5GvMKGBX1NV9ccsgOWUwv1UxXHPq/b/b4NsJIAD78=; Received: from [121.241.96.5] by web8408.mail.in.yahoo.com via HTTP; Fri, 06 Jun 2008 11:15:59 IST X-Mailer: YahooMailWebService/0.7.199 Date: Fri, 6 Jun 2008 11:15:59 +0530 (IST) From: atul garg To: sip@ietf.org MIME-Version: 1.0 Message-ID: <913567.99484.qm@web8408.mail.in.yahoo.com> Subject: [Sip] Call ID doubt in SIP and PTT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: shivalk_80@yahoo.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, I have two queries - 1) When we say there is a SIP Conference ie more than two parties are in one call session then how call-id are maintained that is Call -id remains same or changes ,more precisely if SIP Client-A want to invite Client-B and C for call ,it sends a SIP INvite to SIP server-A and ask it to call B and C. Now when SIP server will send two Invites ,one to B and second to c will all these Call IDs be different or same. 2) Same is for Push To Talk(PTT) , when there is a chat session established between multiple clients , are the Call id s same or different or else how one can correlate different messages belong to one session ?/ is there any session id or some other unique field present ?? Please also suggest if anyone have some study documnt regarding this. Thanx Shiva Bring your gang together. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo.com/groups/ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 6 02:30:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E0328C16D; Fri, 6 Jun 2008 02:30:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191D328C16D for ; Fri, 6 Jun 2008 02:30:31 -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 SMNNnZTfbfds for ; Fri, 6 Jun 2008 02:30:30 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 2D7E128C0D8 for ; Fri, 6 Jun 2008 02:30:30 -0700 (PDT) Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id 6C7C41810C56 for ; Fri, 6 Jun 2008 11:30:37 +0200 (CEST) Received: by shell.iptel.org (sSMTP sendmail emulation); Fri, 06 Jun 2008 11:30:37 +0200 Date: Fri, 6 Jun 2008 11:30:37 +0200 From: cco To: sip@ietf.org Message-ID: <20080606093036.GA4685@shell> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: [Sip] aka authentication and sip (rfc 3310) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org hi! in either of the signalling flow examples given in the rfc 3310 (4. Example Digest AKA Operation), the first non-auth REGISTER does not contain an "Authorization" header. also the rfc does not seem to enforce the usage of an "Authorization" header right on from the first register. now, considering that: 1. an correct AKA challenge is user dependent. 2. in order to generate the correct AKA challenge the proxy may need information about both: a. the aor (From/To headers of the REGISTER) and b. the authentication username ("username" parameter of the "Authorization" header) the question is how should the proxy generate a correct AKA challenge when the "Authorization" header is not present in the first (non-auth.) REGISTER? bye now! cristian _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 6 04:54:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AE63A6A84; Fri, 6 Jun 2008 04:54:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C8A3A6A84 for ; Fri, 6 Jun 2008 04:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 ijkjGhusRyHS for ; Fri, 6 Jun 2008 04:54:15 -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 1C1713A6A78 for ; Fri, 6 Jun 2008 04:54:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,600,1204520400"; d="scan'208";a="10307116" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Jun 2008 07:54:23 -0400 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 m56BsN0K009499; Fri, 6 Jun 2008 07:54:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m56BsN1N016882; Fri, 6 Jun 2008 11:54:23 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.1830); Fri, 6 Jun 2008 07:54:23 -0400 Received: from [10.86.243.17] ([10.86.243.17]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 07:54:22 -0400 Message-ID: <48492596.4010704@cisco.com> Date: Fri, 06 Jun 2008 07:55:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Yuantao Zhang References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> In-Reply-To: X-OriginalArrivalTime: 06 Jun 2008 11:54:23.0119 (UTC) FILETIME=[0FBA69F0:01C8C7CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5507; t=1212753263; x=1213617263; 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[Sip]=20What=20is=20the=20port=20number =20in=20=22Invite=22=20request-line?=20Thanks |Sender:=20 |To:=20Yuantao=20Zhang=20; bh=oR9jE11tCBvR2+PWuw71CR3uTqm6X/BeFtuJ4tqXOiM=; b=cg37Dn/coROXyHe0PFYwlh2zTbOL5OEHyszwCIXx1mXrQEDtz4JmlHfsUI Qr998QOW73RIB1a++xfV+7zpGBB5SC157ssI8/zIi+L8BCoUW5sSwkHSowdZ 9lKD4BBmFn; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, discussion@sipforum.org, Attila Sipos Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org VGhlIFVSSSB0eXBpY2FsbHkgZXhpc3RzIGJlZm9yZSB0aGUgbWVzc2FnZSBpcyBjb25zdHJ1Y3Rl ZC4gVGhlbiBhCm1lc3NhZ2UgaXMgY29uc3RydWN0ZWQgYW5kIHRoZSBVUkkgaW5jbHVkZWQgaW4g aXQuIFRoZSBVUkkgc3BlY2lmaWVzCndoZXJlIHRoZSBtZXNzYWdlIGlzICppbnRlbmRlZCogdG8g Z28uIEFuZCBpdCBtaWdodCBub3QgZ28gdGhlcmUKaW1tZWRpYXRlbHkuIEluc3RlYWQgaXQgbWF5 IGZpcnN0IGdvIHRvIGEgcHJveHkuIFdoZW4gaXQgZ2V0cyB0aGVyZSB0aGUKcHJveHkgbmVlZHMg dG8gY29uc3VsdCB0aGUgUi1VUkkgdG8ga25vdyB3aGVyZSB0aGUgbWVzc2FnZSBpcyBpbnRlbmRl ZAp0byBnby4KCldoZW4gdGhlIGxhc3QgaG9wIHRvIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBpcyBt YWRlIGl0IGlzIHRydWUgdGhhdCB0aGUKcG9ydCBudW1iZXIsIGFuZCB0aGUgaXAgYWRkcmVzcywg bWF5IGJlIHJlZHVuZGFudC4gQnV0IHdlIGRvbid0IGV4cGVjdAp0aGUgaW50ZXJtZWRpYXRlIG5v ZGVzIHRvIHJlbW92ZSB0aGUgaW5mb3JtYXRpb24uIFRoZSByZWNpcGllbnQgbWF5IGRvCmFzIGl0 IHdpc2hlcyBpZiBpdCByZWNlaXZlcyBhIHJlcXVlc3Qgd2l0aCBhZGRyZXNzaW5nIHRoYXQgaXMK aW5jb25zaXN0ZW50IHdpdGggd2hlcmUgaXQgaXMgcmVjZWl2ZWQuCgoJUGF1bAoKWXVhbnRhbyBa aGFuZyB3cm90ZToKPiBEZWFyIGFsbAo+IAo+IFRoYW5rcyBmb3IgeW91ciByZXBseS4gUGxlYXNl IGxldCBtZSBhc2sgbXkgcXVlc3Rpb24gaW4gYW5vdGhlciB3YXkuCj4gCj4gPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gCj4g VURQOgo+IAo+IFNyYyBwb3J0OiA1MDYwCj4gCj4gRHN0IHBvcnQ6IDU1NTUgICAgICAgICrDny0t LS0tLS0tLS0tLQo+IAo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQo+IAo+IFNJUDoKPiAKPiBJTlZJVEUgc2lwOjEyMzEwMUAx OTIuMTY4LjEwMC4xMDA6NTU1NSBTSVAvMi4wICAqw58tLS0tLS0tLS0tLS0KPiAKPiBWaWE6IFNJ UC8yLjAvVURQIDE5Mi4xNjguMTAwLjM6NTA2MDtycG9ydDticmFuY2g9ejloRzRiSzI3MTk1Cj4g Cj4gRnJvbTogPHNpcDoxMjMxMDJAMTkyLjE2OC4xMDAuMTAwPjt0YWc9MjcyNjYKPiAKPiBUbzog PHNpcDoxMjMxMDFAMTkyLjE2OC4xMDAuMTAwOjU1NTU+Cj4gCj4gQ2FsbC1JRDogMjQ2NThAMTky LjE2OC4xMDAuMwo+IAo+IENTZXE6IDIwIElOVklURQo+IAo+IENvbnRhY3Q6IDxzaXA6MTIzMTAy QDE5Mi4xNjguMTAwLjM6NTA2MD4KPiAKPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPiAKPiBUaGUgYWJvdmUgIkludml0ZSIg bWVzc2FnZSBpcyBvdmVyIFVEUC4gSW4gdGhlIFVEUCBwYXJ0IChUcmFuc3BvcnQgCj4gbGF5ZXIp LCB0aGUgRGVzdGluYXRpb24gcG9ydCBpcyA1NTU1LiBJbiB0aGUgU0lQIHBhcnQgKGFwcGxpY2F0 aW9uIAo+IGxheWVyKSwgdGhlIHBvcnQgaW4gdGhlICJJbnZpdGUiIHJlcXVlc3QtbGluZSBVUkwg aXMgNTU1NSB0b28uIEJvdGggb2YgCj4gdGhlbSBhcmUgc2FtZS4gSW4gd2hpY2ggY2FzZSB0aGUg cG9ydCBpbiAiSW52aXRlIiByZXF1ZXN0LWxpbmUgVVJMIGlzIAo+IGRpZmZlcmVudCBmcm9tIHRo ZSBEZXN0aW5hdGlvbiBwb3J0IGluIGxvd2VyIGxheWVyIFVEUD8gRnVydGhlcm1vcmUsIGlmIAo+ IHRoZXkgYXJlIGFsd2F5cyBzYW1lIHdoeSB3ZSBpbmNsdWRlIHJlZHVuZGFudCBpbmZvcm1hdGlv biAodGhlIHBvcnQgCj4gbnVtYmVyKSBpbiAiSW52aXRlIiByZXF1ZXN0LWxpbmUgVVJMPyBXaGF0 IGhhcHBlbnMgaWYgdGhlIHBvcnQgaW4gCj4gIkludml0ZSIgcmVxdWVzdC1saW5lIFVSTCBpcyBk aWZmZXJlbnQgZnJvbSB0aGUgRGVzdGluYXRpb24gcG9ydCBpbiAKPiBsb3dlciBsYXllciBVRFA/ Cj4gCj4gVGhhbmsgeW91IHZlcnkgbXVjaAo+IAo+IEJlc3QgUmVnYXJkcwo+IAo+IFl1YW50YW8K PiAKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IAo+IEZyb206IFBhdWwgS3l6aXZhdCBb bWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbV0KPiAKPiBTZW50OiAyMDA45bm0NuaciDTml6UgMjA6 NDUKPiAKPiBUbzogQXR0aWxhIFNpcG9zCj4gCj4gQ2M6IFl1YW50YW8gWmhhbmc7IHNpcEBpZXRm Lm9yZzsgZGlzY3Vzc2lvbkBzaXBmb3J1bS5vcmcKPiAKPiBTdWJqZWN0OiBSZTogW1NpcF0gV2hh dCBpcyB0aGUgcG9ydCBudW1iZXIgaW4gIkludml0ZSIgcmVxdWVzdC1saW5lPyBUaGFua3MKPiAK PiAKPiAKPiBBdHRpbGEgU2lwb3Mgd3JvdGU6Cj4gCj4+IAo+IAo+PiAgSXQgaXMgcG9zc2libGUg dG8gaGF2ZSB0d28gaW5zdGFuY2VzIG9mIGEgVUEgKGZvciBleGFtcGxlKSBvbiBvbmUgdW5pdC4K PiAKPj4KPiAKPj4gIFNvIHVzaW5nIHRoZSBwb3J0IGlzIHRoZW9yZXRpY2FsbHkgb25lIHdheSB0 byBkaWZmZXJlbnRpYXRlIGJldHdlZW4KPiAKPj4gIGluc3RhbmNlcy4KPiAKPj4gCj4gCj4+ICBJ dCdzIG5vdCB1c2VsZXNzLiAgSWYgeW91IGdldCBhIENvbnRhY3QgaGVhZGVyIHdpdGggYSBwb3J0 IHRoZW4geW91IGhhdmUKPiAKPj4gIHRvIHNlbmQgdG8gdGhhdCBwb3J0IChkaXNjb3VudGluZyBO QVQgdHJhdmVyc2FsIHNjZW5hcmlvcykgb3RoZXJ3aXNlCj4gCj4+ICBldmVyeXRoaW5nIHdpbGwg YnJlYWsuCj4gCj4+IAo+IAo+PiA+ID5PciBpcyB0aGUgcG9ydCBudW1iZXIgaXMgd2hpY2ggdGhl IFVBUyBpcyBsaXN0ZW5pbmcgdG8/IEhvdyB0aGUgVUFDCj4gCj4+ICBrbm93cyBpdCBpcyA1NTU1 IGlmIHNvPwo+IAo+PiAKPiAKPj4gIEEgVUFDIG1pZ2h0IG5vdCBrbm93IGJ1dCBhIHByb3h5L3Jl Z2lzdHJhciBtaWdodCAtIGZvciBleGFtcGxlIGlmIGEgdXNlcgo+IAo+PiAgd2FzIHJlZ2lzdGVy ZWQgd2l0aAo+IAo+PiAgdGhlIENvbnRhY3QgYXMgcG9ydCA1NTU1LCB0aGVuIHJlcXVlc3RzIHRv IHRoYXQgdXNlciB3aWxsIGdldCBmb3J3YXJkZWQKPiAKPj4gIHRvIHBvcnQgNTU1NS4KPiAKPj4g IEFub3RoZXIgdXNlciB1c2luZywgZm9yIGV4YW1wbGUsIHBvcnQgNTU1NiB3aWxsIHJlZ2lzdGVy IHVzaW5nIGEgQ29udGFjdAo+IAo+PiAgd2l0aCA1NTU2Cj4gCj4+ICBhbmQgc28gd2lsbCByZWNl aXZlIHJlcXVlc3RzIHRvIHRoYXQgcG9ydC4KPiAKPiBSaWdodC4gVGhpcyBpbGx1c3RyYXRlcyBh IGdvb2QgcG9pbnQ6Cj4gCj4gSW4gZ2VuZXJhbCBhIFVBQyBzaG91bGQgbm90IGJlIGV4cGVjdGVk IHRvIGtub3cgIndoYXQgcG9ydCBhIFVBUyBsaXN0ZW5zCj4gCj4gb24iLiBBbGwgQSBVQUMgc2hv dWxkIGJlIGRvaW5nIGlzIHNlbmRpbmcgcmVxdWVzdHMgdG8gVVJJcyB0aGF0IGl0IGhhcwo+IAo+ IGJlZW4gZ2l2ZW4uIElmIHRoZSBVUkkgaXQgaXMgZ2l2ZW4gY29udGFpbnMgYSBwb3J0IG51bWJl ciwgdGhlbiBpdAo+IAo+IHNob3VsZCBob25vciB0aGF0Lgo+IAo+IFRoaXMgZ2V0cyBiZW50IG91 dCBvZiBzaGFwZSBhIGJpdCBieSBudW1lcmljIGRpYWxpbmcsIHdoZXJlIHRoZSBVQUMgaXMKPiAK PiBvbmx5IGdpdmVuIGEgZGlhbCBzdHJpbmcgYW5kIG11c3QgZGVyaXZlIGEgVVJJIGZyb20gaXQu IFRoZSAic3RhbmRhcmQiCj4gCj4gd2F5IHRvIGRvIHRoaXMgaXMgdmlhIEVOVU0sIHdoZXJlIGVm ZmVjdGl2ZWx5IHRoZSBudW1lcmljIGFkZHJlc3MgaXMKPiAKPiBsb29rZWQgdXAgaW4gYSBEQiB0 byBvYnRhaW4gYSBVUkkuIEluIHRoYXQgY2FzZSBhZ2FpbiB0aGUgVUFDIGhhcyBiZWVuCj4gCj4g ImdpdmVuIiB0aGUgVVJJLCB3aGljaCBtYXkgaGF2ZSBhIHBvcnQgb3Igbm90Lgo+IAo+IEluIHRo ZSBub24tc3RhbmRhcmQgYnV0IGNvbW1vbiBjYXNlIHdoZXJlIHRoZSBVQUMgKmNvbnN0cnVjdHMq IGEgVVJJCj4gCj4gZnJvbSBhIGRpYWwgc3RyaW5nLCB0aGUgVUFDIG11c3Qgc3RpbGwgYmUgKnRv bGQqIHdoYXQgdG8gdXNlIGZvciB0aGUKPiAKPiByZW1haW5kZXIgb2YgdGhlIFVSSS4KPiAKPiAg ICAgICAgIFBhdWwKPiAKPiAqKipGcm9tOiogc2lwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz aXAtYm91bmNlc0BpZXRmLm9yZ10qKiogT24gCj4gQmVoYWxmIE9mKiBZdWFudGFvIFpoYW5nCj4g KioqU2VudDoqIDA0IEp1bmUgMjAwOCAxMToxMAo+ICoqKlRvOiogc2lwQGlldGYub3JnOyBkaXNj dXNzaW9uQHNpcGZvcnVtLm9yZwo+ICoqKlN1YmplY3Q6KiBbU2lwXSBXaGF0IGlzIHRoZSBwb3J0 IG51bWJlciBpbiAiSW52aXRlIiByZXF1ZXN0LWxpbmU/IFRoYW5rcwo+IAo+IERlYXIgYWxsCj4g Cj4gSU5WSVRFIHNpcDpib2JAYmlsb3hpLmNvbSBTSVAvMi4wOjU1NTUKPiAKPiBJTlZJVEUgc2lw OmJvYkBiaWxveGkuY29tIFNJUC8yLjAKPiAKPiBBYm92ZSBhcmUgMiDigJxJbnZpdGXigJ0gcmVx dWVzdC1saW5lIGV4YW1wbGVzLiBJbiBleGFtcGxlIG9uZSwgaXQgaW5kaWNhdGVzIAo+IGEgcG9y dCBudW1iZXIsIDU1NTUuIFdoYXQgZG9lcyB0aGUgcG9ydCBudW1iZXIgbWVhbj8KPiAKPiBJcyBp dCB0aGUgcG9ydCBudW1iZXIgb2YgU0lQIHByb3h5PyBXaHkgd2UgaW5jbHVkZSBwb3J0IG51bWJl ciBoZXJlPyBUaGUgCj4gU0lQIHByb3h5KGJpbG94aS5jb20pIGFwcGxpY2F0aW9uIGxheWVyIHdo byByZWNlaXZlcyB0aGlzICJJbnZpdGUiIAo+IHNob3VsZCByZWNlaXZlIHRoaXMgdmlhIHBvcnQg NTU1NSBmcm9tIGxvd2UgbGF5ZXIoVURQKS4gVGhlcmVmb3JlLCBUaGUgCj4gU0lQIHByb3h5KGJp bG94aS5jb20pIGFwcGxpY2F0aW9uIGxheWVyIGFscmVhZHkga25vdyB0aGUgcG9ydCBpcyA1NTU1 LiAKPiBBY3R1YWx5LCB0aGUgU0lQIHByb3h5IGFwcGxpY2F0aW9uIGxheWVyIGtlZXBzIGxpc3Rl bmluZyBwb3J0IDU1NTUuCj4gCj4gVGhlIHNlY29uZCDigJxJbnZpdGXigJ0gcmVxdWVzdC1saW5l IGV4YW1wbGUgaXMgZnJvbSBSRkMzMjYxIGFuZCBkb2VzIG5vdCAKPiBpbmNsdWRlIHBvcnQgbnVt YmVyLiBDYW4gSSBzYXkgdGhlIHBvcnQgbnVtYmVyIGlzIHVzZWxlc3M/IFNvIHdoeSAKPiBleGFt cGxlIG9uZSBpbmNsdWRlcyBhIHVzZWxlc3MgcGFydCBpbiDigJxJbnZpdGXigJ0gcmVxdWVzdC1s aW5lIFVSTD8KPiAKPiBPciBpcyB0aGUgcG9ydCBudW1iZXIgaXMgd2hpY2ggdGhlIFVBUyBpcyBs aXN0ZW5pbmcgdG8/IEhvdyB0aGUgVUFDIAo+IGtub3dzIGl0IGlzIDU1NTUgaWYgc28/Cj4gCj4g QW55IHN0YW5kYXJkIG9uIHRoaXMgcG9ydCBudW1iZXIgaXNzdWU/IFRoYW5rcy4KPiAKPiBCZXN0 IHJlZ2FyZHMKPiAKPiBTdGV2ZW4KPiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXAKVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhl IGNvcmUgU0lQIFByb3RvY29sClVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBm b3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwClVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcg ZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXA= From sip-bounces@ietf.org Fri Jun 6 07:49:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B987528C1B8; Fri, 6 Jun 2008 07:49:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA5528C19D for ; Fri, 6 Jun 2008 07:49:56 -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_DE=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 Ul-1QjTFKT7z for ; Fri, 6 Jun 2008 07:49:52 -0700 (PDT) Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.17]) by core3.amsl.com (Postfix) with ESMTP id 5998C28C1D8 for ; Fri, 6 Jun 2008 07:49:52 -0700 (PDT) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw22] (8.14.2+/8.14.2) with ESMTP id m56Eo03E009557; Fri, 6 Jun 2008 16:50:00 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m56EnxUi009532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Jun 2008 16:50:00 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m56Enx3i016105; Fri, 6 Jun 2008 16:49:59 +0200 (MEST) Received: from heisenberg.fokus.fraunhofer.de ([10.147.9.232]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 16:49:59 +0200 Received: from [127.0.0.1] ([10.147.67.172]) by heisenberg.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 16:49:59 +0200 Message-ID: <48494E97.2010108@fokus.fraunhofer.de> Date: Fri, 06 Jun 2008 16:49:59 +0200 From: Dragos Vingarzan User-Agent: Thunderbird 2.0.0.12 (X11/20080428) MIME-Version: 1.0 To: cco References: <20080606093036.GA4685@shell> In-Reply-To: <20080606093036.GA4685@shell> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 06 Jun 2008 14:49:59.0324 (UTC) FILETIME=[97CBB5C0:01C8C7E4] X-Fraunhofer-Email-Policy: accepted Cc: sip@ietf.org Subject: Re: [Sip] aka authentication and sip (rfc 3310) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I also find this quite annoying. The 3GPP standards indicate that the UE "shall" add that initial header, so if you are in the 3GPP IMS scope, it works. After implementing AKA and using it for quite some time, I would say that the presence of an Authorization header in the first request indicates that the client knows how to do AKA. If you don't see one, don't bother sending an AKA challenge. But this is just an experience fact, so to say, and not a written fact. And I would add that I don't think that there is another way of auto-detecting the username either. The best example is when I have 2 phones with 2 ISIMs, but they share the same AOR. The requests would be identical for both, yet the challenge must be generated accordingly for each of them. I hope we get a more authoritative answer though.... Anyone? Cheers, -Dragos cco wrote: > hi! > > in either of the signalling flow examples given in the rfc 3310 (4. Example > Digest AKA Operation), the first non-auth REGISTER does not contain an > "Authorization" header. also the rfc does not seem to enforce the usage > of an "Authorization" header right on from the first register. > > now, considering that: > > 1. an correct AKA challenge is user dependent. > 2. in order to generate the correct AKA challenge the proxy may need > information about both: > a. the aor (From/To headers of the REGISTER) and > b. the authentication username ("username" parameter of the "Authorization" > header) > > the question is how should the proxy generate a correct AKA challenge when > the "Authorization" header is not present in the first (non-auth.) > REGISTER? > > bye now! > cristian > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.schroeder@nitro-software.de Fri Jun 6 08:40:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CA53A6840; Fri, 6 Jun 2008 08:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.369 X-Spam-Level: X-Spam-Status: No, score=-87.369 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 7WjAPmoZJ9Le; Fri, 6 Jun 2008 08:40:17 -0700 (PDT) Received: from Dynamic-IP-19015910953.cable.net.co (unknown [190.159.109.53]) by core3.amsl.com (Postfix) with SMTP id 154913A6A19; Fri, 6 Jun 2008 08:40:08 -0700 (PDT) X-Originating-IP: 81.140.173.159 by smtp.190.159.109.53; Fri, 06 Jun 2008 11:40:18 -0500 Message-ID: From: "Abby Chapman" Reply-To: "Abby Chapman" To: send-archive@ietf.org Subject: Inexpensive IWC watches Date: Fri, 06 Jun 2008 11:40:18 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://tihofulehup34.blogspot.com/ From sip-bounces@ietf.org Fri Jun 6 09:41:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17BD83A6D7A; Fri, 6 Jun 2008 09:41:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2430428C170 for ; Fri, 6 Jun 2008 09:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 ChhgDus5+1Um for ; Fri, 6 Jun 2008 09:41:22 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DE8743A6D64 for ; Fri, 6 Jun 2008 09:39:21 -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 m56Gc7w19811; Fri, 6 Jun 2008 16:38:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 11:39:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF173B9D22@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What's happening with Outbound? Thread-Index: AcjHVAvnOPRrybrHSnyJ5FnM8CqjhQALE0B+ABy0Q/A= References: <12C57E3E-6E1A-4944-956A-7ACDB1027B0A@softarmor.com> From: "Francois Audet" To: "Christer Holmberg" , "Dean Willis" , Cc: Cullen Jennings , Rohan Mahy Subject: Re: [Sip] What's happening with Outbound? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I propose that we use the exact terminology of RFC 3261 (10.2.1 -adding-, 10.2.3 -removing- and 10.2.4 -refreshing). So it would look like this: Registrations for refreshing a binding and for removing a binding use the same instance-id and reg-id values as the corresponding initial registration where the binding was added. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Thursday, June 05, 2008 20:04 > To: Dean Willis; sip@ietf.org > Subject: Re: [Sip] What's happening with Outbound? > > Hi, > > One minor editorial issue: > > Chapter 4.2.2 says: > > "Re-registrations and single Contact de-registrations use the > same instance-id and reg-id values as the corresponding > initial registration." > > Other than the "Contact de-registrations" wording, I can't > find any text about explicitly removing flows (using REGISTER > with "0" expiration interval). Would it be possible to add > some extra words about that? > > Maybe simply saying: > > "Re-registrations and single Contact de-registrations (i.e. > explicit removal of flows) use the same..." > > Regards, > > Christer > > ________________________________ > > From: sip-bounces@ietf.org on behalf of Dean Willis > Sent: Thu 05/06/2008 23:34 > To: sip@ietf.org > Subject: [Sip] What's happening with Outbound? > > > > > We found a couple of typos and other nits in draft-ietf-sip- > outbound-14. The authors are working on a -15 that I expect > to be "final", so if you have any other changes you want in > there, get them to the list NOW. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 6 11:18:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A050D28C1E4; Fri, 6 Jun 2008 11:18:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C27D28C1E4 for ; Fri, 6 Jun 2008 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, 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 V51dIU5zwsdd for ; Fri, 6 Jun 2008 11:18:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E610D28C1E1 for ; Fri, 6 Jun 2008 11:18:28 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C2791209CE; Fri, 6 Jun 2008 20:18:37 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-3e-48497f7de08a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 947D12052B; Fri, 6 Jun 2008 20:18:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 20:18:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 20:17:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What's happening with Outbound? Thread-Index: AcjHVAvnOPRrybrHSnyJ5FnM8CqjhQALE0B+ABy0Q/AAA5mpfA== References: <12C57E3E-6E1A-4944-956A-7ACDB1027B0A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF173B9D22@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Dean Willis" , X-OriginalArrivalTime: 06 Jun 2008 18:18:37.0333 (UTC) FILETIME=[BD1C4C50:01C8C801] X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , Rohan Mahy Subject: Re: [Sip] What's happening with Outbound? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, If "removing a binding" = "removing a flow", then I guess it's ok. REgards, Christer ________________________________ From: Francois Audet [mailto:audet@nortel.com] Sent: Fri 06/06/2008 18:39 To: Christer Holmberg; Dean Willis; sip@ietf.org Cc: Cullen Jennings; Rohan Mahy Subject: RE: [Sip] What's happening with Outbound? I propose that we use the exact terminology of RFC 3261 (10.2.1 -adding-, 10.2.3 -removing- and 10.2.4 -refreshing). So it would look like this: Registrations for refreshing a binding and for removing a binding use the same instance-id and reg-id values as the corresponding initial registration where the binding was added. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Thursday, June 05, 2008 20:04 > To: Dean Willis; sip@ietf.org > Subject: Re: [Sip] What's happening with Outbound? > > Hi, > > One minor editorial issue: > > Chapter 4.2.2 says: > > "Re-registrations and single Contact de-registrations use the > same instance-id and reg-id values as the corresponding > initial registration." > > Other than the "Contact de-registrations" wording, I can't > find any text about explicitly removing flows (using REGISTER > with "0" expiration interval). Would it be possible to add > some extra words about that? > > Maybe simply saying: > > "Re-registrations and single Contact de-registrations (i.e. > explicit removal of flows) use the same..." > > Regards, > > Christer > > ________________________________ > > From: sip-bounces@ietf.org on behalf of Dean Willis > Sent: Thu 05/06/2008 23:34 > To: sip@ietf.org > Subject: [Sip] What's happening with Outbound? > > > > > We found a couple of typos and other nits in draft-ietf-sip- > outbound-14. The authors are working on a -15 that I expect > to be "final", so if you have any other changes you want in > there, get them to the list NOW. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.jordan@aldridge-jordan.com Fri Jun 6 23:38:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE823A67EB; Fri, 6 Jun 2008 23:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.405 X-Spam-Level: X-Spam-Status: No, score=-69.405 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 rkqz-tnh2div; Fri, 6 Jun 2008 23:38:29 -0700 (PDT) Received: from cpe-190-55-103-55.telecentro.com.ar (unknown [190.55.103.55]) by core3.amsl.com (Postfix) with SMTP id 530B23A680B; Fri, 6 Jun 2008 23:38:20 -0700 (PDT) X-Originating-IP: 96.84.200.110 by smtp.190.55.103.55; Sat, 07 Jun 2008 02:38:32 -0500 Message-ID: From: "Cliff Bowles" Reply-To: "Cliff Bowles" To: send-archive@ietf.org Subject: Hot replica watches from 2008 Date: Sat, 07 Jun 2008 02:38:32 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://mixewycicyw73.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://mixewycicyw73.blogspot.com/ From sip-bounces@ietf.org Fri Jun 6 23:59:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35193A681E; Fri, 6 Jun 2008 23:59:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AE33A6832 for ; Fri, 6 Jun 2008 23:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 nuvhkfuow1kr for ; Fri, 6 Jun 2008 23:59:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C2AD13A6807 for ; Fri, 6 Jun 2008 23:59:03 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m576xDHD022282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Jun 2008 01:59:15 -0500 Message-Id: <56CEB1FF-946D-4C56-9DBB-6AD4FB4F8780@softarmor.com> From: Dean Willis To: shivalk_80@yahoo.co.in In-Reply-To: <913567.99484.qm@web8408.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Sat, 7 Jun 2008 01:59:07 -0500 References: <913567.99484.qm@web8408.mail.in.yahoo.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] Call ID doubt in SIP and PTT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 6, 2008, at 12:45 AM, atul garg wrote: > Hello, > > I have two queries - > > 1) When we say there is a SIP Conference ie more than two parties > are in one call session then how call-id are maintained that is Call > -id remains same or changes ,more precisely if SIP Client-A want to > invite Client-B and C for call ,it sends a SIP INvite to SIP server- > A and ask it to call B and C. Now when SIP server will send two > Invites ,one to B and second to c will all these Call IDs be > different or same. > > 2) Same is for Push To Talk(PTT) , when there is a chat session > established between multiple clients , are the Call id s same or > different or else how one can correlate different messages belong to > one session ?/ is there any session id or some other unique field > present ?? > > Please also suggest if anyone have some study documnt regarding this. > Most SIP "conferences" are implemented by conference bridges, which are back-to-back user agents. What do they do with call IDs? Whatever they want to -- there behavior really isn't specified by IETF. usually, each "leg" of the bridge will be a separate call with a distinct call ID. This makes life much easier. As I understand OMA POC, this is what happens there -- but you'd have to read their spec to be sure. Each "POC controller" (they call it a "participating function", IIRC) is basically a B2BUA. So even a minimal 2 party POC call has three different call legs, all of which probably have (or at least probably should have) different call-IDs. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.glaeser@cglaeser.de Sun Jun 8 10:34:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B541D3A68F8; Sun, 8 Jun 2008 10:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.441 X-Spam-Level: X-Spam-Status: No, score=-69.441 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, 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 zGwGZuuC5vqt; Sun, 8 Jun 2008 10:34:28 -0700 (PDT) Received: from 189-11-108-108.ctaje701.dsl.brasiltelecom.net.br (189-11-108-108.ctaje701.dsl.brasiltelecom.net.br [189.11.108.108]) by core3.amsl.com (Postfix) with SMTP id DE8263A6912; Sun, 8 Jun 2008 10:34:11 -0700 (PDT) X-Originating-IP: 126.207.0.216 by smtp.189.11.108.108; Sun, 08 Jun 2008 13:34:27 -0500 Message-ID: From: "Vonda Stuart" Reply-To: "Vonda Stuart" To: send-archive@ietf.org Subject: Beautiful Rado watches for less Date: Sun, 08 Jun 2008 13:34:27 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080608-0, 08/06/2008), Outbound message X-Antivirus-Status: Clean A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://vitagexamug77.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://vitagexamug77.blogspot.com/ From sip-bounces@ietf.org Sun Jun 8 13:08:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F3D3A6BAA; Sun, 8 Jun 2008 13:08:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B753A6B87 for ; Sun, 8 Jun 2008 13:08:37 -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 IIb2etnm6yyj for ; Sun, 8 Jun 2008 13:08:37 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E6FF33A6B57 for ; Sun, 8 Jun 2008 13:08:36 -0700 (PDT) Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id 950E81810C12; Sun, 8 Jun 2008 22:08:46 +0200 (CEST) Received: by shell.iptel.org (sSMTP sendmail emulation); Sun, 08 Jun 2008 22:08:46 +0200 Date: Sun, 8 Jun 2008 22:08:46 +0200 From: cco To: Dragos Vingarzan Message-ID: <20080608200846.GA6325@shell> References: <20080606093036.GA4685@shell> <48494E97.2010108@fokus.fraunhofer.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48494E97.2010108@fokus.fraunhofer.de> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sip@ietf.org Subject: Re: [Sip] aka authentication and sip (rfc 3310) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Fri, Jun 06, 2008 at 04:49:59PM +0200, Dragos Vingarzan wrote: > I also find this quite annoying. The 3GPP standards indicate that the UE > "shall" add that initial header, so if you are in the 3GPP IMS scope, it > works. > > After implementing AKA and using it for quite some time, I would say > that the presence of an Authorization header in the first request > indicates that the client knows how to do AKA. If you don't see one, > don't bother sending an AKA challenge. But this is just an experience > fact, so to say, and not a written fact. > > And I would add that I don't think that there is another way of > auto-detecting the username either. The best example is when I have 2 > phones with 2 ISIMs, but they share the same AOR. The requests would be > identical for both, yet the challenge must be generated accordingly for > each of them. cristian: hi! dragos, I am refering strictly to the rfc3310 and I am trying to understand how the call flows given as an example there would function in the most general case, that is: 1. the AKA key is shared btw. an AuC and a certain authorization username 2. the sip proxy does not have yet the authentication vector and needs to get it somehow from the AuC. now, the call flows given as an example would function when the challenge (nonce) does not explicitly depend on the user which is actually trying to register itself, being generated (periodically) by the sip proxy itself; that is they are o.k. for an HTTP digest MD5 auth. as spec. in rfc 3261/rfc 2617. but they do NOT seem to function in the real world when AKA is used, because: 1. the challenge is user specific. 2. the "network" authenticates itself to the UE as well in case of AKA. but then again my interpretation of the rfc3310/call flows given as an example there may be wrong. that is why I am asking for an oppinion on this mailing list. thanks. bye now! cristian _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From ca01@51translation.com Sun Jun 8 17:26:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0173A6843; Sun, 8 Jun 2008 17:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -60.608 X-Spam-Level: X-Spam-Status: No, score=-60.608 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 Qbr6D1z7fB0l; Sun, 8 Jun 2008 17:26:10 -0700 (PDT) Received: from 46-136-245-190.fibertel.com.ar (unknown [190.245.136.46]) by core3.amsl.com (Postfix) with SMTP id 94C3A3A6906; Sun, 8 Jun 2008 17:25:50 -0700 (PDT) X-Originating-IP: 254.32.84.80 by smtp.190.245.136.46; Sun, 08 Jun 2008 20:26:05 -0500 Message-ID: From: "Walker Flood" Reply-To: "Walker Flood" To: send-archive@ietf.org Subject: 15% off on two watches Date: Sun, 08 Jun 2008 20:26:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://xegihemawik03.blogspot.com/ From sip-bounces@ietf.org Sun Jun 8 19:34:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1743A691A; Sun, 8 Jun 2008 19:34:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0EF3A67A1 for ; Sun, 8 Jun 2008 19:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=-2.133, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL+zYg1hFU4o for ; Sun, 8 Jun 2008 19:34:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B65E43A677D for ; Sun, 8 Jun 2008 19:34:35 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B0B2B200BE; Mon, 9 Jun 2008 04:34:51 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-dc-484c96cb6ccb Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6795E20090; Mon, 9 Jun 2008 04:34:51 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 04:34:53 +0200 Received: from emyklmw103.eapac.ericsson.se ([150.236.92.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 04:34:53 +0200 Received: from ecnbjmw513.eapac.ericsson.se ([150.236.34.26]) by emyklmw103.eapac.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 10:34:48 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 10:34:46 +0800 Message-ID: In-Reply-To: <48492596.4010704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What is the port number in "Invite" request-line? Thanks Thread-Index: AcjHzCRokGU/cppMQSmDPr1KaNYJ3AAoiqtw References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> <48492596.4010704@cisco.com> From: "Yuantao Zhang" To: "Paul Kyzivat" , , X-OriginalArrivalTime: 09 Jun 2008 02:34:48.0470 (UTC) FILETIME=[62EACB60:01C8C9D9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060760766==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2060760766== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C9D9.61BCB6BC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C9D9.61BCB6BC Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable ------------------ ------------------- ------------------- |UA1 | |SIP proxy | |UA2 | |IP:192.168.100.1|-----|IP: 192.168.100.2 |--------|IP: 192.168.100.3 | |Port: 1111 | |Port: 2222 | |Port: 3333 | ------------------ -------------------- ------------------- If UA1 makes call to UA2, UA1 should send the following message to the = SIP proxy: =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IP:=20 Src: 192.168.100.1 Dst: 192.168.100.2 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UDP: Src port: 1111 Dst port: 2222 ! =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIP: INVITE sip:UA2@192.168.100.2:2222 SIP/2.0 ! Via: SIP/2.0/UDP 192.168.100.1:1111; =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Then SIP proxy sends the following message to UA2: =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IP:=20 Src: 192.168.100.2 Dst: 192.168.100.3 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UDP: Src port: 2222 Dst port: 3333 ! =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIP: INVITE sip:UA2@192.168.100.2:3333 SIP/2.0 ! Via: SIP/2.0/UDP 192.168.100.2:2222; Via: SIP/2.0/UDP 192.168.100.1:1111; =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UAC(UA1) does not know the port of UAS(UA2). All the UAC needs to know = is the proxy's port. And the proxy knows all the ports of UAs under it = (UAs tell proxy when register). Therefore, the proxy does not care the = port number in the received "Invite" request-linen (because the port = number is proxy itself) Therefore, the port number in the "Invite" request-line is always same = with the port number in the lower layer UDP. Why we insert redundant = information? How about we drop this redundant and confusing port number = in the URL? Please correct me if I am wrong. Thanks. Best regards Yuantao Zhang -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 2008=D2=B46=EA=C56=EC=ED 19:55 To: Yuantao Zhang Cc: Attila Sipos; sip@ietf.org; discussion@sipforum.org Subject: Re: [Sip] What is the port number in "Invite" request-line? = Thanks The URI typically exists before the message is constructed. Then a message is constructed and the URI included in it. The URI specifies where the message is *intended* to go. And it might not go there immediately. Instead it may first go to a proxy. When it gets there the proxy needs to consult the R-URI to know where the message is intended to go. When the last hop to the final destination is made it is true that the port number, and the ip address, may be redundant. But we don't expect the intermediate nodes to remove the information. The recipient may do as it wishes if it receives a request with addressing that is inconsistent with where it is received. Paul Yuantao Zhang wrote: > Dear all >=20 > Thanks for your reply. Please let me ask my question in another way. >=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=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 > UDP: >=20 > Src port: 5060 >=20 > Dst port: 5555 *=A9=AC------------ >=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=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 > SIP: >=20 > INVITE sip:123101@192.168.100.100:5555 SIP/2.0 *=A9=AC------------ >=20 > Via: SIP/2.0/UDP 192.168.100.3:5060;rport;branch=3Dz9hG4bK27195 >=20 > From: ;tag=3D27266 >=20 > To: >=20 > Call-ID: 24658@192.168.100.3 >=20 > CSeq: 20 INVITE >=20 > Contact: >=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=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 > The above "Invite" message is over UDP. In the UDP part (Transport=20 > layer), the Destination port is 5555. In the SIP part (application=20 > layer), the port in the "Invite" request-line URL is 5555 too. Both of = > them are same. In which case the port in "Invite" request-line URL is=20 > different from the Destination port in lower layer UDP? Furthermore, = if=20 > they are always same why we include redundant information (the port=20 > number) in "Invite" request-line URL? What happens if the port in=20 > "Invite" request-line URL is different from the Destination port in=20 > lower layer UDP? >=20 > Thank you very much >=20 > Best Regards >=20 > Yuantao >=20 ------_=_NextPart_001_01C8C9D9.61BCB6BC Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable RE: [Sip] What is the port number in "Invite" = request-line? Thanks

------------------     = -------------------         = -------------------

|UA1            =   |     |SIP = proxy          |   =       |UA2      =           |

|IP:192.168.100.1|-----|IP: 192.168.100.2 |--------|IP: 192.168.100.3 |

|Port: 1111       = |     |Port: = 2222        |    =       |Port: = 3333        |

------------------      = --------------------         = -------------------

If = UA1 makes call to UA2, UA1 should send the following message to the SIP = proxy:

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

IP:

Src: 192.168.100.1

Dst: = 192.168.100.2

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

UDP:

Src = port: 1111

Dst = port: 2222        =           =         =         =         =            !

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SIP:

INVITE sip:UA2@192.168.100.2:2222 = SIP/2.0       =         =            !

Via: SIP/2.0/UDP 192.168.100.1:1111;

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Then SIP proxy sends the following message to = UA2:

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

IP:

Src: 192.168.100.2

Dst: = 192.168.100.3

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

UDP:

Src = port: 2222

Dst = port: 3333        =           =         =         =         =            !

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SIP:

INVITE sip:UA2@192.168.100.2:3333 = SIP/2.0       =         =            !

Via: SIP/2.0/UDP 192.168.100.2:2222;

Via: SIP/2.0/UDP = 192.168.100.1:1111;

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

UAC(UA1) does not know the port of UAS(UA2). All = the UAC needs to know is the proxy's port. And the proxy knows all the = ports of UAs under it (UAs tell proxy when register). Therefore, the = proxy does not care the port number in the received "Invite" request-linen (because the port number is proxy = itself)

Therefore, the port number in = the "Invite" = request-line is always same with = the port number in the lower layer UDP. Why we insert redundant = information? How about we = drop this redundant and confusing port number in the = URL? Please correct me if I am wrong. = Thanks.

Best regards

Yuantao Zhang

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: 2008=D2=B46=EA=C56=EC=ED 19:55
To: Yuantao Zhang
Cc: Attila Sipos; sip@ietf.org; discussion@sipforum.org
Subject: Re: [Sip] What is the port number in "Invite" = request-line? Thanks

The URI typically exists = before the message is constructed. Then a

message is constructed and the URI included in it. The URI = specifies

where the message is *intended* to go. And it might not go = there

immediately. Instead it may first go to a proxy. When it gets there = the

proxy needs to consult = the R-URI to know where the message is intended

to = go.

When the last hop to the final destination is made it is true that = the

port number, and the ip address, may be redundant. But we don't = expect

the intermediate nodes to remove the information. The recipient may do

as = it wishes if it receives a request with addressing that = is

inconsistent with where it is received.

        Paul

Yuantao Zhang wrote:

> Dear all

>

> Thanks for your = reply. Please let me ask my question in another way.

>

> = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> =

> = UDP:

> =

> = Src port: 5060

> =

> = Dst port: 5555        = *=A9=AC------------

>

> = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> SIP:

>

> INVITE sip:123101@192.168.100.100:5555 SIP/2.0  = *=A9=AC------------

>

> Via: SIP/2.0/UDP = 192.168.100.3:5060;rport;branch=3Dz9hG4bK27195

>

> From: = <sip:123102@192.168.100.100>;tag=3D27266

>

> To: <sip:123101@192.168.100.100:5555>

>

> Call-ID: 24658@192.168.100.3

>

> CSeq: 20 INVITE

>

> Contact: = <sip:123102@192.168.100.3:5060>

>

> = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> The above "Invite" message is over UDP. In the UDP = part (Transport

> layer), the Destination port is 5555. In the SIP part = (application

> layer), the port in the "Invite" request-line URL is = 5555 too. Both of

> them are same. In which case the port in "Invite" = request-line URL is

> different from the Destination port in lower layer UDP? Furthermore, if =

> they are always same why we include redundant information (the = port

> number) in "Invite" request-line URL? What happens = if the port in

> "Invite" request-line URL is different from the = Destination port in

> lower layer = UDP?

>

> Thank you very much

>

> Best Regards

>

> Yuantao

>

------_=_NextPart_001_01C8C9D9.61BCB6BC-- --===============2060760766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2060760766==-- From c.isopp@morgenbau.net Mon Jun 9 04:35:46 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317613A6C11; Mon, 9 Jun 2008 04:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -63.73 X-Spam-Level: X-Spam-Status: No, score=-63.73 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, GB_ROLEX=5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, 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 NG+WNx4pE4o3; Mon, 9 Jun 2008 04:35:45 -0700 (PDT) Received: from p5137-ipbfp904tokaisakaetozai.aichi.ocn.ne.jp (p5137-ipbfp904tokaisakaetozai.aichi.ocn.ne.jp [125.200.174.137]) by core3.amsl.com (Postfix) with SMTP id D49D03A6A62; Mon, 9 Jun 2008 04:35:37 -0700 (PDT) X-Originating-IP: 23.106.32.176 by smtp.125.200.174.137; Mon, 09 Jun 2008 07:35:55 -0500 Message-ID: From: "Rich Frederick" Reply-To: "Rich Frederick" To: shelley.osborn@ietf.org Subject: April promo on watches Date: Mon, 09 Jun 2008 07:35:55 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://kewimovyduf65.blogspot.com/ From sip-bounces@ietf.org Mon Jun 9 04:51:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6066D3A6C50; Mon, 9 Jun 2008 04:51:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7278D3A6C4F for ; Mon, 9 Jun 2008 04:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMDFRj64TOJl for ; Mon, 9 Jun 2008 04:51:49 -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 BFA243A6AAA for ; Mon, 9 Jun 2008 04:51:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,612,1204520400"; d="scan'208";a="10493091" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Jun 2008 07:52:04 -0400 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 m59Bq4Hw012644; Mon, 9 Jun 2008 07:52:04 -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.13.8) with ESMTP id m59Bq4RS026207; Mon, 9 Jun 2008 11:52:04 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.1830); Mon, 9 Jun 2008 07:52:04 -0400 Received: from [10.86.249.5] ([10.86.249.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 07:52:03 -0400 Message-ID: <484D198B.1000004@cisco.com> Date: Mon, 09 Jun 2008 07:52:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Yuantao Zhang References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> <48492596.4010704@cisco.com> In-Reply-To: X-OriginalArrivalTime: 09 Jun 2008 11:52:04.0052 (UTC) FILETIME=[3C13B940:01C8CA27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5711; t=1213012324; x=1213876324; 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[Sip]=20What=20is=20the=20port=20number =20in=20=22Invite=22=20request-line?=20Thanks |Sender:=20 |To:=20Yuantao=20Zhang=20; bh=eUtuxW6kVMrKfxPCiUE3qVp5KMRFty+1HvHgfs83LK4=; b=UuRcGy8Jld1xXGaDFUq7sEOxPjDEV9DefSa7e17RCbysq6w2wml3qK07EF fNvcs+VzDbQCdWH4IFwK5C8yBMtd2ulHgcl8DpQTgQe/WtId25lICx/kz1TP 5VRbA/Um3r; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, discussion@sipforum.org Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org T0ssIGlmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBhIGNhc2Ugd2l0aCBhIHByb3h5L3JlZ2lzdHJh ciwgdGhlbiB3aGVuCnRoZSBwcm94eSBkb2VzIHRoZSB0cmFuc2xhdGlvbiwgaXQgZG9lcyBzbyBi eSBieSB0YWtraW5nIHRoZSBVUkkgdGhhdAp3YXMgcHJvdmlkZWQgaW4gUkVHSVNURVIgYW5kIHBs YWNpbmcgaXQgaW50byB0aGUgUi1VUkkuIFRoZW4gaXQgcm91dGVzCmJhc2VkIG9uIHRoZSByZXZp c2VkIG1lc3NhZ2UuCgpUaGUgd2hvbGUgc3lzdGVtIG9mIHJvdXRpbmcgc2lwIG1lc3NhZ2VzIGlz IGJhc2VkIG9uIFVSSXMuIFRoZSBVUkkgKm1heSoKY29udGFpbiBhIHBvcnQsIG9yIHRoZSBwb3J0 IG1heSBiZSBkaXNjb3ZlcmVkIHVzaW5nIEROUy4KCkkgZ3Vlc3MgeW91IGFyZSBwcm9wb3Npbmcg c29tZSBlbnRpcmVseSBkaWZmZXJlbnQgc3lzdGVtIGZvciBtYW5hZ2luZwp0aGUgcm91dGluZyBv ZiBzaXAgbWVzc2FnZXMuIEJ1dCB5b3UgYXJlIDggb3IgOSB5ZWFycyB0b28gbGF0ZSBmb3IgdGhh dC4KCglUaGFua3MsCglQYXVsCgpZdWFudGFvIFpoYW5nIHdyb3RlOgo+IC0tLS0tLS0tLS0tLS0t LS0tLSAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0K PiAKPiB8VUExICAgICAgICAgICAgICB8ICAgICB8U0lQIHByb3h5ICAgICAgICAgIHwgICAgICAg ICB8VUEyICAgICAgICAgICAgICAgIHwKPiAKPiB8SVA6MTkyLjE2OC4xMDAuMXwtLS0tLXxJUDog MTkyLjE2OC4xMDAuMiB8LS0tLS0tLS18SVA6IDE5Mi4xNjguMTAwLjMgfAo+IAo+IHxQb3J0OiAx MTExICAgICAgIHwgICAgIHxQb3J0OiAyMjIyICAgICAgICB8ICAgICAgICAgIHxQb3J0OiAzMzMz ICAgICAgICB8Cj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0gICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gSWYgVUExIG1ha2VzIGNhbGwgdG8g VUEyLCBVQTEgc2hvdWxkIHNlbmQgdGhlIGZvbGxvd2luZyBtZXNzYWdlIHRvIHRoZSAKPiBTSVAg cHJveHk6Cj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Cj4gCj4gSVA6Cj4gCj4gU3JjOiAxOTIuMTY4LjEwMC4xCj4gCj4g RHN0OiAxOTIuMTY4LjEwMC4yCj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gCj4gVURQOgo+IAo+IFNyYyBwb3J0OiAx MTExCj4gCj4gRHN0IHBvcnQ6IDIyMjIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICEKPiAKPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPiAKPiBTSVA6Cj4gCj4gSU5WSVRFIHNp cDpVQTJAMTkyLjE2OC4xMDAuMjoyMjIyIFNJUC8yLjAgICAgICAgICAgICAgICAgICAgICAgICAg ICEKPiAKPiBWaWE6IFNJUC8yLjAvVURQIDE5Mi4xNjguMTAwLjE6MTExMTsKPiAKPiA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K PiAKPiAKPiBUaGVuIFNJUCBwcm94eSBzZW5kcyB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgdG8gVUEy Ogo+IAo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQo+IAo+IElQOgo+IAo+IFNyYzogMTkyLjE2OC4xMDAuMgo+IAo+IERzdDog MTkyLjE2OC4xMDAuMwo+IAo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQo+IAo+IFVEUDoKPiAKPiBTcmMgcG9ydDogMjIyMgo+ IAo+IERzdCBwb3J0OiAzMzMzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAhCj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gCj4gU0lQOgo+IAo+IElOVklURSBzaXA6VUEy QDE5Mi4xNjguMTAwLjI6MzMzMyBTSVAvMi4wICAgICAgICAgICAgICAgICAgICAgICAgICAhCj4g Cj4gVmlhOiBTSVAvMi4wL1VEUCAxOTIuMTY4LjEwMC4yOjIyMjI7Cj4gCj4gVmlhOiBTSVAvMi4w L1VEUCAxOTIuMTY4LjEwMC4xOjExMTE7Cj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gCj4gVUFDKFVBMSkgZG9lcyBu b3Qga25vdyB0aGUgcG9ydCBvZiBVQVMoVUEyKS4gQWxsIHRoZSBVQUMgbmVlZHMgdG8ga25vdyAK PiBpcyB0aGUgcHJveHkncyBwb3J0LiBBbmQgdGhlIHByb3h5IGtub3dzIGFsbCB0aGUgcG9ydHMg b2YgVUFzIHVuZGVyIGl0IAo+IChVQXMgdGVsbCBwcm94eSB3aGVuIHJlZ2lzdGVyKS4gVGhlcmVm b3JlLCB0aGUgcHJveHkgZG9lcyBub3QgY2FyZSB0aGUgCj4gcG9ydCBudW1iZXIgaW4gdGhlIHJl Y2VpdmVkICJJbnZpdGUiIHJlcXVlc3QtbGluZW4gKGJlY2F1c2UgdGhlIHBvcnQgCj4gbnVtYmVy IGlzIHByb3h5IGl0c2VsZikKPiAKPiBUaGVyZWZvcmUsIHRoZSBwb3J0IG51bWJlciBpbiB0aGUg Ikludml0ZSIgcmVxdWVzdC1saW5lIGlzIGFsd2F5cyBzYW1lIAo+IHdpdGggdGhlIHBvcnQgbnVt YmVyIGluIHRoZSBsb3dlciBsYXllciBVRFAuIFdoeSB3ZSBpbnNlcnQgcmVkdW5kYW50IAo+IGlu Zm9ybWF0aW9uPyBIb3cgYWJvdXQgd2UgZHJvcCB0aGlzIHJlZHVuZGFudCBhbmQgY29uZnVzaW5n IHBvcnQgbnVtYmVyIAo+IGluIHRoZSBVUkw/IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jv bmcuIFRoYW5rcy4KPiAKPiBCZXN0IHJlZ2FyZHMKPiAKPiBZdWFudGFvIFpoYW5nCj4gCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6 aXZhdEBjaXNjby5jb21dCj4gU2VudDogMjAwONK0NurFNuztIDE5OjU1Cj4gVG86IFl1YW50YW8g WmhhbmcKPiBDYzogQXR0aWxhIFNpcG9zOyBzaXBAaWV0Zi5vcmc7IGRpc2N1c3Npb25Ac2lwZm9y dW0ub3JnCj4gU3ViamVjdDogUmU6IFtTaXBdIFdoYXQgaXMgdGhlIHBvcnQgbnVtYmVyIGluICJJ bnZpdGUiIHJlcXVlc3QtbGluZT8gVGhhbmtzCj4gCj4gVGhlIFVSSSB0eXBpY2FsbHkgZXhpc3Rz IGJlZm9yZSB0aGUgbWVzc2FnZSBpcyBjb25zdHJ1Y3RlZC4gVGhlbiBhCj4gCj4gbWVzc2FnZSBp cyBjb25zdHJ1Y3RlZCBhbmQgdGhlIFVSSSBpbmNsdWRlZCBpbiBpdC4gVGhlIFVSSSBzcGVjaWZp ZXMKPiAKPiB3aGVyZSB0aGUgbWVzc2FnZSBpcyAqaW50ZW5kZWQqIHRvIGdvLiBBbmQgaXQgbWln aHQgbm90IGdvIHRoZXJlCj4gCj4gaW1tZWRpYXRlbHkuIEluc3RlYWQgaXQgbWF5IGZpcnN0IGdv IHRvIGEgcHJveHkuIFdoZW4gaXQgZ2V0cyB0aGVyZSB0aGUKPiAKPiBwcm94eSBuZWVkcyB0byBj b25zdWx0IHRoZSBSLVVSSSB0byBrbm93IHdoZXJlIHRoZSBtZXNzYWdlIGlzIGludGVuZGVkCj4g Cj4gdG8gZ28uCj4gCj4gV2hlbiB0aGUgbGFzdCBob3AgdG8gdGhlIGZpbmFsIGRlc3RpbmF0aW9u IGlzIG1hZGUgaXQgaXMgdHJ1ZSB0aGF0IHRoZQo+IAo+IHBvcnQgbnVtYmVyLCBhbmQgdGhlIGlw IGFkZHJlc3MsIG1heSBiZSByZWR1bmRhbnQuIEJ1dCB3ZSBkb24ndCBleHBlY3QKPiAKPiB0aGUg aW50ZXJtZWRpYXRlIG5vZGVzIHRvIHJlbW92ZSB0aGUgaW5mb3JtYXRpb24uIFRoZSByZWNpcGll bnQgbWF5IGRvCj4gCj4gYXMgaXQgd2lzaGVzIGlmIGl0IHJlY2VpdmVzIGEgcmVxdWVzdCB3aXRo IGFkZHJlc3NpbmcgdGhhdCBpcwo+IAo+IGluY29uc2lzdGVudCB3aXRoIHdoZXJlIGl0IGlzIHJl Y2VpdmVkLgo+IAo+ICAgICAgICAgUGF1bAo+IAo+IFl1YW50YW8gWmhhbmcgd3JvdGU6Cj4gCj4+ ICBEZWFyIGFsbAo+IAo+Pgo+IAo+PiAgVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBQbGVhc2UgbGV0 IG1lIGFzayBteSBxdWVzdGlvbiBpbiBhbm90aGVyIHdheS4KPiAKPj4KPiAKPj4gID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+ IAo+Pgo+IAo+PiAgVURQOgo+IAo+Pgo+IAo+PiAgU3JjIHBvcnQ6IDUwNjAKPiAKPj4KPiAKPj4g IERzdCBwb3J0OiA1NTU1ICAgICAgICAqqawtLS0tLS0tLS0tLS0KPiAKPj4KPiAKPj4gID09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQo+IAo+Pgo+IAo+PiAgU0lQOgo+IAo+Pgo+IAo+PiAgSU5WSVRFIHNpcDoxMjMxMDFAMTkyLjE2 OC4xMDAuMTAwOjU1NTUgU0lQLzIuMCAgKqmsLS0tLS0tLS0tLS0tCj4gCj4+Cj4gCj4+ICBWaWE6 IFNJUC8yLjAvVURQIDE5Mi4xNjguMTAwLjM6NTA2MDtycG9ydDticmFuY2g9ejloRzRiSzI3MTk1 Cj4gCj4+Cj4gCj4+ICBGcm9tOiA8c2lwOjEyMzEwMkAxOTIuMTY4LjEwMC4xMDA+O3RhZz0yNzI2 Ngo+IAo+Pgo+IAo+PiAgVG86IDxzaXA6MTIzMTAxQDE5Mi4xNjguMTAwLjEwMDo1NTU1Pgo+IAo+ Pgo+IAo+PiAgQ2FsbC1JRDogMjQ2NThAMTkyLjE2OC4xMDAuMwo+IAo+Pgo+IAo+PiAgQ1NlcTog MjAgSU5WSVRFCj4gCj4+Cj4gCj4+ICBDb250YWN0OiA8c2lwOjEyMzEwMkAxOTIuMTY4LjEwMC4z OjUwNjA+Cj4gCj4+Cj4gCj4+ICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KPiAKPj4KPiAKPj4gIFRoZSBhYm92ZSAiSW52aXRl IiBtZXNzYWdlIGlzIG92ZXIgVURQLiBJbiB0aGUgVURQIHBhcnQgKFRyYW5zcG9ydAo+IAo+PiAg bGF5ZXIpLCB0aGUgRGVzdGluYXRpb24gcG9ydCBpcyA1NTU1LiBJbiB0aGUgU0lQIHBhcnQgKGFw cGxpY2F0aW9uCj4gCj4+ICBsYXllciksIHRoZSBwb3J0IGluIHRoZSAiSW52aXRlIiByZXF1ZXN0 LWxpbmUgVVJMIGlzIDU1NTUgdG9vLiBCb3RoIG9mCj4gCj4+ICB0aGVtIGFyZSBzYW1lLiBJbiB3 aGljaCBjYXNlIHRoZSBwb3J0IGluICJJbnZpdGUiIHJlcXVlc3QtbGluZSBVUkwgaXMKPiAKPj4g IGRpZmZlcmVudCBmcm9tIHRoZSBEZXN0aW5hdGlvbiBwb3J0IGluIGxvd2VyIGxheWVyIFVEUD8g RnVydGhlcm1vcmUsIGlmCj4gCj4+ICB0aGV5IGFyZSBhbHdheXMgc2FtZSB3aHkgd2UgaW5jbHVk ZSByZWR1bmRhbnQgaW5mb3JtYXRpb24gKHRoZSBwb3J0Cj4gCj4+ICBudW1iZXIpIGluICJJbnZp dGUiIHJlcXVlc3QtbGluZSBVUkw/IFdoYXQgaGFwcGVucyBpZiB0aGUgcG9ydCBpbgo+IAo+PiAg Ikludml0ZSIgcmVxdWVzdC1saW5lIFVSTCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgRGVzdGluYXRp b24gcG9ydCBpbgo+IAo+PiAgbG93ZXIgbGF5ZXIgVURQPwo+IAo+Pgo+IAo+PiAgVGhhbmsgeW91 IHZlcnkgbXVjaAo+IAo+Pgo+IAo+PiAgQmVzdCBSZWdhcmRzCj4gCj4+Cj4gCj4+ICBZdWFudGFv Cj4gCj4+Cj4gCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f ClNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90 b2NvbApVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBv biBjdXJyZW50IHNpcApVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBv biB0aGUgYXBwbGljYXRpb24gb2Ygc2lw From sip-bounces@ietf.org Mon Jun 9 14:31:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280063A6A55; Mon, 9 Jun 2008 14:31:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB183A6A55 for ; Mon, 9 Jun 2008 14:31:21 -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.163, 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 ZNH+Pc33rP-S for ; Mon, 9 Jun 2008 14:31:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D6F153A694F for ; Mon, 9 Jun 2008 14:31:20 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m59LVE8e008170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 9 Jun 2008 16:31:31 -0500 Message-Id: From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 16:31:05 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] Update on work plan for somain-certs and EKU X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Keith, Cullen, Scott, Vijay and I talked over the status of the domain- certs and EKU drafts this morning. Following teh conversation, we've agreed that as domain-certs is normatively updating RFC 326i, it will be a standards-track document. We've amended the charter milestones to reflect this: Change OLD Jan 2008 X.509 Certificates for TLS use in SIP to IESG (Info) to NEW Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) We've also revised the milestone date for the companion EKU document: Change date of: X.509 extended key usage for SIP to IESG (PS) to be Sep 2008 Thanks. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 9 19:21:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD2F3A6879; Mon, 9 Jun 2008 19:21:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AED23A6879 for ; Mon, 9 Jun 2008 19:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6vZ+28mq5hZ for ; Mon, 9 Jun 2008 19:21:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7B3713A67AD for ; Mon, 9 Jun 2008 19:21:49 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 33D4220B23; Tue, 10 Jun 2008 04:21:35 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-5c-484de52e4665 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ECBA1205BB; Tue, 10 Jun 2008 04:21:34 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 04:21:38 +0200 Received: from emyklmw102.eapac.ericsson.se ([150.236.92.102]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 04:21:36 +0200 Received: from ecnbjmw513.eapac.ericsson.se ([150.236.34.26]) by emyklmw102.eapac.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 10:19:48 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 10:19:47 +0800 Message-ID: In-Reply-To: <484D198B.1000004@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What is the port number in "Invite" request-line? Thanks Thread-Index: AcjKJ03gmJn83S1DQmCWB5iO4cPEbAAd0PVQ References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> <48492596.4010704@cisco.com> <484D198B.1000004@cisco.com> From: "Yuantao Zhang" To: "Paul Kyzivat" X-OriginalArrivalTime: 10 Jun 2008 02:19:48.0299 (UTC) FILETIME=[74C959B0:01C8CAA0] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, discussion@sipforum.org Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org RGVhciBQYXVsIAoKVGhhbmtzIGZvciBrZWVwaW5nIGFuc3dlcmluZyBteSBxdWVzdGlvbi4gQW5k IGl0IGlzIGhhcHB5IHRvIGRpc2N1c3Mgd2l0aCB5b3UuIENvdWxkIHlvdSBnaXZlIG1lIGEgc2Nl bmFyaW8gdGhhdCB0aGUgcG9ydCBudW1iZXIgaW4gUi1saW5lIGFuZCB0aGUgbG93ZXIgbGF5ZXIg VURQIGRlc3RpbmF0aW9uIHBvcnQgYXJlIGRpZmZlcmVudD8gVGhleSBhcmUgYWx3YXlzIHNhbWUs IGFyZW4ndCB0aGV5PyBUaGFua3MKCkJlc3QgcmVnYXJkcwpZdWFudGFvCgoKLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAY2lzY28u Y29tXSAKU2VudDogMjAwONK0NurFOeztIDE5OjUzClRvOiBZdWFudGFvIFpoYW5nCkNjOiBzaXBA aWV0Zi5vcmc7IGRpc2N1c3Npb25Ac2lwZm9ydW0ub3JnClN1YmplY3Q6IFJlOiBbU2lwXSBXaGF0 IGlzIHRoZSBwb3J0IG51bWJlciBpbiAiSW52aXRlIiByZXF1ZXN0LWxpbmU/IFRoYW5rcwoKT0ss IGlmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBhIGNhc2Ugd2l0aCBhIHByb3h5L3JlZ2lzdHJhciwg dGhlbiB3aGVuCnRoZSBwcm94eSBkb2VzIHRoZSB0cmFuc2xhdGlvbiwgaXQgZG9lcyBzbyBieSBi eSB0YWtraW5nIHRoZSBVUkkgdGhhdAp3YXMgcHJvdmlkZWQgaW4gUkVHSVNURVIgYW5kIHBsYWNp bmcgaXQgaW50byB0aGUgUi1VUkkuIFRoZW4gaXQgcm91dGVzCmJhc2VkIG9uIHRoZSByZXZpc2Vk IG1lc3NhZ2UuCgpUaGUgd2hvbGUgc3lzdGVtIG9mIHJvdXRpbmcgc2lwIG1lc3NhZ2VzIGlzIGJh c2VkIG9uIFVSSXMuIFRoZSBVUkkgKm1heSoKY29udGFpbiBhIHBvcnQsIG9yIHRoZSBwb3J0IG1h eSBiZSBkaXNjb3ZlcmVkIHVzaW5nIEROUy4KCkkgZ3Vlc3MgeW91IGFyZSBwcm9wb3Npbmcgc29t ZSBlbnRpcmVseSBkaWZmZXJlbnQgc3lzdGVtIGZvciBtYW5hZ2luZwp0aGUgcm91dGluZyBvZiBz aXAgbWVzc2FnZXMuIEJ1dCB5b3UgYXJlIDggb3IgOSB5ZWFycyB0b28gbGF0ZSBmb3IgdGhhdC4K CglUaGFua3MsCglQYXVsCgpZdWFudGFvIFpoYW5nIHdyb3RlOgo+IC0tLS0tLS0tLS0tLS0tLS0t LSAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0KPiAK PiB8VUExICAgICAgICAgICAgICB8ICAgICB8U0lQIHByb3h5ICAgICAgICAgIHwgICAgICAgICB8 VUEyICAgICAgICAgICAgICAgIHwKPiAKPiB8SVA6MTkyLjE2OC4xMDAuMXwtLS0tLXxJUDogMTky LjE2OC4xMDAuMiB8LS0tLS0tLS18SVA6IDE5Mi4xNjguMTAwLjMgfAo+IAo+IHxQb3J0OiAxMTEx ICAgICAgIHwgICAgIHxQb3J0OiAyMjIyICAgICAgICB8ICAgICAgICAgIHxQb3J0OiAzMzMzICAg ICAgICB8Cj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0g ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gSWYgVUExIG1ha2VzIGNhbGwgdG8gVUEy LCBVQTEgc2hvdWxkIHNlbmQgdGhlIGZvbGxvd2luZyBtZXNzYWdlIHRvIHRoZSAKPiBTSVAgcHJv eHk6Cj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Cj4gCj4gSVA6Cj4gCj4gU3JjOiAxOTIuMTY4LjEwMC4xCj4gCj4gRHN0 OiAxOTIuMTY4LjEwMC4yCj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gCj4gVURQOgo+IAo+IFNyYyBwb3J0OiAxMTEx Cj4gCj4gRHN0IHBvcnQ6IDIyMjIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICEKPiAKPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPiAKPiBTSVA6Cj4gCj4gSU5WSVRFIHNpcDpV QTJAMTkyLjE2OC4xMDAuMjoyMjIyIFNJUC8yLjAgICAgICAgICAgICAgICAgICAgICAgICAgICEK PiAKPiBWaWE6IFNJUC8yLjAvVURQIDE5Mi4xNjguMTAwLjE6MTExMTsKPiAKPiA9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPiAK PiAKPiBUaGVuIFNJUCBwcm94eSBzZW5kcyB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgdG8gVUEyOgo+ IAo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQo+IAo+IElQOgo+IAo+IFNyYzogMTkyLjE2OC4xMDAuMgo+IAo+IERzdDogMTky LjE2OC4xMDAuMwo+IAo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQo+IAo+IFVEUDoKPiAKPiBTcmMgcG9ydDogMjIyMgo+IAo+ IERzdCBwb3J0OiAzMzMzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAhCj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Cj4gCj4gU0lQOgo+IAo+IElOVklURSBzaXA6VUEyQDE5 Mi4xNjguMTAwLjI6MzMzMyBTSVAvMi4wICAgICAgICAgICAgICAgICAgICAgICAgICAhCj4gCj4g VmlhOiBTSVAvMi4wL1VEUCAxOTIuMTY4LjEwMC4yOjIyMjI7Cj4gCj4gVmlhOiBTSVAvMi4wL1VE UCAxOTIuMTY4LjEwMC4xOjExMTE7Cj4gCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gCj4gVUFDKFVBMSkgZG9lcyBub3Qg a25vdyB0aGUgcG9ydCBvZiBVQVMoVUEyKS4gQWxsIHRoZSBVQUMgbmVlZHMgdG8ga25vdyAKPiBp cyB0aGUgcHJveHkncyBwb3J0LiBBbmQgdGhlIHByb3h5IGtub3dzIGFsbCB0aGUgcG9ydHMgb2Yg VUFzIHVuZGVyIGl0IAo+IChVQXMgdGVsbCBwcm94eSB3aGVuIHJlZ2lzdGVyKS4gVGhlcmVmb3Jl LCB0aGUgcHJveHkgZG9lcyBub3QgY2FyZSB0aGUgCj4gcG9ydCBudW1iZXIgaW4gdGhlIHJlY2Vp dmVkICJJbnZpdGUiIHJlcXVlc3QtbGluZW4gKGJlY2F1c2UgdGhlIHBvcnQgCj4gbnVtYmVyIGlz IHByb3h5IGl0c2VsZikKPiAKPiBUaGVyZWZvcmUsIHRoZSBwb3J0IG51bWJlciBpbiB0aGUgIklu dml0ZSIgcmVxdWVzdC1saW5lIGlzIGFsd2F5cyBzYW1lIAo+IHdpdGggdGhlIHBvcnQgbnVtYmVy IGluIHRoZSBsb3dlciBsYXllciBVRFAuIFdoeSB3ZSBpbnNlcnQgcmVkdW5kYW50IAo+IGluZm9y bWF0aW9uPyBIb3cgYWJvdXQgd2UgZHJvcCB0aGlzIHJlZHVuZGFudCBhbmQgY29uZnVzaW5nIHBv cnQgbnVtYmVyIAo+IGluIHRoZSBVUkw/IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jvbmcu IFRoYW5rcy4KPiAKPiBCZXN0IHJlZ2FyZHMKPiAKPiBZdWFudGFvIFpoYW5nCj4gCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZh dEBjaXNjby5jb21dCj4gU2VudDogMjAwONK0NurFNuztIDE5OjU1Cj4gVG86IFl1YW50YW8gWmhh bmcKPiBDYzogQXR0aWxhIFNpcG9zOyBzaXBAaWV0Zi5vcmc7IGRpc2N1c3Npb25Ac2lwZm9ydW0u b3JnCj4gU3ViamVjdDogUmU6IFtTaXBdIFdoYXQgaXMgdGhlIHBvcnQgbnVtYmVyIGluICJJbnZp dGUiIHJlcXVlc3QtbGluZT8gVGhhbmtzCj4gCj4gVGhlIFVSSSB0eXBpY2FsbHkgZXhpc3RzIGJl Zm9yZSB0aGUgbWVzc2FnZSBpcyBjb25zdHJ1Y3RlZC4gVGhlbiBhCj4gCj4gbWVzc2FnZSBpcyBj b25zdHJ1Y3RlZCBhbmQgdGhlIFVSSSBpbmNsdWRlZCBpbiBpdC4gVGhlIFVSSSBzcGVjaWZpZXMK PiAKPiB3aGVyZSB0aGUgbWVzc2FnZSBpcyAqaW50ZW5kZWQqIHRvIGdvLiBBbmQgaXQgbWlnaHQg bm90IGdvIHRoZXJlCj4gCj4gaW1tZWRpYXRlbHkuIEluc3RlYWQgaXQgbWF5IGZpcnN0IGdvIHRv IGEgcHJveHkuIFdoZW4gaXQgZ2V0cyB0aGVyZSB0aGUKPiAKPiBwcm94eSBuZWVkcyB0byBjb25z dWx0IHRoZSBSLVVSSSB0byBrbm93IHdoZXJlIHRoZSBtZXNzYWdlIGlzIGludGVuZGVkCj4gCj4g dG8gZ28uCj4gCj4gV2hlbiB0aGUgbGFzdCBob3AgdG8gdGhlIGZpbmFsIGRlc3RpbmF0aW9uIGlz IG1hZGUgaXQgaXMgdHJ1ZSB0aGF0IHRoZQo+IAo+IHBvcnQgbnVtYmVyLCBhbmQgdGhlIGlwIGFk ZHJlc3MsIG1heSBiZSByZWR1bmRhbnQuIEJ1dCB3ZSBkb24ndCBleHBlY3QKPiAKPiB0aGUgaW50 ZXJtZWRpYXRlIG5vZGVzIHRvIHJlbW92ZSB0aGUgaW5mb3JtYXRpb24uIFRoZSByZWNpcGllbnQg bWF5IGRvCj4gCj4gYXMgaXQgd2lzaGVzIGlmIGl0IHJlY2VpdmVzIGEgcmVxdWVzdCB3aXRoIGFk ZHJlc3NpbmcgdGhhdCBpcwo+IAo+IGluY29uc2lzdGVudCB3aXRoIHdoZXJlIGl0IGlzIHJlY2Vp dmVkLgo+IAo+ICAgICAgICAgUGF1bAo+IAo+IFl1YW50YW8gWmhhbmcgd3JvdGU6Cj4gCj4+ICBE ZWFyIGFsbAo+IAo+Pgo+IAo+PiAgVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBQbGVhc2UgbGV0IG1l IGFzayBteSBxdWVzdGlvbiBpbiBhbm90aGVyIHdheS4KPiAKPj4KPiAKPj4gID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+IAo+ Pgo+IAo+PiAgVURQOgo+IAo+Pgo+IAo+PiAgU3JjIHBvcnQ6IDUwNjAKPiAKPj4KPiAKPj4gIERz dCBwb3J0OiA1NTU1ICAgICAgICAqqawtLS0tLS0tLS0tLS0KPiAKPj4KPiAKPj4gID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+ IAo+Pgo+IAo+PiAgU0lQOgo+IAo+Pgo+IAo+PiAgSU5WSVRFIHNpcDoxMjMxMDFAMTkyLjE2OC4x MDAuMTAwOjU1NTUgU0lQLzIuMCAgKqmsLS0tLS0tLS0tLS0tCj4gCj4+Cj4gCj4+ICBWaWE6IFNJ UC8yLjAvVURQIDE5Mi4xNjguMTAwLjM6NTA2MDtycG9ydDticmFuY2g9ejloRzRiSzI3MTk1Cj4g Cj4+Cj4gCj4+ICBGcm9tOiA8c2lwOjEyMzEwMkAxOTIuMTY4LjEwMC4xMDA+O3RhZz0yNzI2Ngo+ IAo+Pgo+IAo+PiAgVG86IDxzaXA6MTIzMTAxQDE5Mi4xNjguMTAwLjEwMDo1NTU1Pgo+IAo+Pgo+ IAo+PiAgQ2FsbC1JRDogMjQ2NThAMTkyLjE2OC4xMDAuMwo+IAo+Pgo+IAo+PiAgQ1NlcTogMjAg SU5WSVRFCj4gCj4+Cj4gCj4+ICBDb250YWN0OiA8c2lwOjEyMzEwMkAxOTIuMTY4LjEwMC4zOjUw NjA+Cj4gCj4+Cj4gCj4+ICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KPiAKPj4KPiAKPj4gIFRoZSBhYm92ZSAiSW52aXRlIiBt ZXNzYWdlIGlzIG92ZXIgVURQLiBJbiB0aGUgVURQIHBhcnQgKFRyYW5zcG9ydAo+IAo+PiAgbGF5 ZXIpLCB0aGUgRGVzdGluYXRpb24gcG9ydCBpcyA1NTU1LiBJbiB0aGUgU0lQIHBhcnQgKGFwcGxp Y2F0aW9uCj4gCj4+ICBsYXllciksIHRoZSBwb3J0IGluIHRoZSAiSW52aXRlIiByZXF1ZXN0LWxp bmUgVVJMIGlzIDU1NTUgdG9vLiBCb3RoIG9mCj4gCj4+ICB0aGVtIGFyZSBzYW1lLiBJbiB3aGlj aCBjYXNlIHRoZSBwb3J0IGluICJJbnZpdGUiIHJlcXVlc3QtbGluZSBVUkwgaXMKPiAKPj4gIGRp ZmZlcmVudCBmcm9tIHRoZSBEZXN0aW5hdGlvbiBwb3J0IGluIGxvd2VyIGxheWVyIFVEUD8gRnVy dGhlcm1vcmUsIGlmCj4gCj4+ICB0aGV5IGFyZSBhbHdheXMgc2FtZSB3aHkgd2UgaW5jbHVkZSBy ZWR1bmRhbnQgaW5mb3JtYXRpb24gKHRoZSBwb3J0Cj4gCj4+ICBudW1iZXIpIGluICJJbnZpdGUi IHJlcXVlc3QtbGluZSBVUkw/IFdoYXQgaGFwcGVucyBpZiB0aGUgcG9ydCBpbgo+IAo+PiAgIklu dml0ZSIgcmVxdWVzdC1saW5lIFVSTCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgRGVzdGluYXRpb24g cG9ydCBpbgo+IAo+PiAgbG93ZXIgbGF5ZXIgVURQPwo+IAo+Pgo+IAo+PiAgVGhhbmsgeW91IHZl cnkgbXVjaAo+IAo+Pgo+IAo+PiAgQmVzdCBSZWdhcmRzCj4gCj4+Cj4gCj4+ICBZdWFudGFvCj4g Cj4+Cj4gCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClNp cCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw ClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2Nv bApVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBj dXJyZW50IHNpcApVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0 aGUgYXBwbGljYXRpb24gb2Ygc2lw From sip-bounces@ietf.org Tue Jun 10 01:13:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FED43A695D; Tue, 10 Jun 2008 01:13:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75C13A695D for ; Tue, 10 Jun 2008 01:13:08 -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 Xr3thnBQ0q8J for ; Tue, 10 Jun 2008 01:13:08 -0700 (PDT) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by core3.amsl.com (Postfix) with ESMTP id B13A73A6840 for ; Tue, 10 Jun 2008 01:13:07 -0700 (PDT) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20080610081742.WILE7070.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Tue, 10 Jun 2008 09:17:42 +0100 Received: from darjeeling.procter.org.uk ([81.104.240.101]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20080610082230.BIBX8797.aamtaout03-winn.ispmail.ntl.com@darjeeling.procter.org.uk>; Tue, 10 Jun 2008 09:22:30 +0100 Received: from localhost ([127.0.0.1] helo=webmail.procter.org.uk ident=www-data) by darjeeling.procter.org.uk with esmtp (Exim 4.50) id 1K5yyi-0001ni-Kd; Tue, 10 Jun 2008 09:13:16 +0100 Received: from 87.194.179.229 (SquirrelMail authenticated user michael) by webmail.procter.org.uk with HTTP; Tue, 10 Jun 2008 09:13:16 +0100 (BST) Message-ID: <1680.87.194.179.229.1213085596.squirrel@webmail.procter.org.uk> In-Reply-To: References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> <48492596.4010704@cisco.com> <484D198B.1000004@cisco.com> Date: Tue, 10 Jun 2008 09:13:16 +0100 (BST) From: "Michael Procter" To: "Yuantao Zhang" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: sip@ietf.org, Paul Kyzivat , discussion@sipforum.org Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, June 10, 2008 3:19 am, Yuantao Zhang wrote: > Dear Paul > > Thanks for keeping answering my question. And it is happy to discuss with > you. Could you give me a scenario that the port number in R-line and the > lower layer UDP destination port are different? They are always same, > aren't they? Thanks No. Look up 'Loose Routing' in RFC3261 (section 12.2.1.1 may help you). A request may be sent to destination other than the one indicated by the Request-URI. This may or may not involve different port numbers. Regards, Michael _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 01:56:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90063A67DB; Tue, 10 Jun 2008 01:56:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2953A6765 for ; Tue, 10 Jun 2008 01:56:05 -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 xhyOYr07bCZY for ; Tue, 10 Jun 2008 01:56:01 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 563193A67DB for ; Tue, 10 Jun 2008 01:56:01 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5A8tp34017239; Tue, 10 Jun 2008 11:56:15 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 11:55:46 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 11:55:45 +0300 Received: from [172.21.36.166] (esdhcp036166.research.nokia.com [172.21.36.166]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5A8tix8024820; Tue, 10 Jun 2008 11:55:44 +0300 From: Aki Niemi To: ext cco In-Reply-To: <20080608200846.GA6325@shell> References: <20080606093036.GA4685@shell> <48494E97.2010108@fokus.fraunhofer.de> <20080608200846.GA6325@shell> Organization: Nokia Devices R&D Date: Tue, 10 Jun 2008 11:55:43 +0300 Message-Id: <1213088143.9973.5.camel@little.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-OriginalArrivalTime: 10 Jun 2008 08:55:45.0651 (UTC) FILETIME=[C5459430:01C8CAD7] X-Nokia-AV: Clean Cc: sip@ietf.org, Dragos Vingarzan Subject: Re: [Sip] aka authentication and sip (rfc 3310) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org su, 2008-06-08 kello 22:08 +0200, ext cco kirjoitti: > now, the call flows given as an example would function when the > challenge (nonce) does not explicitly depend on the user which is > actually trying to register itself, being generated > (periodically) by the sip proxy itself; that is they are o.k. for an > HTTP digest MD5 auth. as spec. in rfc 3261/rfc 2617. but they do NOT seem to > function in the real world when AKA is used, because: > > 1. the challenge is user specific. > 2. the "network" authenticates itself to the UE as well in case of AKA. In an environment with plain RFC3310, an extra round trip would be required. The main user of this spec, namely 3GPP fixes this by requiring the presence of the Authorization field in the initial REGISTER. Cheers, Aki _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.tippmann@seasell.com Tue Jun 10 02:02:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6833A69E0; Tue, 10 Jun 2008 02:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.291 X-Spam-Level: X-Spam-Status: No, score=-45.291 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, SARE_SPEC_ROLEX_SEL=2.222, TVD_RCVD_IP=1.931, 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 9w8Zs41eej5z; Tue, 10 Jun 2008 02:02:30 -0700 (PDT) Received: from 230-127-17-190.fibertel.com.ar (230-127-17-190.fibertel.com.ar [190.17.127.230]) by core3.amsl.com (Postfix) with SMTP id 2CD1B3A69BB; Tue, 10 Jun 2008 02:02:01 -0700 (PDT) X-Originating-IP: 103.220.236.162 by smtp.190.17.127.230; Tue, 10 Jun 2008 05:02:20 -0500 Message-ID: From: "Corrine Cervantes" Reply-To: "Corrine Cervantes" To: send-archive@ietf.org Subject: Affordable replica watches Date: Tue, 10 Jun 2008 05:02:20 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Looking for superior quality replica watches? Then welcome to the newly redesigned Prestige Replicas, home of the best reproduction Rolex Sportmodel watches on the whole web! Prestige Replicas offers a tremendous selection of Rolex replica timepieces for both men and women, all of them featuring the original manufacturer markings along with a myriad of details that make these watches look so much like the brand new Rolexes that even the experts are having a hard time differentiating them! http://zekukamexys85.blogspot.com/ So, come visit Prestige Replicas and enjoy not only the most beautiful Rolex Sportmodel replica watches at unbelievable prices, but also get an extra 15% off when you buy two! http://zekukamexys85.blogspot.com/ From sip-bounces@ietf.org Tue Jun 10 03:00:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30913A68E1; Tue, 10 Jun 2008 03:00:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834993A6873 for ; Tue, 10 Jun 2008 03:00:09 -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=[AWL=-0.001, 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 MWJN-5QojDhq for ; Tue, 10 Jun 2008 03:00:06 -0700 (PDT) Received: from outbound.mse16.exchange.ms (outbound.mse16.exchange.ms [64.71.238.252]) by core3.amsl.com (Postfix) with ESMTP id D557B3A68E1 for ; Tue, 10 Jun 2008 03:00:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 06:00:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INAP - SIP conversion Thread-Index: AcjK4M2nZI/iVNi3R0mljx2F3oPSew== From: "Lukas Alig" To: Subject: [Sip] INAP - SIP conversion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1008524153==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1008524153== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CAE0.CEB007D4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CAE0.CEB007D4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 Can anybody help me which RFCs / TSs specifies SIP - INAP conversion. =20 Thanks =20 Lukas Alig Technical Consultant =20 NewNet Communication Technologies, LLC Phone/VoIP: +41 43 544 07 19 Fax: +41 41 790 40 39 e-mail: Lukas.Alig@newnet.com =20 Office: Floraweg 5 CH-6343 Buonas Switzerland Notice to Recipient: This e-mail is confidential and meant only for the intended recipient[s] of the transmission=20 and may be a communication privileged by law. =20 If you received this e-mail in error, any review, use, dissemination, distribution or copying of this e-mail is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and please delete=20 this e-mail from your system and destroy any copies. =20 ------_=_NextPart_001_01C8CAE0.CEB007D4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

Can anybody help me which RFCs / TSs specifies SIP – INAP = conversion.

 

Thanks

 

Lukas Alig

Technical Consultant

 

NewNet Communication Technologies, LLC

Phone/VoIP: +41 43 544 07 19
Fax: +41 41 790 40 39
e-mail: Lukas.Alig@newnet.com

Office: Floraweg 5
CH-6343 Buonas

Switzerland
Notice to Recipient:  This e-mail is confidential and meant only for the = intended recipient[s] of the transmission

and may be a communication privileged by law. 

If you received this e-mail in error, any review, use, dissemination, = distribution or copying of this e-mail is strictly

 prohibit= ed.  If you are not the intended recipient, please contact the sender by = reply e-mail and please delete

this e-mail from your system and destroy any copies.


 

------_=_NextPart_001_01C8CAE0.CEB007D4-- --===============1008524153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1008524153==-- From sip-bounces@ietf.org Tue Jun 10 03:27:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369853A69BB; Tue, 10 Jun 2008 03:27:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAF83A69C7 for ; Tue, 10 Jun 2008 03:27:06 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VcC9fbgv+JF for ; Tue, 10 Jun 2008 03:27:05 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E6D643A69AA for ; Tue, 10 Jun 2008 03:27:04 -0700 (PDT) Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id C17921811582; Tue, 10 Jun 2008 12:27:24 +0200 (CEST) Received: by shell.iptel.org (sSMTP sendmail emulation); Tue, 10 Jun 2008 12:27:24 +0200 Date: Tue, 10 Jun 2008 12:27:24 +0200 From: cco To: Aki Niemi Message-ID: <20080610102724.GE4685@shell> References: <20080606093036.GA4685@shell> <48494E97.2010108@fokus.fraunhofer.de> <20080608200846.GA6325@shell> <1213088143.9973.5.camel@little.research.nokia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1213088143.9973.5.camel@little.research.nokia.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sip@ietf.org, Dragos Vingarzan Subject: Re: [Sip] aka authentication and sip (rfc 3310) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, Jun 10, 2008 at 11:55:43AM +0300, Aki Niemi wrote: > su, 2008-06-08 kello 22:08 +0200, ext cco kirjoitti: > > now, the call flows given as an example would function when the > > challenge (nonce) does not explicitly depend on the user which is > > actually trying to register itself, being generated > > (periodically) by the sip proxy itself; that is they are o.k. for an > > HTTP digest MD5 auth. as spec. in rfc 3261/rfc 2617. but they do NOT seem to > > function in the real world when AKA is used, because: > > > > 1. the challenge is user specific. > > 2. the "network" authenticates itself to the UE as well in case of AKA. > > In an environment with plain RFC3310, an extra round trip would be > required. The main user of this spec, namely 3GPP fixes this by cristian: hi. aki, thanks a lot for the reply. I still have some questions though. lets take it one step at a time. "an extra round trip would be required" means that the call flow given as an example in the rfc lacks that round trip, right? why? > requiring the presence of the Authorization field in the initial > REGISTER. cristian: why not specifying this in the rfc as well? now, as I see it, the problem is that a lot of ue sip stacks implementors would take the rfc word for word and implement their software exactly how it is specified in the rfc. and in the end, everyone will wonder why the call flow in rfc3310 does not work or when it works it looks quite differently... bye now! cristian _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 05:05:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AF23A68E1; Tue, 10 Jun 2008 05:05:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22AB3A68E1 for ; Tue, 10 Jun 2008 05:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 5kPzHzVmbzhH for ; Tue, 10 Jun 2008 05:05:38 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7DE763A67F5 for ; Tue, 10 Jun 2008 05:05:38 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 36C5B2111A for ; Tue, 10 Jun 2008 14:05:59 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-88-484e6e26ea4c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DAB2A209B1 for ; Tue, 10 Jun 2008 14:05:58 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 14:06:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 14:01:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft revision: draft-holmberg-sip-keep-01.txt Thread-Index: AcjK8adH7W0ttWE4SbWjTIJDpHIm1g== From: "Christer Holmberg" To: X-OriginalArrivalTime: 10 Jun 2008 12:06:03.0439 (UTC) FILETIME=[5ACDC3F0:01C8CAF2] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] Draft revision: draft-holmberg-sip-keep-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I've submitted a new version (-01) of the keep draft. I can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-keep-01.txt The major differences from the previous version are: - I added text (chapter 8), provided by Vijay, which describes the relationship with connection reuse - I added a Note (chapter 5), based on the comments from Juha, about usage of CRLF keep-alives even if there are no explicit indication. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 05:50:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A113A6AC0; Tue, 10 Jun 2008 05:50:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1DE3A6AA3 for ; Tue, 10 Jun 2008 05:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.308 X-Spam-Level: X-Spam-Status: No, score=-5.308 tagged_above=-999 required=5 tests=[AWL=-1.159, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTYo2XDs5jxt for ; Tue, 10 Jun 2008 05:49:59 -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 1584F3A6B21 for ; Tue, 10 Jun 2008 05:49:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,617,1204520400"; d="scan'208";a="10604174" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2008 08:50:20 -0400 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 m5ACoJC4010479; Tue, 10 Jun 2008 08:50:19 -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.13.8) with ESMTP id m5ACoJ9v026898; Tue, 10 Jun 2008 12:50:19 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.1830); Tue, 10 Jun 2008 08:50:19 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 08:50:18 -0400 Message-ID: <484E78B5.9090702@cisco.com> Date: Tue, 10 Jun 2008 08:51:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Yuantao Zhang References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> <48492596.4010704@cisco.com> <484D198B.1000004@cisco.com> In-Reply-To: X-OriginalArrivalTime: 10 Jun 2008 12:50:18.0976 (UTC) FILETIME=[89A08E00:01C8CAF8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6468; t=1213102219; x=1213966219; 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[Sip]=20What=20is=20the=20port=20number =20in=20=22Invite=22=20request-line?=20Thanks |Sender:=20 |To:=20Yuantao=20Zhang=20; bh=hZJDme1z7KoTX/5nzrFuDk5GU915akvscbNufJK3lVA=; b=G+eGmoLDVSv7UxHD+P7U9J/g15asfDgwmPNiNFT8O40qXj5kC/X83n2JIu z4Wh8wWE1KeSwtunmJECXfszDLdPfXSxkVRZZZL1XgowkuSUPCznQp6BwXjS A9ITWJ/tcs; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, discussion@sipforum.org Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org CgpZdWFudGFvIFpoYW5nIHdyb3RlOgo+IERlYXIgUGF1bCAKPiAKPiBUaGFua3MgZm9yIGtlZXBp bmcgYW5zd2VyaW5nIG15IHF1ZXN0aW9uLiBBbmQgaXQgaXMgaGFwcHkgdG8gZGlzY3VzcyB3aXRo IHlvdS4gQ291bGQgeW91IGdpdmUgbWUgYSBzY2VuYXJpbyB0aGF0IHRoZSBwb3J0IG51bWJlciBp biBSLWxpbmUgYW5kIHRoZSBsb3dlciBsYXllciBVRFAgZGVzdGluYXRpb24gcG9ydCBhcmUgZGlm ZmVyZW50PyBUaGV5IGFyZSBhbHdheXMgc2FtZSwgYXJlbid0IHRoZXk/IFRoYW5rcwoKWWVzIG9m IGNvdXJzZSBJIGNhbiBnaXZlIGFuIGV4YW1wbGUuIElmIHRoZSBtZXNzYWdlIGNvbnRhaW5zIGEg Um91dGUKaGVhZGVyLCB0aGVuIGl0IHdpbGwgYmUgc2VudCB0byB0aGUgYWRkcmVzcyAoYW5kIHBv cnQgaWYgcHJlc2VudCkgaW4gdGhlCnRvcCBSb3V0ZSBoZWFkZXIuIE1lYW53aGlsZSB0aGUgYWRk cmVzcyAoYW5kIHBvcnQpIGluIHRoZSBSLVVSSSByZW1haW4sCmFuZCB3aWxsICpldmVudHVhbGx5 KiBiZSB1c2VkIHRvIHJvdXRlIHRoZSBtZXNzYWdlIHdoZW4gdGhlIFJvdXRlIGhlYWRlcgpoYXMg YmVlbiBleGhhdXN0ZWQuCgoJUGF1bAoKPiBCZXN0IHJlZ2FyZHMKPiBZdWFudGFvCj4gCj4gCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpw a3l6aXZhdEBjaXNjby5jb21dIAo+IFNlbnQ6IDIwMDjStDbqxTns7SAxOTo1Mwo+IFRvOiBZdWFu dGFvIFpoYW5nCj4gQ2M6IHNpcEBpZXRmLm9yZzsgZGlzY3Vzc2lvbkBzaXBmb3J1bS5vcmcKPiBT dWJqZWN0OiBSZTogW1NpcF0gV2hhdCBpcyB0aGUgcG9ydCBudW1iZXIgaW4gIkludml0ZSIgcmVx dWVzdC1saW5lPyBUaGFua3MKPiAKPiBPSywgaWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGEgY2Fz ZSB3aXRoIGEgcHJveHkvcmVnaXN0cmFyLCB0aGVuIHdoZW4KPiB0aGUgcHJveHkgZG9lcyB0aGUg dHJhbnNsYXRpb24sIGl0IGRvZXMgc28gYnkgYnkgdGFra2luZyB0aGUgVVJJIHRoYXQKPiB3YXMg cHJvdmlkZWQgaW4gUkVHSVNURVIgYW5kIHBsYWNpbmcgaXQgaW50byB0aGUgUi1VUkkuIFRoZW4g aXQgcm91dGVzCj4gYmFzZWQgb24gdGhlIHJldmlzZWQgbWVzc2FnZS4KPiAKPiBUaGUgd2hvbGUg c3lzdGVtIG9mIHJvdXRpbmcgc2lwIG1lc3NhZ2VzIGlzIGJhc2VkIG9uIFVSSXMuIFRoZSBVUkkg Km1heSoKPiBjb250YWluIGEgcG9ydCwgb3IgdGhlIHBvcnQgbWF5IGJlIGRpc2NvdmVyZWQgdXNp bmcgRE5TLgo+IAo+IEkgZ3Vlc3MgeW91IGFyZSBwcm9wb3Npbmcgc29tZSBlbnRpcmVseSBkaWZm ZXJlbnQgc3lzdGVtIGZvciBtYW5hZ2luZwo+IHRoZSByb3V0aW5nIG9mIHNpcCBtZXNzYWdlcy4g QnV0IHlvdSBhcmUgOCBvciA5IHllYXJzIHRvbyBsYXRlIGZvciB0aGF0Lgo+IAo+IAlUaGFua3Ms Cj4gCVBhdWwKPiAKPiBZdWFudGFvIFpoYW5nIHdyb3RlOgo+PiAtLS0tLS0tLS0tLS0tLS0tLS0g ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tCj4+Cj4+ IHxVQTEgICAgICAgICAgICAgIHwgICAgIHxTSVAgcHJveHkgICAgICAgICAgfCAgICAgICAgIHxV QTIgICAgICAgICAgICAgICAgfAo+Pgo+PiB8SVA6MTkyLjE2OC4xMDAuMXwtLS0tLXxJUDogMTky LjE2OC4xMDAuMiB8LS0tLS0tLS18SVA6IDE5Mi4xNjguMTAwLjMgfAo+Pgo+PiB8UG9ydDogMTEx MSAgICAgICB8ICAgICB8UG9ydDogMjIyMiAgICAgICAgfCAgICAgICAgICB8UG9ydDogMzMzMyAg ICAgICAgfAo+Pgo+PiAtLS0tLS0tLS0tLS0tLS0tLS0gICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LSAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0KPj4KPj4gSWYgVUExIG1ha2VzIGNhbGwgdG8g VUEyLCBVQTEgc2hvdWxkIHNlbmQgdGhlIGZvbGxvd2luZyBtZXNzYWdlIHRvIHRoZSAKPj4gU0lQ IHByb3h5Ogo+Pgo+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KPj4KPj4gSVA6Cj4+Cj4+IFNyYzogMTkyLjE2OC4xMDAuMQo+ Pgo+PiBEc3Q6IDE5Mi4xNjguMTAwLjIKPj4KPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+Cj4+IFVEUDoKPj4KPj4gU3Jj IHBvcnQ6IDExMTEKPj4KPj4gRHN0IHBvcnQ6IDIyMjIgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICEKPj4KPj4gPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+Cj4+IFNJUDoKPj4K Pj4gSU5WSVRFIHNpcDpVQTJAMTkyLjE2OC4xMDAuMjoyMjIyIFNJUC8yLjAgICAgICAgICAgICAg ICAgICAgICAgICAgICEKPj4KPj4gVmlhOiBTSVAvMi4wL1VEUCAxOTIuMTY4LjEwMC4xOjExMTE7 Cj4+Cj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQo+Pgo+Pgo+PiBUaGVuIFNJUCBwcm94eSBzZW5kcyB0aGUgZm9sbG93aW5n IG1lc3NhZ2UgdG8gVUEyOgo+Pgo+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPj4KPj4gSVA6Cj4+Cj4+IFNyYzogMTkyLjE2 OC4xMDAuMgo+Pgo+PiBEc3Q6IDE5Mi4xNjguMTAwLjMKPj4KPj4gPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+Cj4+IFVEUDoK Pj4KPj4gU3JjIHBvcnQ6IDIyMjIKPj4KPj4gRHN0IHBvcnQ6IDMzMzMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICEKPj4KPj4gPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+Cj4+ IFNJUDoKPj4KPj4gSU5WSVRFIHNpcDpVQTJAMTkyLjE2OC4xMDAuMjozMzMzIFNJUC8yLjAgICAg ICAgICAgICAgICAgICAgICAgICAgICEKPj4KPj4gVmlhOiBTSVAvMi4wL1VEUCAxOTIuMTY4LjEw MC4yOjIyMjI7Cj4+Cj4+IFZpYTogU0lQLzIuMC9VRFAgMTkyLjE2OC4xMDAuMToxMTExOwo+Pgo+ PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KPj4KPj4gVUFDKFVBMSkgZG9lcyBub3Qga25vdyB0aGUgcG9ydCBvZiBVQVMoVUEy KS4gQWxsIHRoZSBVQUMgbmVlZHMgdG8ga25vdyAKPj4gaXMgdGhlIHByb3h5J3MgcG9ydC4gQW5k IHRoZSBwcm94eSBrbm93cyBhbGwgdGhlIHBvcnRzIG9mIFVBcyB1bmRlciBpdCAKPj4gKFVBcyB0 ZWxsIHByb3h5IHdoZW4gcmVnaXN0ZXIpLiBUaGVyZWZvcmUsIHRoZSBwcm94eSBkb2VzIG5vdCBj YXJlIHRoZSAKPj4gcG9ydCBudW1iZXIgaW4gdGhlIHJlY2VpdmVkICJJbnZpdGUiIHJlcXVlc3Qt bGluZW4gKGJlY2F1c2UgdGhlIHBvcnQgCj4+IG51bWJlciBpcyBwcm94eSBpdHNlbGYpCj4+Cj4+ IFRoZXJlZm9yZSwgdGhlIHBvcnQgbnVtYmVyIGluIHRoZSAiSW52aXRlIiByZXF1ZXN0LWxpbmUg aXMgYWx3YXlzIHNhbWUgCj4+IHdpdGggdGhlIHBvcnQgbnVtYmVyIGluIHRoZSBsb3dlciBsYXll ciBVRFAuIFdoeSB3ZSBpbnNlcnQgcmVkdW5kYW50IAo+PiBpbmZvcm1hdGlvbj8gSG93IGFib3V0 IHdlIGRyb3AgdGhpcyByZWR1bmRhbnQgYW5kIGNvbmZ1c2luZyBwb3J0IG51bWJlciAKPj4gaW4g dGhlIFVSTD8gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy4gVGhhbmtzLgo+Pgo+PiBC ZXN0IHJlZ2FyZHMKPj4KPj4gWXVhbnRhbyBaaGFuZwo+Pgo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQo+PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5jb21d Cj4+IFNlbnQ6IDIwMDjStDbqxTbs7SAxOTo1NQo+PiBUbzogWXVhbnRhbyBaaGFuZwo+PiBDYzog QXR0aWxhIFNpcG9zOyBzaXBAaWV0Zi5vcmc7IGRpc2N1c3Npb25Ac2lwZm9ydW0ub3JnCj4+IFN1 YmplY3Q6IFJlOiBbU2lwXSBXaGF0IGlzIHRoZSBwb3J0IG51bWJlciBpbiAiSW52aXRlIiByZXF1 ZXN0LWxpbmU/IFRoYW5rcwo+Pgo+PiBUaGUgVVJJIHR5cGljYWxseSBleGlzdHMgYmVmb3JlIHRo ZSBtZXNzYWdlIGlzIGNvbnN0cnVjdGVkLiBUaGVuIGEKPj4KPj4gbWVzc2FnZSBpcyBjb25zdHJ1 Y3RlZCBhbmQgdGhlIFVSSSBpbmNsdWRlZCBpbiBpdC4gVGhlIFVSSSBzcGVjaWZpZXMKPj4KPj4g d2hlcmUgdGhlIG1lc3NhZ2UgaXMgKmludGVuZGVkKiB0byBnby4gQW5kIGl0IG1pZ2h0IG5vdCBn byB0aGVyZQo+Pgo+PiBpbW1lZGlhdGVseS4gSW5zdGVhZCBpdCBtYXkgZmlyc3QgZ28gdG8gYSBw cm94eS4gV2hlbiBpdCBnZXRzIHRoZXJlIHRoZQo+Pgo+PiBwcm94eSBuZWVkcyB0byBjb25zdWx0 IHRoZSBSLVVSSSB0byBrbm93IHdoZXJlIHRoZSBtZXNzYWdlIGlzIGludGVuZGVkCj4+Cj4+IHRv IGdvLgo+Pgo+PiBXaGVuIHRoZSBsYXN0IGhvcCB0byB0aGUgZmluYWwgZGVzdGluYXRpb24gaXMg bWFkZSBpdCBpcyB0cnVlIHRoYXQgdGhlCj4+Cj4+IHBvcnQgbnVtYmVyLCBhbmQgdGhlIGlwIGFk ZHJlc3MsIG1heSBiZSByZWR1bmRhbnQuIEJ1dCB3ZSBkb24ndCBleHBlY3QKPj4KPj4gdGhlIGlu dGVybWVkaWF0ZSBub2RlcyB0byByZW1vdmUgdGhlIGluZm9ybWF0aW9uLiBUaGUgcmVjaXBpZW50 IG1heSBkbwo+Pgo+PiBhcyBpdCB3aXNoZXMgaWYgaXQgcmVjZWl2ZXMgYSByZXF1ZXN0IHdpdGgg YWRkcmVzc2luZyB0aGF0IGlzCj4+Cj4+IGluY29uc2lzdGVudCB3aXRoIHdoZXJlIGl0IGlzIHJl Y2VpdmVkLgo+Pgo+PiAgICAgICAgIFBhdWwKPj4KPj4gWXVhbnRhbyBaaGFuZyB3cm90ZToKPj4K Pj4+ICBEZWFyIGFsbAo+Pj4gIFRoYW5rcyBmb3IgeW91ciByZXBseS4gUGxlYXNlIGxldCBtZSBh c2sgbXkgcXVlc3Rpb24gaW4gYW5vdGhlciB3YXkuCj4+PiAgPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+PiAgVURQOgo+Pj4g IFNyYyBwb3J0OiA1MDYwCj4+PiAgRHN0IHBvcnQ6IDU1NTUgICAgICAgICqprC0tLS0tLS0tLS0t LQo+Pj4gID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQo+Pj4gIFNJUDoKPj4+ICBJTlZJVEUgc2lwOjEyMzEwMUAxOTIuMTY4LjEw MC4xMDA6NTU1NSBTSVAvMi4wICAqqawtLS0tLS0tLS0tLS0KPj4+ICBWaWE6IFNJUC8yLjAvVURQ IDE5Mi4xNjguMTAwLjM6NTA2MDtycG9ydDticmFuY2g9ejloRzRiSzI3MTk1Cj4+PiAgRnJvbTog PHNpcDoxMjMxMDJAMTkyLjE2OC4xMDAuMTAwPjt0YWc9MjcyNjYKPj4+ICBUbzogPHNpcDoxMjMx MDFAMTkyLjE2OC4xMDAuMTAwOjU1NTU+Cj4+PiAgQ2FsbC1JRDogMjQ2NThAMTkyLjE2OC4xMDAu Mwo+Pj4gIENTZXE6IDIwIElOVklURQo+Pj4gIENvbnRhY3Q6IDxzaXA6MTIzMTAyQDE5Mi4xNjgu MTAwLjM6NTA2MD4KPj4+ICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KPj4+ICBUaGUgYWJvdmUgIkludml0ZSIgbWVzc2FnZSBp cyBvdmVyIFVEUC4gSW4gdGhlIFVEUCBwYXJ0IChUcmFuc3BvcnQKPj4+ICBsYXllciksIHRoZSBE ZXN0aW5hdGlvbiBwb3J0IGlzIDU1NTUuIEluIHRoZSBTSVAgcGFydCAoYXBwbGljYXRpb24KPj4+ ICBsYXllciksIHRoZSBwb3J0IGluIHRoZSAiSW52aXRlIiByZXF1ZXN0LWxpbmUgVVJMIGlzIDU1 NTUgdG9vLiBCb3RoIG9mCj4+PiAgdGhlbSBhcmUgc2FtZS4gSW4gd2hpY2ggY2FzZSB0aGUgcG9y dCBpbiAiSW52aXRlIiByZXF1ZXN0LWxpbmUgVVJMIGlzCj4+PiAgZGlmZmVyZW50IGZyb20gdGhl IERlc3RpbmF0aW9uIHBvcnQgaW4gbG93ZXIgbGF5ZXIgVURQPyBGdXJ0aGVybW9yZSwgaWYKPj4+ ICB0aGV5IGFyZSBhbHdheXMgc2FtZSB3aHkgd2UgaW5jbHVkZSByZWR1bmRhbnQgaW5mb3JtYXRp b24gKHRoZSBwb3J0Cj4+PiAgbnVtYmVyKSBpbiAiSW52aXRlIiByZXF1ZXN0LWxpbmUgVVJMPyBX aGF0IGhhcHBlbnMgaWYgdGhlIHBvcnQgaW4KPj4+ICAiSW52aXRlIiByZXF1ZXN0LWxpbmUgVVJM IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBEZXN0aW5hdGlvbiBwb3J0IGluCj4+PiAgbG93ZXIgbGF5 ZXIgVURQPwo+Pj4gIFRoYW5rIHlvdSB2ZXJ5IG11Y2gKPj4+ICBCZXN0IFJlZ2FyZHMKPj4+ICBZ dWFudGFvCj4gCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f ClNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90 b2NvbApVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBv biBjdXJyZW50IHNpcApVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBv biB0aGUgYXBwbGljYXRpb24gb2Ygc2lw From sip-bounces@ietf.org Tue Jun 10 06:36:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA793A6B3F; Tue, 10 Jun 2008 06:36:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A01B3A6993 for ; Tue, 10 Jun 2008 06:36: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 hjvgXNSjuiXc for ; Tue, 10 Jun 2008 06:35:59 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 884DC3A6C62 for ; Tue, 10 Jun 2008 06:35:47 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2625197rvf.49 for ; Tue, 10 Jun 2008 06:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xoG7E41ZdHSamP667FaMJsMAG9Y6oPwDDuDKHV6UQyM=; b=jS39jQb3m8LfjgK7IerZN1EG5Cu+8mHjqS/u+1TRbIV7iQGzc3l3dCEdNKGcHqViN+ 6Cwp/EnX37Hs/YR3hTrcGPiQx6Ks9BlEIbrOfGNzx4/n5tOy9JrkDekPSnikhOBncoo0 SoUEffFE94c/4Tq4cy+TuwZDT99nXemuLy5qA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PUwoW/PI+pXHnJkV+Zp8W02uim01ohcJTqz+cKmiZU5Vy131pfbGlEaM43i4UYW5gI POF6RjarS80McPd7k2ba42p8JctCvq5MzE3bLQdaZRoHrGxr7hkEVTrquNJlstMtxHrU tj/5gfx3Qj1yYHzGkPSIzQ3UdkneTWgq4Or7A= Received: by 10.141.170.10 with SMTP id x10mr2981164rvo.139.1213104969755; Tue, 10 Jun 2008 06:36:09 -0700 (PDT) Received: by 10.140.201.14 with HTTP; Tue, 10 Jun 2008 06:36:09 -0700 (PDT) Message-ID: <641c14980806100636s1c733cb5yf7fc02de531f0b78@mail.gmail.com> Date: Tue, 10 Jun 2008 19:06:09 +0530 From: "Rammohan R" To: "Lukas Alig" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: sip@ietf.org Subject: Re: [Sip] INAP - SIP conversion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, You can look at http://tools.ietf.org/html/rfc3976 Another paper that might be of help is http://www.cs.columbia.edu/~hgs/papers/cucs-002-99.pdf - Ram On Tue, Jun 10, 2008 at 3:30 PM, Lukas Alig wrote: > Hi, > > > > Can anybody help me which RFCs / TSs specifies SIP =96 INAP conversion. > > > > Thanks > > > > Lukas Alig > > Technical Consultant > > > > NewNet Communication Technologies, LLC > > Phone/VoIP: +41 43 544 07 19 > Fax: +41 41 790 40 39 > e-mail: Lukas.Alig@newnet.com > > Office: Floraweg 5 > CH-6343 Buonas > > Switzerland > > Notice to Recipient: This e-mail is confidential and meant only for the > intended recipient[s] of the transmission > > and may be a communication privileged by law. > > If you received this e-mail in error, any review, use, dissemination, > distribution or copying of this e-mail is strictly > > prohibited. If you are not the intended recipient, please contact the > sender by reply e-mail and please delete > > this e-mail from your system and destroy any copies. > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 06:54:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDBC3A6874; Tue, 10 Jun 2008 06:54:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28993A6908 for ; Tue, 10 Jun 2008 06:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=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 lYiWI7hvTDUt for ; Tue, 10 Jun 2008 06:54:49 -0700 (PDT) Received: from n58.bullet.mail.sp1.yahoo.com (n58.bullet.mail.sp1.yahoo.com [98.136.44.46]) by core3.amsl.com (Postfix) with SMTP id B67A23A6874 for ; Tue, 10 Jun 2008 06:54:49 -0700 (PDT) Received: from [216.252.122.216] by n58.bullet.mail.sp1.yahoo.com with NNFMP; 10 Jun 2008 13:55:08 -0000 Received: from [69.147.65.157] by t1.bullet.sp1.yahoo.com with NNFMP; 10 Jun 2008 13:55:08 -0000 Received: from [127.0.0.1] by omp405.mail.sp1.yahoo.com with NNFMP; 10 Jun 2008 13:55:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 263772.14238.bm@omp405.mail.sp1.yahoo.com Received: (qmail 47808 invoked by uid 60001); 10 Jun 2008 13:55:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=yIXrPuA5R4XiUiZ/2YpB9VwoXOzZ7Gk2LwGm80CYXq0dJN+8wvv89GLe2kaJ0po0Pyb0Q6RCFZXJVjsW9RiVt/OJSBDj9isBjUjqzXsjrax2uUGC2OFyy1KJQCDyvpfnEFgZp6Cq2p4a5t00lJCQSyubwkxBm7m14KVjZijCYyY=; Received: from [121.241.96.5] by web8414.mail.in.yahoo.com via HTTP; Tue, 10 Jun 2008 19:25:05 IST X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 10 Jun 2008 19:25:05 +0530 (IST) From: atul garg To: sip@ietf.org MIME-Version: 1.0 Message-ID: <4853.47467.qm@web8414.mail.in.yahoo.com> Subject: [Sip] Maximum allowed value of Clock rate in SDP ??? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: shivalk_80@yahoo.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, Is there any limitation about the maximum allowed value for the Clock-rate appears in SDP. a = rtpmap : eg:- a =rtpmap:96 H263/90000 here this 90000, I have seen in real network ..is this value aloowed ??? If anyone also can mention any reference which states about this ,would help me alot. Regards shiva Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 08:40:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53F53A6839; Tue, 10 Jun 2008 08:40:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F34A3A6812 for ; Tue, 10 Jun 2008 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=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 pl2+bK-CBKXF for ; Tue, 10 Jun 2008 08:40:41 -0700 (PDT) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.239]) by core3.amsl.com (Postfix) with ESMTP id C86913A6839 for ; Tue, 10 Jun 2008 08:40:40 -0700 (PDT) Received: by hu-out-0506.google.com with SMTP id 24so4225275hud.14 for ; Tue, 10 Jun 2008 08:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=vhDdnexkVJhHY6N+43KCBuYMscXcCuyQ7dAUjIXqj0s=; b=d9e5GnrVpzQwVH86dT7SPnSIx0RWOjiNld5fEZJ0rNB8x95bUDy+Vtye2DGzu3fPbs VGvVgLt2/9d7lMQlnl+bmtt3oDb25QU+/qzdBpUp4CR+OjNDWmIMkpUG137GkEkfE95M 60kTNf5I1H8EX6a8Uvb3b7weTcdpqbugm3jJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=pEpxIh2qqYzW9rgyXzQ0KIcMm/aJnRkxVuw3ftM2RY5AcY02YZDdSugF9lMPmooMVb RcvcOmMFPdiztiNGQUpOPp0i24fDNPOaYaKr83dZ+UsuoC7de7ww/C5ktNvKC096ugVm tZo4ZQiYw7OdtmnAtDlGaQ0mrKF7Toy2y/l3E= Received: by 10.86.66.19 with SMTP id o19mr5866034fga.62.1213112461796; Tue, 10 Jun 2008 08:41:01 -0700 (PDT) Received: by 10.86.83.8 with HTTP; Tue, 10 Jun 2008 08:41:00 -0700 (PDT) Message-ID: <14b80930806100841i6463d9dauff7636e76c77b671@mail.gmail.com> Date: Tue, 10 Jun 2008 21:11:00 +0530 From: "Hul spencer" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] Doubt in outbound draft v14 - auth proxy behaviour X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1126118557==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1126118557== Content-Type: multipart/alternative; boundary="----=_Part_21511_15574508.1213112461811" ------=_Part_21511_15574508.1213112461811 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have a doubt related to outbound draft v14 In section 7 bullet 3 " If the proxy receives a final response from a branch other than a 408 (Request Timeout) or a 430 (Flow Failed) response, the proxy MUST NOT forward the same request to another target representing the same AOR and instance-id. The targeted instance has already provided its response." As this section talks about authoritative proxy, this would imply that the request gets sent to one of the edge proxy. There can be cases where for same AOR and instance-id, UE register via 2 edge proxies, with reg-id=1 and reg-id=2. |----EP1---------| | | UE REGISTRAR/AUTH Proxy | | |----EP2---------| When auth proxy receives a request for this UE, it can decide to send the request via EP1. Due to some problem(reboot etc) EP1, sends error response 404 Not Found(or any other error resp except 408 and 430). Once authoritative proxy gets 404 , because of bullet 3 it can not try the other path(via EP2) to UE. Is it a correct behaiour ? because if authoritative proxy sends request to UE via EP2, request may still reach UE. I understand that a proxy is supposed to send 430 in case flow is not there, but there can be many other generic error conditions because of which proxy may send any 4xx response. ------=_Part_21511_15574508.1213112461811 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I have a doubt related to outbound draft v14

In section 7 bullet 3 
" If the proxy receives a final response from a branch other than a

      408 (Request Timeout) or a 430 (Flow Failed) response, the proxy
      MUST NOT forward the same request to another target representing
      the same AOR and instance-id.  The targeted instance has already

      provided its response."
As this section talks about authoritative proxy, this would imply that the request gets sent to one of the edge proxy.
There can be cases where for same AOR and instance-id, UE register via 2 edge proxies, with reg-id=1 and reg-id=2.

  |----EP1---------|
  |                |
 UE        REGISTRAR/AUTH Proxy
  |                |
  |----EP2---------|
 
When auth proxy receives a request for this UE, it can decide to send the request via EP1. Due to some problem(reboot etc) EP1, sends error response 404 Not Found(or any other error resp except 408 and 430). Once authoritative proxy gets 404 , because of bullet 3 it can not try the other path(via EP2) to UE.  Is it a correct behaiour ?  because  if authoritative proxy sends  request to UE via EP2, request may still reach UE.


I understand that a proxy is supposed to send 430 in case flow is not there, but there can be many other generic error conditions because of which proxy may send any 4xx response.
------=_Part_21511_15574508.1213112461811-- --===============1126118557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1126118557==-- From c.vicenzetto@chario.it Tue Jun 10 11:19:52 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871573A67F3; Tue, 10 Jun 2008 11:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -60.361 X-Spam-Level: X-Spam-Status: No, score=-60.361 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 U8kuX7DCd7pH; Tue, 10 Jun 2008 11:19:47 -0700 (PDT) Received: from 69-137-246-201.adsl.terra.cl (69-137-246-201.adsl.terra.cl [201.246.137.69]) by core3.amsl.com (Postfix) with SMTP id 113153A696B; Tue, 10 Jun 2008 11:19:35 -0700 (PDT) X-Originating-IP: 170.84.225.126 by smtp.201.246.137.69; Tue, 10 Jun 2008 14:19:56 -0500 Message-ID: From: "Calvin Nielsen" Reply-To: "Calvin Nielsen" To: send-archive@ietf.org Subject: Looking for a replica watch? Date: Tue, 10 Jun 2008 14:19:56 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://lasusewaxiv01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://lasusewaxiv01.blogspot.com/ From sip-bounces@ietf.org Tue Jun 10 13:58:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FAB3A6A65; Tue, 10 Jun 2008 13:58:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFEB3A68A9 for ; Tue, 10 Jun 2008 13:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kSmB3y28WLk for ; Tue, 10 Jun 2008 13:58:42 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.242]) by core3.amsl.com (Postfix) with ESMTP id E4A073A6A65 for ; Tue, 10 Jun 2008 13:58:41 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so6315681agb.12 for ; Tue, 10 Jun 2008 13:59:04 -0700 (PDT) Received: by 10.100.6.13 with SMTP id 13mr6238397anf.83.1213131544325; Tue, 10 Jun 2008 13:59:04 -0700 (PDT) Received: by 10.100.112.2 with HTTP; Tue, 10 Jun 2008 13:59:04 -0700 (PDT) Message-ID: <167dfb9b0806101359q36f09617vd20e8b27d4c7a526@mail.gmail.com> Date: Tue, 10 Jun 2008 21:59:04 +0100 From: "Theo Zourzouvillys" To: "Yuantao Zhang" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <680808427CF931459462C3D78CB5EC6002461AEB@EXVS02.nasstar-t1.net> <48468E37.40603@cisco.com> <48492596.4010704@cisco.com> <484D198B.1000004@cisco.com> Cc: sip@ietf.org, discussion@sipforum.org Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 2008/6/10 Yuantao Zhang : > Thanks for keeping answering my question. And it is happy to discuss with you. Could you give me a scenario that the port number in R-line and the lower layer UDP destination port are different? They are always same, aren't they? Thanks as well as others examples, there are also these times when a UAC sends a request and the destination is resolved via SRV - the R-URI may be sip:example.com, but the port could be anything at all. Note however that if a port is explicitly provided in the URI, then this would not be the case. ~ Theo _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 14:11:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C213A6A6B; Tue, 10 Jun 2008 14:11:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34BFD3A6A6B for ; Tue, 10 Jun 2008 14:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 vcLwvjLMngbV for ; Tue, 10 Jun 2008 14:11:19 -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 C39423A6A65 for ; Tue, 10 Jun 2008 14:11:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,619,1204531200"; d="scan'208";a="55510966" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2008 14:11:43 -0700 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 m5ALBhWp024596; Tue, 10 Jun 2008 14:11:43 -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.13.8) with ESMTP id m5ALBREe017737; Tue, 10 Jun 2008 21:11:43 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.1830); Tue, 10 Jun 2008 17:11:42 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 17:11:41 -0400 Message-ID: <484EEE3C.3040606@cisco.com> Date: Tue, 10 Jun 2008 17:12:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: X-OriginalArrivalTime: 10 Jun 2008 21:11:42.0012 (UTC) FILETIME=[94838FC0:01C8CB3E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4828; t=1213132303; x=1213996303; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20; bh=QScEDS5UXTRV+ykn8C+sMLPF2RGveAExIwsQKwYTguY=; b=h1PlrSMbw2WVioPDDczm5xnFJ91wAocKNZJh7HCPwIp26jSSmMfzR26k1w NECh4u8MVA9z2lIDjI7KY6MGAbjy/U+KoFg4Bf8qS2CEAC5luJqq8iflOrhp 80AIpzviv9Mpszno1xEDU61jJ71DZZBjFkh2S+AZ0lZ/Yc2nx0k0I=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer, I finally got around to this. A few comments: Section 1: When SIP entities upstream receive the 2xx final response they will automatically terminate other associated outstanding early dialogs. This isn't always wise. At this point it is still possible to receive additional 2xx responses. Discarding the early dialog is probably fine if subsequent 2xx responses with be dealt with by sending BYE. Retaining the early dialog isn't useful in that case. But if the UAC is planning to accept an additional 2xx response and retain the dialog rather than terminate it, then it should not discard the early dialog upon receipt of the first 2xx. (Note that sending cancel upon receipt of a 2xx is MUST in 3261, but it is overridden by a 'Request-Disposition: no-cancel' specified in RFC 3841. Terminating the early dialog at the UAC is also a MUST, but seems like it is probably an error.) Section 4: You give examples of kinds of resources that may be freed upon receipt of the 199. But you also hint at a problem: If the client is able to associate the 199 response with a specific media stream, In many cases it may be hard/impossible to accomplish this. Can you give some plausible examples of cases when this will be possible? I don't understand the following: The UAC MAY use additional information (for example the final response which triggered the 199 response) received in the 199 response when initiating new sessions, if it is possible to avoid the new session initation request to be rejected. I can't parse it into anything meaningful. Section 5: When would it be advantageous for the UAS to send a 199? Section 6: This has MUST strength language. But of course not all proxies will implement this draft if/when it becomes an RFC. It it expected that this is to be an independent RFC to which support may be claimed? Section 8: OPEN ISSUE: We need to discuss whether the To tag in the 199 identifies the dialog that has been terminated, and/or if some additional information element (e.g. SIP header) can be used, which would allow to indicate the termination of multiple dialogs in a single 199 response. My preference is to use the To-tag, so that normal dialog matching rules will apply. We don't need more irregularities to complicate sip stacks. OPEN ISSUE: We need to discuss whether, in addition to the dialog identifier, some additional information (e.g. the non-2xx final response which triggered the 199 response) should be provided in the 199 response. I think it would be useful to at least acknowledge that a sipfrag can be carried in the 199, in a similar way to is carried in a refer event package notification. Would probably be good to state that it SHOULD NOT be included unless there was an Accept header mentioning the sipfrag content type in the request. Section 9: A 199 Early Dialog Terminated provisional response MUST NOT contain a new SDP offer/answer message body, but the sender of the response MAY insert a copy of a previously sent offer/answer message body as otherwise allowed by the offer/answer rules for a provisional response. A forking proxy or a UAS MUST NOT trigger and send a 199 Early Dialog Terminated provisional response reliably in a situation where a reliable provisional response is required to contain an SDP offer/ answer message body, according to [RFC3262] and [RFC3264]. These two paragraphs seem to be slightly at odds with one another, regarding the sending of an answer in a reliable 199. This can be fixed by changing the 2nd paragraph to only mention "offer", not "answer". Section 10: OPEN ISSUE: We need to discuss whether a proxy should send 199 reliably at all, since the proxy would have to terminate the associated PRACK, and support the logic associated with 100rel. If not sent, how would required 100rel affect the usage of 199? IMO it is a bad idea for a proxy to send a reliable 199. The problem is that you aren't sending the 199 unless there was already an early dialog. If there was, the proxy is not the second party in that dialog. The PRACK will be sent to the peer in the dialog, not the proxy. The proxy has no business terminating and responding to it. Yet the UAS won't be expecting it. So I think it would only be possible to send a reliable 199 as part of some new dialog terminated by the proxy. But that then means the To-tag can't be used to indicate which dialog is being terminated. It just keeps getting more and more complicated. And there really isn't any great value in sending this reliably. So don't do it. Thanks, Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 15:00:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566B73A6A44; Tue, 10 Jun 2008 15:00:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A613A6983 for ; Tue, 10 Jun 2008 15:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcsxhezjY7gS for ; Tue, 10 Jun 2008 15:00:10 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 02F273A68A6 for ; Tue, 10 Jun 2008 15:00:09 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m5AM0WLX028752; Tue, 10 Jun 2008 16:00:32 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 10 Jun 2008 16:00:32 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 16:00:32 -0600 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgAWxgY1A= References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> From: "Stuart Hoggan" To: "DRAGE, Keith (Keith)" , X-Approved: ondar Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org All, We have updated the document to incorporate feedback received so far. It now contains a section that helps clarify the motivation. Let us know if you have further comments. -Stuart > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: Wednesday, June 04, 2008 3:48 AM > To: sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > (As SIP WG cochair) > > This has been raised in the SIP group a couple of times, and we have not > yet gained an idea of whether to proceed with it in the SIP WG or not. > > There have been a couple of technical comments raised in the past from > the security experts; my understanding is that these have now been > clarified. > > I believe in the past there has been an interested community that says > this is useful. It has also been clarified that 3GPP would like to use > it in their specifications. > > So could I ask the WG to look at this document, and formally to indicate > whether they believe some work with this scope should be progressed as a > SIP WG item. > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-02.txt > > So if you support it please indicate to the SIP WG chairs. > > If you have technical concerns (i.e. it should not proceed because it is > technically flawed beyond fixing) then please ideally mail the list, > although the SIP WG chairs will also accept input. > > Responses please in 1 calendar week from this date. > > Regards > > Keith > > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Stuart Hoggan > Sent: Friday, May 02, 2008 5:15 PM > To: sip@ietf.org > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > > > Folks, > > > > Based on the feedback received in Philadelphia, we have updated > draft-dotson-sip-mutual-auth. The changes clarify the usage of the > Proxy-Authentication-Info header, including support for multiple values. > > > > > Any further comments or suggestions will be appreciated. It > would also be nice to obtain WG feedback on pursuing this I-D as a WG > document. > > > > Regards, > > Stuart > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 10 22:57:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B46B3A6782; Tue, 10 Jun 2008 22:57:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B873A6781 for ; Tue, 10 Jun 2008 22:57:27 -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.048, 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 zHrX0qzyIjEG for ; Tue, 10 Jun 2008 22:57:25 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BAAAB3A6782 for ; Tue, 10 Jun 2008 22:57:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A1E3F20B65; Wed, 11 Jun 2008 07:57:47 +0200 (CEST) X-AuditID: c1b4fb3c-ab095bb00000193b-fd-484f695b0bba Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 661CD20A96; Wed, 11 Jun 2008 07:57:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 07:57:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 07:56:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjLPppct85UumKMSzmobvr5St0OoQAOnAXm References: <484EEE3C.3040606@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 Jun 2008 05:57:52.0797 (UTC) FILETIME=[162B0CD0:01C8CB88] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2039444233==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2039444233== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CB87.F2E0AFC7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CB87.F2E0AFC7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, =20 >I finally got around to this. A few comments: > >Section 1: > > When SIP entities upstream > receive the 2xx final response they will automatically terminate > other associated outstanding early dialogs. > >This isn't always wise. At this point it is still possible to receive >additional 2xx responses. Discarding the early dialog is probably fine >if subsequent 2xx responses with be dealt with by sending BYE. =20 Correct. I can add some text, clarifying that the SIP enitty should still be prepared to receive additional 2xx responses and deal with the accordingly. =20 =20 =20 >Retaining the early dialog isn't useful in that case. But if the UAC is planning >to accept an additional 2xx response and retain the dialog rather than >terminate it, then it should not discard the early dialog upon receipt >of the first 2xx. I will mention that also. >(Note that sending cancel upon receipt of a 2xx is MUST in 3261, but it >is overridden by a 'Request-Disposition: no-cancel' specified in RFC >3841. Terminating the early dialog at the UAC is also a MUST, but seems >like it is probably an error.) I can mention that RFC 3841 may affect the behavior of entities regarding termination of early dialogs. >Section 4: > >You give examples of kinds of resources that may be freed upon receipt of the 199. But you also hint at a problem: > > If the client is able to associate the 199 response with a specific media stream, > >In many cases it may be hard/impossible to accomplish this. Can you give some plausible examples of cases when this will be possible? Maybe if the media stream is encrypted, and there are some encryption parameters associated with the dialog. I am not an expert on that, though.... Every now and then there have also been discussions of including parameters, which are sent in the media stream, also in SIP messages, so that media streams can be associated with an early dialog. =20 >I don't understand the following: > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initation request to be rejected. > >I can't parse it into anything meaningful. This is related to the HERFP problem. I has been agreed to not solve that problem in this draft, but it was agreed to add some words about what the information could be used for. >Section 5: When would it be advantageous for the UAS to send a 199? This is one of the issues which was perviously discussed, so I listed the possibility. Francois also had that question, and I am ok with removing it. >Section 6: > >This has MUST strength language. But of course not all proxies will implement this draft if/when it becomes an RFC. Well, the text only applies to proxies supporting the draft, so... >It it expected that this is to be an independent RFC to which support may be claimed? Yes. The idea is NOT to make a normative reference to RFC3261. >Section 8: > > OPEN ISSUE: We need to discuss whether the To tag in the 199 > identifies the dialog that has been terminated, and/or if some > additional information element (e.g. SIP header) can be used, which > would allow to indicate the termination of multiple dialogs in a > single 199 response. > >My preference is to use the To-tag, so that normal dialog matching rules >will apply. We don't need more irregularities to complicate sip stacks. I agree. I am happy to remove the OPEN ISSUE, unless someone else has a different opinion. > OPEN ISSUE: We need to discuss whether, in addition to the dialog > identifier, some additional information (e.g. the non-2xx final > response which triggered the 199 response) should be provided in the > 199 response. > >I think it would be useful to at least acknowledge that a sipfrag can be >carried in the 199, in a similar way to is carried in a refer event >package notification. Would probably be good to state that it SHOULD NOT >be included unless there was an Accept header mentioning the sipfrag >content type in the request. This was discussed based on input from Francois just a few days ago, so please take a look whether you are ok with the outcome of that discussion.=20 We did not discuss the Accept header, though, and I think that is a good point. >Section 9: > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > > A forking proxy or a UAS MUST NOT trigger and send a 199 Early Dialog > Terminated provisional response reliably in a situation where a > reliable provisional response is required to contain an SDP offer/ > answer message body, according to [RFC3262] and [RFC3264]. > >These two paragraphs seem to be slightly at odds with one another, >regarding the sending of an answer in a reliable 199. This can be fixed >by changing the 2nd paragraph to only mention "offer", not "answer". Ok >Section 10: > > OPEN ISSUE: We need to discuss whether a proxy should send 199 > reliably at all, since the proxy would have to terminate the > associated PRACK, and support the logic associated with 100rel. If > not sent, how would required 100rel affect the usage of 199? > >IMO it is a bad idea for a proxy to send a reliable 199. The problem is >that you aren't sending the 199 unless there was already an early >dialog. If there was, the proxy is not the second party in that dialog. >The PRACK will be sent to the peer in the dialog, not the proxy. The >proxy has no business terminating and responding to it. Yet the UAS >won't be expecting it. > >So I think it would only be possible to send a reliable 199 as part of >some new dialog terminated by the proxy. But that then means the To-tag >can't be used to indicate which dialog is being terminated. It just >keeps getting more and more complicated. > >And there really isn't any great value in sending this reliably. So >don't do it. I have no problem with that. A UA that doesn't support 199, but has required 100rel, may discard the unreliable 199, but it really doesn't matter. =20 =20 Thank you very much for the comments! =20 Regards, =20 Christer =20 ------_=_NextPart_001_01C8CB87.F2E0AFC7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Sip] Draft submission: = draft-ietf-sip-199-00
Hi Paul,
 
>I finally got around to this. A few=20 comments:
>
>Section 1:
>
>    = When SIP=20 entities upstream
>    receive the 2xx final = response they=20 will automatically terminate
>    other associated=20 outstanding early dialogs.
>
>This isn't always wise. At = this point=20 it is still possible to receive
>additional 2xx responses. = Discarding the=20 early dialog is probably fine
>if subsequent 2xx responses with be = dealt=20 with by sending BYE.
 
Correct. I can add some text, clarifying = that the SIP=20 enitty should still be prepared to receive additional 2xx responses and = deal=20 with the accordingly.
 
 
 
>Retaining the early dialog isn't = useful in that=20 case. But if the UAC is planning
>to accept an additional 2xx = response and=20 retain the dialog rather than
>terminate it, then it should not = discard=20 the early dialog upon receipt
>of the first 2xx.

I will mention that also.


>(Note that sending cancel upon = receipt of a=20 2xx is MUST in 3261, but it
>is overridden by a = 'Request-Disposition:=20 no-cancel' specified in RFC
>3841. Terminating the early dialog at = the UAC=20 is also a MUST, but seems
>like it is probably an error.)

I can mention that RFC 3841 may affect the behavior of = entities=20 regarding termination of early dialogs.


>Section 4:
>
>You give examples of kinds of = resources=20 that may be freed upon receipt of the 199. But you also hint at a=20 problem:
>
>   If the client is able to = associate the=20 199 response with a specific media stream,
>
>In many cases = it may=20 be hard/impossible to accomplish this. Can you give some plausible = examples of=20 cases when this will be possible?

Maybe if the media stream is encrypted, and there are = some=20 encryption parameters associated with the dialog. I am not an expert on = that,=20 though....

Every now and then there have also been discussions of = including=20 parameters, which are sent in the media stream, also in SIP = messages, so=20 that media streams can be associated with an early dialog.

 

>I don't = understand the=20 following:
>
>    The UAC MAY use additional=20 information (for example the final
>    response = which=20 triggered the 199 response) received in the = 199
>   =20 response when initiating new sessions, if it is possible to avoid=20 the
>    new session initation request to be=20 rejected.
>
>I can't parse it into anything = meaningful.

This is related to the HERFP problem. I has been = agreed to not=20 solve that problem in this draft, but it was agreed to add some words = about what=20 the information could be used for.



>Section 5: When would it be advantageous = for the UAS=20 to send a 199?

This is one of the = issues which=20 was perviously discussed, so I listed the possibility.

Francois also had that question, and I am ok with = removing=20 it.



>Section 6:
>
>This has MUST = strength=20 language. But of course not all proxies will implement this draft = if/when it=20 becomes an RFC.

Well, the text only applies to proxies supporting the = draft,=20 so...

>It it expected that this is to be an independent = RFC to=20 which support may be claimed?

Yes. The idea is NOT to make a normative = reference=20 to RFC3261.



>Section=20 8:
>
>    OPEN ISSUE: We need to discuss = whether the=20 To tag in the 199
>    identifies the dialog that = has been=20 terminated, and/or if some
>    additional = information=20 element (e.g.  SIP header) can be used, = which
>   =20 would allow to indicate the termination of multiple dialogs in=20 a
>    single 199 response.
>
>My = preference is=20 to use the To-tag, so that normal dialog matching rules
>will = apply. We=20 don't need more irregularities to complicate sip stacks.

I agree. I am happy to remove the OPEN ISSUE, unless = someone=20 else has a different opinion.


>    OPEN=20 ISSUE: We need to discuss whether, in addition to the=20 dialog
>    identifier, some additional information = (e.g.=20 the non-2xx final
>    response which triggered the = 199=20 response) should be provided in the
>    199=20 response.
>
>I think it would be useful to at least = acknowledge that=20 a sipfrag can be
>carried in the 199, in a similar way to is = carried in a=20 refer event
>package notification. Would probably be good to state = that it=20 SHOULD NOT
>be included unless there was an Accept header = mentioning the=20 sipfrag
>content type in the request.

This was discussed based on input from Francois just a few days ago, so please take a = look=20 whether you are ok with the = outcome of that=20 discussion.

We did not discuss = the Accept=20 header, though, and I think that is a good point.



>Section=20 9:
>
>    A 199 Early = Dialog=20 Terminated provisional response MUST NOT contain a
>    new SDP = offer/answer=20 message body, but the sender of the response MAY
>    insert a copy = of a=20 previously sent offer/answer message body as
>    otherwise = allowed by the=20 offer/answer rules for a provisional
>   response.
>
>    A forking proxy = or a UAS=20 MUST NOT trigger and send a 199 Early Dialog
>    Terminated = provisional=20 response reliably in a situation where a
>    reliable = provisional=20 response is required to contain an SDP offer/
>    answer message = body,=20 according to [RFC3262] and [RFC3264].
>
>These two paragraphs seem to be = slightly at=20 odds with one another,
>regarding=20 the sending of an answer in a reliable 199. This can be fixed
>by changing the 2nd paragraph to = only=20 mention "offer", not "answer".

Ok



>Section=20 10:
>
>    OPEN ISSUE: We = need to=20 discuss whether a proxy should send 199
>    reliably at = all, since=20 the proxy would have to terminate the
>    associated = PRACK, and=20 support the logic associated with 100rel.  If
>    not sent, how = would=20 required 100rel affect the usage of 199?
>
>IMO it is a bad idea for a proxy = to send a=20 reliable 199. The problem is
>that=20 you aren't sending the 199 unless there was already an early
>dialog. If there was, the proxy is = not the=20 second party in that dialog.
>The=20 PRACK will be sent to the peer in the dialog, not the proxy. = The
>proxy has no business terminating = and=20 responding to it. Yet the UAS
>won't=20 be expecting it.
>
>So I think it would only be = possible to send=20 a reliable 199 as part of
>some new=20 dialog terminated by the proxy. But that then means the To-tag
>can't be used to indicate which = dialog is=20 being terminated. It just
>keeps=20 getting more and more complicated.
>
>And there really isn't any great = value in=20 sending this reliably. So
>don't do=20 it.

I have = no problem=20 with that. A UA that doesn't support 199, but has required 100rel, may = discard=20 the unreliable 199, but it really doesn't matter.
 
 
Thank = you very much=20 for the comments!
 
Regards,
 
Christer
 
------_=_NextPart_001_01C8CB87.F2E0AFC7-- --===============2039444233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2039444233==-- From sip-bounces@ietf.org Tue Jun 10 23:25:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1DC3A69D3; Tue, 10 Jun 2008 23:25:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408093A69D3 for ; Tue, 10 Jun 2008 23:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599, 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 F0wHdkjcE+wX for ; Tue, 10 Jun 2008 23:25:57 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.119.2.190]) by core3.amsl.com (Postfix) with ESMTP id 132A13A69D2 for ; Tue, 10 Jun 2008 23:25:56 -0700 (PDT) Received: from rly08f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly08f.srv.mailcontrol.com (MailControl) with ESMTP id m5B6QDOr019700 for ; Wed, 11 Jun 2008 07:26:17 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly08f.srv.mailcontrol.com (MailControl) id m5B6POb2017539 for sip@ietf.org; Wed, 11 Jun 2008 07:25:24 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly08f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id m5B6OofG016229; Wed, 11 Jun 2008 07:25:24 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 07:26:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 07:25:14 +0100 Message-ID: <680808427CF931459462C3D78CB5EC60025430C2@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjLPppct85UumKMSzmobvr5St0OoQAOnAXmAAQeUFA= From: "Attila Sipos" To: , "Christer Holmberg" X-OriginalArrivalTime: 11 Jun 2008 06:26:40.0636 (UTC) FILETIME=[1C0A5BC0:01C8CB8C] X-Scanned-By: MailControl A-08-50-03 (www.mailcontrol.com) on 10.70.1.118 Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ( Aren't we at draft 04 now? ) Should the document describe what should happen if you get a 199 and the 199 refers the only leg you have? e.g. UAC P1 UAS_2 UAS_3 --- INVITE ------> --- INVITE (leg 2) -> --- INVITE (leg 3) ----------> <-- 18x (leg 2) ----- <-- 18x (leg 2) -- <-- 4xx (leg 2) ----- <-- 199 (leg 2) -- ======================= what does UAC do now? ======================= <-- 18x (leg 3) -------------- <-- 18x (leg 3) -- <-- 200 (leg 3) -------------- <-- 200 (leg 3) -- --- ACK (leg 3) -> --- ACK (leg 3) -------------> The UAC would have to act as if it hadn't received the "18x (leg 2)" and "199 (leg 2)" message. So it would be as if it was still be waiting for its first non-100 response. This answer is obvious maybe but maybe some explicit text might be useful otherwise the question might come up over and over. Regards, Attila _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 11 02:55:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8023A69C0; Wed, 11 Jun 2008 02:55:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3FD3A688D for ; Wed, 11 Jun 2008 02:55:35 -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 j+fhDVXqoYfV for ; Wed, 11 Jun 2008 02:55:35 -0700 (PDT) Received: from web8405.mail.in.yahoo.com (web8405.mail.in.yahoo.com [202.43.219.153]) by core3.amsl.com (Postfix) with SMTP id 629183A69C0 for ; Wed, 11 Jun 2008 02:55:34 -0700 (PDT) Received: (qmail 51676 invoked by uid 60001); 11 Jun 2008 09:55:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mpX5IBZpqhfgTu8ox0bDoLpeFw0weDJhWaGP3c+mNJzTLR0BIVbWa3xcdkywAhlrmU6XvZiM9Hac1iKgzNeMQpL83n0KznaAT4lBn6Dl3LNS6Fr75mgYea71HZaHJZ7BrAiH7INRdTIfkI5fiesEdm1yHf2xTrRYm670wSaRHfw=; Received: from [125.21.164.251] by web8405.mail.in.yahoo.com via HTTP; Wed, 11 Jun 2008 15:25:58 IST X-Mailer: YahooMailWebService/0.7.199 Date: Wed, 11 Jun 2008 15:25:58 +0530 (IST) From: atul garg To: sip@ietf.org MIME-Version: 1.0 Message-ID: <54074.50722.qm@web8405.mail.in.yahoo.com> Subject: [Sip] Is this a valid Request Line/response lie ?? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: shivalk_80@yahoo.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, BYE sipua" sipua"< X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAA03A6A21; Wed, 11 Jun 2008 03:15:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DAD3A6A21 for ; Wed, 11 Jun 2008 03:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, 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 Ecj0NcQi8Rff for ; Wed, 11 Jun 2008 03:15:37 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.119.2.190]) by core3.amsl.com (Postfix) with ESMTP id 8BA433A63EC for ; Wed, 11 Jun 2008 03:15:37 -0700 (PDT) Received: from rly28f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly28f.srv.mailcontrol.com (MailControl) with ESMTP id m5BAFwOF030888 for ; Wed, 11 Jun 2008 11:16:00 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly28f.srv.mailcontrol.com (MailControl) id m5BAEsLn025113 for sip@ietf.org; Wed, 11 Jun 2008 11:14:54 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly28f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id m5BAEE16021527; Wed, 11 Jun 2008 11:14:54 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 11:15:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 11:13:34 +0100 Message-ID: <680808427CF931459462C3D78CB5EC6002543285@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Is this a valid Request Line/response lie ?? Thread-Index: AcjLqcgKqiSKID7AQbOSsbEwYJMCUQAAfang From: "Attila Sipos" To: , X-OriginalArrivalTime: 11 Jun 2008 10:15:01.0922 (UTC) FILETIME=[02A4B020:01C8CBAC] X-Scanned-By: MailControl A-08-50-03 (www.mailcontrol.com) on 10.70.1.138 Subject: Re: [Sip] Is this a valid Request Line/response lie ?? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org no. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of atul garg Sent: 11 June 2008 10:56 To: sip@ietf.org Subject: [Sip] Is this a valid Request Line/response lie ?? Hi, BYE sipua" sipua"< X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8499A3A6970; Wed, 11 Jun 2008 07:08:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B993A6970 for ; Wed, 11 Jun 2008 07:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 FRajcd5FJLMo for ; Wed, 11 Jun 2008 07:08:54 -0700 (PDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id DEB3A3A6953 for ; Wed, 11 Jun 2008 07:08:53 -0700 (PDT) Received: from vpn5.dcs.gla.ac.uk ([130.209.254.5]:53131) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1K6R0n-0006Cp-FZ; Wed, 11 Jun 2008 15:09:17 +0100 In-Reply-To: <4853.47467.qm@web8414.mail.in.yahoo.com> References: <4853.47467.qm@web8414.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Colin Perkins Date: Wed, 11 Jun 2008 15:09:26 +0100 To: shivalk_80@yahoo.co.in X-Mailer: Apple Mail (2.753.1) Cc: sip@ietf.org Subject: Re: [Sip] Maximum allowed value of Clock rate in SDP ??? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 10 Jun 2008, at 14:55, atul garg wrote: > Is there any limitation about the maximum allowed value for the > Clock-rate appears in SDP. > > a = rtpmap : > > eg:- a =rtpmap:96 H263/90000 > > here this 90000, I have seen in real network ..is this value > aloowed ??? Yes - this is the clock rate used for most video formats. > If anyone also can mention any reference which states about > this ,would help me alot. The legal values for the clock rate for each RTP payload format are defined in the payload format RFC. SDP doesn't specify a maximum value. The largest clock rate used that I'm aware of is video/ smpte292m, which uses a rate of 148500000. -- Colin Perkins http://csperkins.org/ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 11 10:43:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7A03A6824; Wed, 11 Jun 2008 10:43:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843923A681F for ; Wed, 11 Jun 2008 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 Koi-rKbPwRQC for ; Wed, 11 Jun 2008 10:43:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6A28A3A6824 for ; Wed, 11 Jun 2008 10:43:34 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3E5602036E; Wed, 11 Jun 2008 19:43:59 +0200 (CEST) X-AuditID: c1b4fb3e-ac995bb000004ec0-4f-48500edf5582 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2AC402025C; Wed, 11 Jun 2008 19:43:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 19:44:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 19:43:03 +0200 Message-ID: In-Reply-To: <680808427CF931459462C3D78CB5EC60025430C2@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjLPppct85UumKMSzmobvr5St0OoQAOnAXmAAQeUFAAGC4aAA== References: <680808427CF931459462C3D78CB5EC60025430C2@EXVS02.nasstar-t1.net> From: "Christer Holmberg" To: "Attila Sipos" , X-OriginalArrivalTime: 11 Jun 2008 17:44:05.0457 (UTC) FILETIME=[BE3DDC10:01C8CBEA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >( Aren't we at draft 04 now? ) No. We are now discussing the SIP WG draft, which has been put together based on the requirement in the previous individual draft for SIPPING. >Should the document describe what should happen if you get a 199 and the 199 refers the only leg you have? > > >e.g. > UAC P1 UAS_2 UAS_3 > > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > > ======================= > what does UAC do now? > ======================= > > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > > <-- 200 (leg 3) -------------- > <-- 200 (leg 3) -- > --- ACK (leg 3) -> > --- ACK (leg 3) -------------> > > >The UAC would have to act as if it hadn't received the "18x (leg 2)" and "199 (leg 2)" message. So it would be as if it >was still be waiting for its first non-100 response. > >This answer is obvious maybe but maybe some explicit text might be useful otherwise the question might come up over and >over. I can add some words about it. Thanks for the comment! Regards, Christer Regards, Attila _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.martin@gfnmbh.de Wed Jun 11 14:45:02 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F833A68ED; Wed, 11 Jun 2008 14:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.863 X-Spam-Level: X-Spam-Status: No, score=-73.863 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 dN7-puXAPo4Z; Wed, 11 Jun 2008 14:45:01 -0700 (PDT) Received: from 206-134-22-190.adsl.terra.cl (206-134-22-190.adsl.terra.cl [190.22.134.206]) by core3.amsl.com (Postfix) with SMTP id 81B393A68D3; Wed, 11 Jun 2008 14:44:46 -0700 (PDT) X-Originating-IP: 221.60.96.117 by smtp.190.22.134.206; Wed, 11 Jun 2008 17:45:09 -0500 Message-ID: From: "Steven Babb" Reply-To: "Steven Babb" To: send-archive@ietf.org Subject: Inexpensive IWC watches Date: Wed, 11 Jun 2008 17:45:09 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://balodyvuric76.blogspot.com/ From sip-bounces@ietf.org Wed Jun 11 14:57:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C7B3A6800; Wed, 11 Jun 2008 14:57:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E6E3A6878 for ; Wed, 11 Jun 2008 14:57:23 -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=0.908, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_NEED_REPLY=0.784, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAMnsFnmxmTo for ; Wed, 11 Jun 2008 14:57:22 -0700 (PDT) Received: from bay0-omc3-s16.bay0.hotmail.com (bay0-omc3-s16.bay0.hotmail.com [65.54.246.216]) by core3.amsl.com (Postfix) with ESMTP id 2E2D33A65A5 for ; Wed, 11 Jun 2008 14:57:20 -0700 (PDT) Received: from BAYC1-PASMTP04 ([65.54.191.164]) by bay0-omc3-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 14:57:47 -0700 X-Originating-IP: [70.48.49.45] X-Originating-Email: [barcaroller@sympatico.ca] Message-ID: Received: from fgt4t01 ([70.48.49.45]) by BAYC1-PASMTP04.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668); Wed, 11 Jun 2008 14:57:46 -0700 From: To: Date: Wed, 11 Jun 2008 17:55:19 -0400 MIME-Version: 1.0 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.5512 X-OriginalArrivalTime: 11 Jun 2008 21:57:46.0406 (UTC) FILETIME=[2EA25C60:01C8CC0E] Subject: [Sip] Request/response question... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I have a basic SIP question. The way I understood RFC3261, the "To:" header field in a response has to match the "To:" header field of the corresponding request (if no To tag is present in the request). This is true for 99% of the SIP conversations I've seen but not for the (real-life) example below (note that the "To:" header fields differ). Wireshark has no problem with analyzing this SIP conversation, so I suspect I'm misinterpreting the RFC. Can the "To:" header fields be different, and if so, how can the response be correlated to the request? # # The request # INVITE sip:5557451576@e.voncp.com:10000 SIP/2.0 Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2 From: 555-482-0690 ;tag=716ff48d4ef52332o0 To: Remote-Party-ID: 555-482-0690 ;screen=yes;party=calling Call-ID: 81f537e9-aaa35786@192.168.5.156 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="15554820690",realm="69.59.242.85",nonce="1489356920",uri="sip:5557451576@e.voncp.com:10000",algorithm=MD5,response="095bb689741268d970ca807964d58a73" Contact: 555-482-0690 Expires: 240 User-Agent: 001310757539 Linksys/RT31P2-3.1.6(LI) Content-Length: 316 # # The response # SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2 From: 555-482-0690 ;tag=716ff48d4ef52332o0;natted=24.235.117.242 To: ;tag=1645248237 Call-ID: 81f537e9-aaa35786@192.168.5.156 CSeq: 102 INVITE Contact: Max-Forwards: 15 # # The relevant RFC section # 8.2.6.2 Headers and Tags The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering. If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 11 15:13:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38213A69E4; Wed, 11 Jun 2008 15:13:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AAA03A69E4 for ; Wed, 11 Jun 2008 15:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcCbN3NVJ4pg for ; Wed, 11 Jun 2008 15:13:31 -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 13D953A68ED for ; Wed, 11 Jun 2008 15:13:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,626,1204531200"; d="scan'208";a="112037922" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2008 15:13:57 -0700 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 m5BMDvp4009898; Wed, 11 Jun 2008 15:13:57 -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.13.8) with ESMTP id m5BMDv7j015304; Wed, 11 Jun 2008 22:13:57 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.1830); Wed, 11 Jun 2008 18:13:57 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 18:13:56 -0400 Message-ID: <48504E52.9000605@cisco.com> Date: Wed, 11 Jun 2008 18:14:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: barcaroller@sympatico.ca References: In-Reply-To: X-OriginalArrivalTime: 11 Jun 2008 22:13:56.0641 (UTC) FILETIME=[70F07910:01C8CC10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3825; t=1213222437; x=1214086437; 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[Sip]=20Request/response=20question... |Sender:=20; bh=ehZ36qV+fTNH461QMr64UiIyFsV+F9+/bxD928rFK2o=; b=SrxwtxQaaLTnvlYbDFW8ze/tKtdcllf2WdTXPny+3QP3x5wBs7Q66a3VfY 8L7lcBOWaOBCk78LOYw2Aet5oaHbF2Rw0HGklLZ7yp/Ot3rPak1TCijBvqAX Z0Yv+sR40+3LosVU9M4O4IkOglPCtgBwbiQHngspd42R1m6Lq0OYA=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Request/response question... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org barcaroller@sympatico.ca wrote: > I have a basic SIP question. The way I understood RFC3261, the "To:" header > field in a response has to match the "To:" header field of the > corresponding request (if no To tag is present in the request). This is > true for 99% of the SIP conversations I've seen but not for the (real-life) > example below (note that the "To:" header fields differ). Wireshark has no > problem with analyzing this SIP conversation, so I suspect I'm > misinterpreting the RFC. > > Can the "To:" header fields be different, and if so, how can the response be > correlated to the request? The To in the response can only differ from that in the request because of the addition of a tag= parameter if there wasn't one in the request. The rest of the To-header must be the same. The matching of the response to the request is based on the branch parameter in the Via, so that isn't the problem. Paul > > # > # The request > # > INVITE sip:5557451576@e.voncp.com:10000 SIP/2.0 > Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2 > From: 555-482-0690 > ;tag=716ff48d4ef52332o0 > To: > Remote-Party-ID: 555-482-0690 > ;screen=yes;party=calling > Call-ID: 81f537e9-aaa35786@192.168.5.156 > CSeq: 102 INVITE > Max-Forwards: 70 > Proxy-Authorization: Digest > username="15554820690",realm="69.59.242.85",nonce="1489356920",uri="sip:5557451576@e.voncp.com:10000",algorithm=MD5,response="095bb689741268d970ca807964d58a73" > Contact: 555-482-0690 > Expires: 240 > User-Agent: 001310757539 Linksys/RT31P2-3.1.6(LI) > Content-Length: 316 > > > # > # The response > # > SIP/2.0 200 OK > Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2 > From: 555-482-0690 > ;tag=716ff48d4ef52332o0;natted=24.235.117.242 > To: ;tag=1645248237 > Call-ID: 81f537e9-aaa35786@192.168.5.156 > CSeq: 102 INVITE > Contact: > Max-Forwards: 15 > > > > # > # The relevant RFC section > # > 8.2.6.2 Headers and Tags > > > The From field of the response MUST equal the From header field of > the request. The Call-ID header field of the response MUST equal the > Call-ID header field of the request. The CSeq header field of the > response MUST equal the CSeq field of the request. The Via header > field values in the response MUST equal the Via header field values > in the request and MUST maintain the same ordering. > > If a request contained a To tag in the request, the To header field > in the response MUST equal that of the request. However, if the To > header field in the request did not contain a tag, the URI in the To > header field in the response MUST equal the URI in the To header > field; additionally, the UAS MUST add a tag to the To header field in > the response (with the exception of the 100 (Trying) response, in > which a tag MAY be present). This serves to identify the UAS that is > responding, possibly resulting in a component of a dialog ID. The > same tag MUST be used for all responses to that request, both final > and provisional (again excepting the 100 (Trying)). Procedures for > the generation of tags are defined in Section 19.3. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 11 15:15:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7043A6A69; Wed, 11 Jun 2008 15:15:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9119A3A6A69 for ; Wed, 11 Jun 2008 15:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XvL-pRXxJqf for ; Wed, 11 Jun 2008 15:15:35 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id D913D3A68ED for ; Wed, 11 Jun 2008 15:15:35 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id cdH61Z01H0mlR8UA60T200; Wed, 11 Jun 2008 22:16:01 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id cmFx1Z00302AVH08XmFyro; Wed, 11 Jun 2008 22:15:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=GlO_jEE4dgMA:10 a=CICIjtp2axAA:10 a=2G-c3ynMm1lOro69YRkA:9 a=s22AEXlEEX0aThAt_eMA:7 a=l-IC0G_Tg5yEhMW4xz1EGJm01bEA:4 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5BMFuPO002479 for ; Wed, 11 Jun 2008 18:15:56 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5BMFuTo002475; Wed, 11 Jun 2008 18:15:56 -0400 Date: Wed, 11 Jun 2008 18:15:56 -0400 Message-Id: <200806112215.m5BMFuTo002475@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (barcaroller@sympatico.ca) References: Subject: Re: [Sip] Request/response question... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: I have a basic SIP question. The way I understood RFC3261, the "To:" header field in a response has to match the "To:" header field of the corresponding request (if no To tag is present in the request). This is true for 99% of the SIP conversations I've seen but not for the (real-life) example below (note that the "To:" header fields differ). Wireshark has no problem with analyzing this SIP conversation, so I suspect I'm misinterpreting the RFC. Can the "To:" header fields be different, and if so, how can the response be correlated to the request? The RFC does require the To (and From) headers to match, but everybody believes that is an obsolete requirement and will probably be relaxed in the near future. So generate requests with matching To/From headers, but do not depend on them. Requests and responses are correlated by the branch parameters in their Via headers. Requests are grouped into dialogs by their "dialog identifiers", that is, call-id/to-tag/from-tag. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 11 15:23:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F933A69ED; Wed, 11 Jun 2008 15:23:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E3E3A69ED for ; Wed, 11 Jun 2008 15:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDl-cbOxWxlE for ; Wed, 11 Jun 2008 15:23:22 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 9679D3A69A2 for ; Wed, 11 Jun 2008 15:23:22 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5BMNjh00769; Wed, 11 Jun 2008 22:23:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 17:23:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF17565CF2@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Request/response question... Thread-Index: AcjMDkAX7sWbmnYOQ/GkA17ETofXKQAAILmQ References: From: "Francois Audet" To: , Subject: Re: [Sip] Request/response question... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org See section 3 of http://www.ietf.org/rfc/rfc4916.txt. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of barcaroller@sympatico.ca > Sent: Wednesday, June 11, 2008 14:55 > To: sip@ietf.org > Subject: [Sip] Request/response question... > > > I have a basic SIP question. The way I understood RFC3261, > the "To:" header field in a response has to match the "To:" > header field of the corresponding request (if no To tag is > present in the request). This is true for 99% of the SIP > conversations I've seen but not for the (real-life) example > below (note that the "To:" header fields differ). Wireshark > has no problem with analyzing this SIP conversation, so I > suspect I'm misinterpreting the RFC. > > Can the "To:" header fields be different, and if so, how can > the response be correlated to the request? > > > # > # The request > # > INVITE sip:5557451576@e.voncp.com:10000 SIP/2.0 > Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2 > From: 555-482-0690 > ;tag=716ff48d4ef52332o0 > To: > Remote-Party-ID: 555-482-0690 > ;screen=yes;party=calling > Call-ID: 81f537e9-aaa35786@192.168.5.156 > CSeq: 102 INVITE > Max-Forwards: 70 > Proxy-Authorization: Digest > username="15554820690",realm="69.59.242.85",nonce="1489356920" > ,uri="sip:5557451576@e.voncp.com:10000",algorithm=MD5,response ="095bb689741268d970ca807964d58a73" > Contact: 555-482-0690 > Expires: 240 > User-Agent: 001310757539 Linksys/RT31P2-3.1.6(LI) > Content-Length: 316 > > > # > # The response > # > SIP/2.0 200 OK > Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2 > From: 555-482-0690 > ;tag=716ff48d4ef52332o0;nat > ted=24.235.117.242 > To: ;tag=1645248237 > Call-ID: 81f537e9-aaa35786@192.168.5.156 > CSeq: 102 INVITE > Contact: > Max-Forwards: 15 > > > > # > # The relevant RFC section > # > 8.2.6.2 Headers and Tags > > > The From field of the response MUST equal the From header field of > the request. The Call-ID header field of the response > MUST equal the > Call-ID header field of the request. The CSeq header field of the > response MUST equal the CSeq field of the request. The Via header > field values in the response MUST equal the Via header field values > in the request and MUST maintain the same ordering. > > If a request contained a To tag in the request, the To header field > in the response MUST equal that of the request. However, if the To > header field in the request did not contain a tag, the URI > in the To > header field in the response MUST equal the URI in the To header > field; additionally, the UAS MUST add a tag to the To > header field in > the response (with the exception of the 100 (Trying) response, in > which a tag MAY be present). This serves to identify the > UAS that is > responding, possibly resulting in a component of a dialog ID. The > same tag MUST be used for all responses to that request, both final > and provisional (again excepting the 100 (Trying)). Procedures for > the generation of tags are defined in Section 19.3. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 11 15:26:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA8F3A6A22; Wed, 11 Jun 2008 15:26:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6753A6911 for ; Wed, 11 Jun 2008 15:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNQLVefsBni6 for ; Wed, 11 Jun 2008 15:26:29 -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 C34613A6A03 for ; Wed, 11 Jun 2008 15:26:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,626,1204531200"; d="scan'208";a="56034828" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2008 15:26:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5BMQuDv022575; Wed, 11 Jun 2008 15:26:56 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5BMQtb4005927; Wed, 11 Jun 2008 22:26:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 18:26:56 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 18:26:55 -0400 Message-ID: <4850515D.8040008@cisco.com> Date: Wed, 11 Jun 2008 18:27:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <200806112215.m5BMFuTo002475@dragon.ariadne.com> In-Reply-To: <200806112215.m5BMFuTo002475@dragon.ariadne.com> X-OriginalArrivalTime: 11 Jun 2008 22:26:55.0785 (UTC) FILETIME=[41586990:01C8CC12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1948; t=1213223216; x=1214087216; c=relaxed/simple; s=sjdkim2002; 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[Sip]=20Request/response=20question... |Sender:=20; bh=u9iwdJK3sEDhBZ1Y7kQ7mYn5yr39W5sT+N8D6sOTIOo=; b=hm5UAuxqKZIUOzfIdvQgPqCiROlmWmSCWGmFcEmAV4xvrXW8eOQ7C+ZeZt DP4B6X5U0M+NGMCHyca9A7er+OCeMSV+iwBhP3Xydnu2HjsAAxbIhNMBZXtu LH7GqCmqmD; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Request/response question... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: > > I have a basic SIP question. The way I understood RFC3261, the "To:" header > field in a response has to match the "To:" header field of the > corresponding request (if no To tag is present in the request). This is > true for 99% of the SIP conversations I've seen but not for the (real-life) > example below (note that the "To:" header fields differ). Wireshark has no > problem with analyzing this SIP conversation, so I suspect I'm > misinterpreting the RFC. > > Can the "To:" header fields be different, and if so, how can the > response be correlated to the request? > > The RFC does require the To (and From) headers to match, but everybody > believes that is an obsolete requirement and will probably be relaxed > in the near future. So generate requests with matching To/From > headers, but do not depend on them. AFAIK there is no agreement that they shouldn't match in a request and its *response*. Most do now agree that they might change for subsequent requests within a dialog. At one point there may have been a little talk about changing the To in a response to indicate the actual identity of the called party. But once it was realized there was no good way to authenticate that we stopped talking about it. (At least that is what I remember.) Paul > Requests and responses are correlated by the branch parameters in > their Via headers. > > Requests are grouped into dialogs by their "dialog identifiers", that > is, call-id/to-tag/from-tag. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 11 19:24:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EA93A6878; Wed, 11 Jun 2008 19:24:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7123A6878 for ; Wed, 11 Jun 2008 19:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+ko4w1Wqp05 for ; Wed, 11 Jun 2008 19:24:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4E7A23A6855 for ; Wed, 11 Jun 2008 19:24:47 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5C2O88R023116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Jun 2008 21:24:10 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <4850515D.8040008@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 11 Jun 2008 21:24:03 -0500 References: <200806112215.m5BMFuTo002475@dragon.ariadne.com> <4850515D.8040008@cisco.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] Request/response question... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 11, 2008, at 5:27 PM, Paul Kyzivat wrote: > > > Dale.Worley@comcast.net wrote: >> From: >> >> I have a basic SIP question. The way I understood RFC3261, the >> "To:" header >> field in a response has to match the "To:" header field of the >> corresponding request (if no To tag is present in the request). >> This is >> true for 99% of the SIP conversations I've seen but not for the >> (real-life) >> example below (note that the "To:" header fields differ). >> Wireshark has no >> problem with analyzing this SIP conversation, so I suspect I'm >> misinterpreting the RFC. >> >> Can the "To:" header fields be different, and if so, how can the >> response be correlated to the request? >> >> The RFC does require the To (and From) headers to match, but >> everybody >> believes that is an obsolete requirement and will probably be relaxed >> in the near future. So generate requests with matching To/From >> headers, but do not depend on them. > > AFAIK there is no agreement that they shouldn't match in a request and > its *response*. Most do now agree that they might change for > subsequent > requests within a dialog. > > At one point there may have been a little talk about changing the To > in > a response to indicate the actual identity of the called party. But > once > it was realized there was no good way to authenticate that we stopped > talking about it. (At least that is what I remember.) > Changing it in a response is critical to extending RFC 4474 for use in responses where there are certificates available in the UAs or where identity-based signatures are used. In other words, IF we solve the PKI problem and don't get distracted by the unanticipated respondent problem, then we NEED variant To in responses to be able to se response-identity, because connected- identity is a) late in a dialog and b) useless for non-dialog transactions, like MESSAGE. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 02:34:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713C63A69AC; Thu, 12 Jun 2008 02:34:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5237E3A69AC for ; Thu, 12 Jun 2008 02:34:19 -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 P1W8Dw0fx8A2 for ; Thu, 12 Jun 2008 02:34:18 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 25FA03A697D for ; Thu, 12 Jun 2008 02:34:17 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5C9Y982013974; Thu, 12 Jun 2008 12:34:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 12:34:28 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 12:34:28 +0300 Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5C9YQF3008647; Thu, 12 Jun 2008 12:34:26 +0300 From: Aki Niemi To: ext cco In-Reply-To: <20080610102724.GE4685@shell> References: <20080606093036.GA4685@shell> <48494E97.2010108@fokus.fraunhofer.de> <20080608200846.GA6325@shell> <1213088143.9973.5.camel@little.research.nokia.com> <20080610102724.GE4685@shell> Organization: Nokia Devices R&D Date: Thu, 12 Jun 2008 12:34:28 +0300 Message-Id: <1213263268.9973.38.camel@little.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-OriginalArrivalTime: 12 Jun 2008 09:34:28.0375 (UTC) FILETIME=[828CA270:01C8CC6F] X-Nokia-AV: Clean Cc: sip@ietf.org, Dragos Vingarzan Subject: Re: [Sip] aka authentication and sip (rfc 3310) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ti, 2008-06-10 kello 12:27 +0200, ext cco kirjoitti: > On Tue, Jun 10, 2008 at 11:55:43AM +0300, Aki Niemi wrote: > > su, 2008-06-08 kello 22:08 +0200, ext cco kirjoitti: > > > now, the call flows given as an example would function when the > > > challenge (nonce) does not explicitly depend on the user which is > > > actually trying to register itself, being generated > > > (periodically) by the sip proxy itself; that is they are o.k. for an > > > HTTP digest MD5 auth. as spec. in rfc 3261/rfc 2617. but they do NOT seem to > > > function in the real world when AKA is used, because: > > > > > > 1. the challenge is user specific. > > > 2. the "network" authenticates itself to the UE as well in case of AKA. > > > > In an environment with plain RFC3310, an extra round trip would be > > required. The main user of this spec, namely 3GPP fixes this by > > cristian: hi. aki, thanks a lot for the reply. I still have some > questions though. lets take it one step at a time. "an extra round trip > would be required" means that the call flow given as an example in the > rfc lacks that round trip, right? why? Well, the REGISTER header is not visible, so it indeed could contain an Authorization field, as it normally would if there are cached credentials. > > requiring the presence of the Authorization field in the initial > > REGISTER. > > cristian: why not specifying this in the rfc as well? I don't think it matters. I can't see Digest AKA very useful beyond 3GPP IMS anyway, which means implementing a bunch of their TSs. > now, as I see it, the problem is that a lot of ue sip stacks implementors > would take the rfc word for word and implement their software exactly > how it is specified in the rfc. Not necessarily a bad thing... > and in the end, everyone will wonder > why the call flow in rfc3310 does not work or when it works it looks > quite differently... There isn't a big difference, really. Look at it as there always being a set of cached credentials at the UA that are included in every REGISTER. It just happens that the UA always gets a 401 in response. Cheers, Aki _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 03:09:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BE53A69EC; Thu, 12 Jun 2008 03:09:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDC23A69EC for ; Thu, 12 Jun 2008 03:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.786 X-Spam-Level: * X-Spam-Status: No, score=1.786 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbzWSH+-smVI for ; Thu, 12 Jun 2008 03:09:15 -0700 (PDT) Received: from poczta.o2.pl (mx10.go2.pl [193.17.41.74]) by core3.amsl.com (Postfix) with ESMTP id 329023A697A for ; Thu, 12 Jun 2008 03:09:15 -0700 (PDT) Received: from poczta.o2.pl (mx10.go2.pl [127.0.0.1]) by poczta.o2.pl (Postfix) with ESMTP id E5B8458009 for ; Thu, 12 Jun 2008 12:09:44 +0200 (CEST) Received: from [192.168.6.244] (unknown [195.117.141.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP for ; Thu, 12 Jun 2008 12:09:43 +0200 (CEST) Message-ID: <4850F5E4.30408@o2.pl> Date: Thu, 12 Jun 2008 12:09:40 +0200 From: Maciej Kowalski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: sip@ietf.org Subject: [Sip] Both sides of dialog sending request at the same time X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Everybody. I'm currently working on SIP/TDM Gateway application. I've encountered following problem. During Sip dialog both sides at the exactly same moment send Re-Invite requests. Those are reaching their destinations while both client are expecting replies. What should be the behavior of SIP client in a situation like that. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 03:58:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B3E3A68D4; Thu, 12 Jun 2008 03:58:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0EB3A68D4 for ; Thu, 12 Jun 2008 03:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIkGS04H-EgT for ; Thu, 12 Jun 2008 03:58:00 -0700 (PDT) Received: from n59.bullet.mail.sp1.yahoo.com (n59.bullet.mail.sp1.yahoo.com [98.136.44.43]) by core3.amsl.com (Postfix) with SMTP id 3B0C43A68BC for ; Thu, 12 Jun 2008 03:57:59 -0700 (PDT) Received: from [216.252.122.216] by n59.bullet.mail.sp1.yahoo.com with NNFMP; 12 Jun 2008 10:58:22 -0000 Received: from [69.147.65.166] by t1.bullet.sp1.yahoo.com with NNFMP; 12 Jun 2008 10:58:22 -0000 Received: from [127.0.0.1] by omp501.mail.sp1.yahoo.com with NNFMP; 12 Jun 2008 10:58:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 221203.52081.bm@omp501.mail.sp1.yahoo.com Received: (qmail 78836 invoked by uid 60001); 12 Jun 2008 10:58:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=jZYugnKvjeM+9/VIq4tDi32OMWherJaRMU6Nxgd6MZPTkggLyynyoe/6hTQs+52RHxEktBkfhxfMGfUAdcd0wPyQHmg02Azq2JOf3aWtR3nnN0ig78Sc7jvDkOeAC9zm5z3vtRXhVyBV0sjc+euenBf88Yi1akzKIm9UIGhggPg=; Received: from [121.241.96.5] by web8413.mail.in.yahoo.com via HTTP; Thu, 12 Jun 2008 16:28:20 IST X-Mailer: YahooMailWebService/0.7.199 Date: Thu, 12 Jun 2008 16:28:20 +0530 (IST) From: atul garg To: sip@ietf.org MIME-Version: 1.0 Message-ID: <37104.78503.qm@web8413.mail.in.yahoo.com> Subject: [Sip] PTT query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: shivalk_80@yahoo.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, I have a question regarding push to talk message . Is there any way through which I can identify that particular SIP message is meant for PTT ie. this sip message is a part of some Push To Talk session.. Like through which I can filter that such message is for PTT. Such criteria which can be applicable on all SIP messages ie. 1) Invite 2) Register 3) 2xx/1xx/4xx/3xx etc. responces .. .. etc. Thnx Atul From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From ca@moaaz.ca Thu Jun 12 04:13:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70C43A6878; Thu, 12 Jun 2008 04:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -58.526 X-Spam-Level: X-Spam-Status: No, score=-58.526 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 wJtNXUwOtvMs; Thu, 12 Jun 2008 04:13:34 -0700 (PDT) Received: from 62.42.146.247.dyn.user.ono.com (62.42.146.247.dyn.user.ono.com [62.42.146.247]) by core3.amsl.com (Postfix) with SMTP id 24D2D3A698E; Thu, 12 Jun 2008 04:13:26 -0700 (PDT) X-Originating-IP: 92.194.228.54 by smtp.62.42.146.247; Thu, 12 Jun 2008 07:13:53 -0500 Message-ID: From: "Angelo Cruz" Reply-To: "Angelo Cruz" To: shelley.osborn@ietf.org Subject: Spring quality watches offer Date: Thu, 12 Jun 2008 07:13:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://tasaxowegyh30.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://tasaxowegyh30.blogspot.com/ From sip-bounces@ietf.org Thu Jun 12 05:27:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E543A6878; Thu, 12 Jun 2008 05:27:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E096D3A68AF for ; Thu, 5 Jun 2008 15:16:21 -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 fbwc0eooKpaS for ; Thu, 5 Jun 2008 15:16:21 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 9D90E3A684E for ; Thu, 5 Jun 2008 15:16:20 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so633996ugd.46 for ; Thu, 05 Jun 2008 15:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=pqA21LE75iAvg53q0jl2wfLKZGQpSMxwesBMWp3N4oE=; b=jnaGOTsH4YjTMUuAmJlXAsm/CsMhlFLVH3m3Zqp7JG9D7jaQaY9nbLWHhzIdkyR+UT N1JPKpbu0irQCawNKEUpdtz0Umes4ROf/2T9m7ADQqca7oCEFpn9XTOpxtlvUlSsiqEm mmxtCC+z0iB11gfAnK86i/77tKwPK+KmAzdjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=JmQUVPNgvEz4kCkbIAD6TsKBzckSALZSIVwMu7I/K9gsKF5ASjaamyegmFfmXZvj9w a/N6hjw6ZEmwuFjAcFOLaM8YzG1BrpnULLnY+VVfrxrf3/JgCA0iOn2jpMxw7e+gVM+I zgN63+GcPN0LN3pT5MCMS8/YzYP8lty9oQJow= Received: by 10.210.43.11 with SMTP id q11mr1424763ebq.196.1212704185391; Thu, 05 Jun 2008 15:16:25 -0700 (PDT) Received: by 10.210.23.18 with HTTP; Thu, 5 Jun 2008 15:16:25 -0700 (PDT) Message-ID: <9f07b7680806051516i336f4eb9ofd97dcc5d521a224@mail.gmail.com> Date: Thu, 5 Jun 2008 18:16:25 -0400 From: "Chris Liu" To: sip@ietf.org, discussion@sipforum.org MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Thu, 12 Jun 2008 05:27:28 -0700 Subject: [Sip] SIP feature support question? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello all, I got a few questions as below want to hear your inputs: Is there anyone implemented SIP to support long call audit? (e.g. SIP INFO, SIP re-INVITE with SDP)? How do you implement SIP to support the use of the DIVERSION header and under what circumtances this DIVERSION header is been provaked? (Such as call forwading?) If so, do you support sending privacy information via the DIVERSION header? Thanks for sharing. Chris On 6/4/08, Yuantao Zhang wrote: > Dear all > > > > INVITE sip:bob@biloxi.com SIP/2.0:5555 > > INVITE sip:bob@biloxi.com SIP/2.0 > > > > Above are 2 "Invite" request-line examples. In example one, it indicates > a port number, 5555. What does the port number mean? > > > > Is it the port number of SIP proxy? Why we include port number here? The > SIP proxy(biloxi.com) application layer who receives this "Invite" > should receive this via port 5555 from lowe layer(UDP). Therefore, The > SIP proxy(biloxi.com) application layer already know the port is 5555. > Actualy, the SIP proxy application layer keeps listening port 5555. > > > > The second "Invite" request-line example is from RFC3261 and does not > include port number. Can I say the port number is useless? So why > example one includes a useless part in "Invite" request-line URL? > > > > Or is the port number is which the UAS is listening to? How the UAC > knows it is 5555 if so? > > > > Any standard on this port number issue? Thanks. > > > > Best regards > > Steven > > -- Sent from Gmail for mobile | mobile.google.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 05:28:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014343A6AAB; Thu, 12 Jun 2008 05:28:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A123A68EF for ; Thu, 5 Jun 2008 16:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, WEIRD_PORT=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 pajRabayBu2R for ; Thu, 5 Jun 2008 16:22:53 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by core3.amsl.com (Postfix) with ESMTP id 9E62B3A6826 for ; Thu, 5 Jun 2008 16:22:53 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so517558pyg.24 for ; Thu, 05 Jun 2008 16:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=LvdKqYBQ5Wex5noAXTyVXoYROZvwtpN6ZxSiNku/k7g=; b=rxppwewHYV6IRZO7rlg7ksiqxQt9ClUC2HPKD3uFypDE1mOB4dDxjCc5LD4DegaMPj l6xYDBQPB1ijUEERSf5GUq49GM4tCMXH3K2ZBPBgT48erXEGFO50lr1R+b8ThId1Kcl5 UBw3AlkeaCC8fF7LNHFhtBVPn1lSbrKOR9Y7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=Cu7vWOVxcBsjGm4uYZAu0MUYaptUZ9CR5VPuHSZtbhT4PvPPhFJnNnAXFnrA4q9F1m ZIv5Oig8ZnGQsgsuaEoPNISC6GfufFI0NMcb8sXmwO/YFrCoWsvuRjIARQiHPaY7K/tQ GvPeVCMON6dTiGRzKHiSYlCd9/TICXb+O6UHs= Received: by 10.143.156.15 with SMTP id i15mr804166wfo.4.1212708178235; Thu, 05 Jun 2008 16:22:58 -0700 (PDT) Received: by 10.142.50.17 with HTTP; Thu, 5 Jun 2008 16:22:58 -0700 (PDT) Message-ID: <81237f640806051622h323d7f87g8392c5645e38975f@mail.gmail.com> Date: Fri, 6 Jun 2008 02:22:58 +0300 From: "Liran Tal" To: "Yuantao Zhang" , discussion@sipforum.org In-Reply-To: <063001c8c746$6e1c84a0$4a558de0$@com> MIME-Version: 1.0 References: <063001c8c746$6e1c84a0$4a558de0$@com> X-Google-Sender-Auth: 78fc75800ee641ee X-Mailman-Approved-At: Thu, 12 Jun 2008 05:28:01 -0700 Cc: sip@ietf.org, sbasan@10levels.com Subject: Re: [Sip] [SIPForum-discussion] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1957077193==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1957077193== Content-Type: multipart/alternative; boundary="----=_Part_3351_27023946.1212708178220" ------=_Part_3351_27023946.1212708178220 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey Yuantao, > *From:* discussion-bounces@sipforum.org [mailto: > discussion-bounces@sipforum.org] *On Behalf Of *Yuantao Zhang > *Sent:* Wednesday, June 04, 2008 12:10 > *To:* sip@ietf.org; discussion@sipforum.org > *Subject:* [SIPForum-discussion] What is the port number in "Invite" > request-line? Thanks > > Dear all > > INVITE sip:bob@biloxi.com SIP/2.0:5555 > > INVITE sip:bob@biloxi.com SIP/2.0 > > Above are 2 "Invite" request-line examples. In example one, it indicates a > port number, 5555. What does the port number mean? Is it the port number > of SIP proxy? > As you suspected yourself and as Shmulik pointed correctly, the number 555 indicates the port number of the running SIP Proxy which the UA is registered to. > Why we include port number here? The SIP proxy(biloxi.com) application > layer who receives > Simply because this is a non-standard SIP port, just as if a web server was running on port 8081 you would have to explicitly tell the browser to use that port, for example: http://www.non-standard-server.com:8081 This is also required when more than one SIP Proxy is involved in the process and the INVITE travels from one proxy to another. The second "Invite" request-line example is from RFC3261 and does not > include port number. Can I say the port number is useless? So why example > one includes a useless part in "Invite" request-line URL? > To be more precise the first invite message (INVITE sip:bob@biloxi.comSIP/2.0:5555) is wrong. It should have been INVITE sip:bob@biloxi.com:5555 SIP/2.0 > Any standard on this port number issue? Thanks. > It is very common for different SIP stacks to behave somewhat differently and quite a few of them do not comply with the RFC which is very unfortunate. -- -- Regards, *Liran Tal **Unix Kernel Developer NGN Solutions, TELES Israel * [image: [Teles Logo]] Phone +972 4 9092592 Fax +972 4 9597144 Mobile +972 52 3793446 ------=_Part_3351_27023946.1212708178220 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey Yuantao,


From: discussion-bounces@sipforum.org [mailto:discussion-bounces@sipforum.org] On Behalf Of Yuantao Zhang
Sent: Wednesday, June 04, 2008 12:10
To: sip@ietf.org; discussion@sipforum.org
Subject: [SIPForum-discussion] What is the port number in "Invite" request-line? Thanks

Dear all

INVITE sip:bob@biloxi.com SIP/2.0:5555

INVITE sip:bob@biloxi.com SIP/2.0

Above are 2 "Invite" request-line examples. In example one, it indicates a port number, 5555. What does the port number mean? Is it the port number of SIP proxy?

As you suspected yourself and as Shmulik pointed correctly, the number 555 indicates
the port number of the running SIP Proxy which the UA is registered to.

Why we include port number here? The SIP proxy(biloxi.com) application layer who receives

Simply because this is a non-standard SIP port, just as if a web server was running on port
8081 you would have to explicitly tell the browser to use that port, for example:
http://www.non-standard-server.com:8081

This is also required when more than one SIP Proxy is involved in the process and the
INVITE travels from one proxy to another.

 The second "Invite" request-line example is from RFC3261 and does not include port number. Can I say the port number is useless? So why example one includes a useless part in "Invite" request-line URL?

To be more precise the first invite message (INVITE sip:bob@biloxi.com SIP/2.0:5555)
is wrong. It should have been INVITE sip:bob@biloxi.com:5555 SIP/2.0 

Any standard on this port number issue? Thanks.

It is very common for different SIP stacks to behave somewhat differently and quite
a few of them do not comply with the RFC which is very unfortunate.




--
--
Regards,

Liran Tal
Unix Kernel Developer
NGN Solutions, TELES Israel

[Teles Logo]

Phone           +972 4 9092592
Fax               +972 4 9597144
Mobile           +972 52 3793446

------=_Part_3351_27023946.1212708178220-- --===============1957077193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1957077193==-- From sip-bounces@ietf.org Thu Jun 12 05:28:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37D728C111; Thu, 12 Jun 2008 05:28:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DD528C2B7 for ; Thu, 5 Jun 2008 12:00:26 -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 Z4buuxIUJoMX for ; Thu, 5 Jun 2008 12:00:20 -0700 (PDT) Received: from dns.org.il (mail.dns.org.il [82.80.253.7]) by core3.amsl.com (Postfix) with ESMTP id B63773A6B02 for ; Thu, 5 Jun 2008 11:57:59 -0700 (PDT) Received: from sbasanlaptop [89.0.1.154] by dns.org.il with ESMTP (SMTPD-8.22) id A7330338; Thu, 05 Jun 2008 21:57:55 +0300 From: "Shmulik Basan" To: "'Yuantao Zhang'" , , References: In-Reply-To: Date: Thu, 5 Jun 2008 21:57:48 +0200 Organization: 10levels Message-ID: <063001c8c746$6e1c84a0$4a558de0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aci7y8Ccu2ENUpcER8SVd+I4biihjwAHYouwAABEjdACjSM50ABEeY3Q Content-Language: en-us X-Mailman-Approved-At: Thu, 12 Jun 2008 05:28:56 -0700 Subject: Re: [Sip] [SIPForum-discussion] What is the port number in "Invite" request-line? Thanks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sbasan@10levels.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1032173765==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1032173765== Content-Type: multipart/related; boundary="----=_NextPart_000_0631_01C8C757.31A554A0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0631_01C8C757.31A554A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0632_01C8C757.31A554A0" ------=_NextPart_001_0632_01C8C757.31A554A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stevan hi, The reason is that the proxy is listening to port 5555. By example one it reference to send the SIP message to this port (port 5555). By using example two, the SIP message will be sent to the default SIP port (i.e. 5060) Sincerely, * Sam Basan From: discussion-bounces@sipforum.org [mailto:discussion-bounces@sipforum.org] On Behalf Of Yuantao Zhang Sent: Wednesday, June 04, 2008 12:10 To: sip@ietf.org; discussion@sipforum.org Subject: [SIPForum-discussion] What is the port number in "Invite" request-line? Thanks Dear all INVITE sip:bob@biloxi.com SIP/2.0:5555 INVITE sip:bob@biloxi.com SIP/2.0 Above are 2 "Invite" request-line examples. In example one, it indicates a port number, 5555. What does the port number mean? Is it the port number of SIP proxy? Why we include port number here? The SIP proxy(biloxi.com) application layer who receives this "Invite" should receive this via port 5555 from lowe layer(UDP). Therefore, The SIP proxy(biloxi.com) application layer already know the port is 5555. Actualy, the SIP proxy application layer keeps listening port 5555. The second "Invite" request-line example is from RFC3261 and does not include port number. Can I say the port number is useless? So why example one includes a useless part in "Invite" request-line URL? Or is the port number is which the UAS is listening to? How the UAC knows it is 5555 if so? Any standard on this port number issue? Thanks. Best regards Steven __________ Information from ESET Smart Security, version of virus signature database 3157 (20080604) __________ The message was checked by ESET Smart Security. http://www.eset.com ------=_NextPart_001_0632_01C8C757.31A554A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MUST 200 OK contain SDP? Thanks

Stevan hi,

 

The reason is that the proxy is listening to port = 5555.

By example one it reference to send the SIP message to = this port (port 5555).

By using example two, the SIP message will be sent to the default SIP port (i.e. 5060)

 

 

 

Sincerely,

3D"*" 

Sam Basan

 

From:= discussion-bounces@sipforum.org [mailto:discussion-bounces@sipforum.org] = On Behalf Of Yuantao Zhang
Sent: Wednesday, June 04, 2008 12:10
To: sip@ietf.org; discussion@sipforum.org
Subject: [SIPForum-discussion] What is the port number in "Invite" request-line? Thanks

 

Dear all

 

INVITE sip:bob@biloxi.com SIP/2.0:5555

INVITE sip:bob@biloxi.com SIP/2.0

 

Above are 2 “Invite” request-line examples. In = example one, it indicates a port number, 5555. What does the port number mean? =

 

Is it the port number of SIP proxy? Why we include port = number here? The SIP proxy(biloxi.com) application layer who receives this "Invite" should receive this via port 5555 from lowe = layer(UDP). Therefore, The SIP proxy(biloxi.com) application layer already know the = port is 5555. Actualy, the SIP proxy application layer keeps listening port = 5555.

 

The second “Invite” request-line example is from RFC3261 and does not include port number. Can I say the port number is = useless? So why example one includes a useless part in “Invite” = request-line URL?

 

Or is the port number is which the UAS is listening to? How = the UAC knows it is 5555 if so?

 

Any standard on this port number issue? Thanks. =

 

Best regards

Steven



__________ Information from ESET Smart Security, version of virus = signature database 3157 (20080604) __________

The message was checked by ESET Smart Security.

http://www.eset.com



__________ Information from ESET Smart Security, version of = virus signature database 3161 (20080605) __________

The message = was checked by ESET Smart Security.

http://www.eset.com
------=_NextPart_001_0632_01C8C757.31A554A0-- ------=_NextPart_000_0631_01C8C757.31A554A0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAZACMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDqPEeo eM5/GD6Z4clVYI4Y3kLxptj3Z5JIz2/Sorj/AITePxPbaJD4jikMtubiWY2aARqDg8Y55/nWV4tu Z7f4taeIZ5Iw5twwRiNw3Hg+tdof+Skr/wBgk/8Ao2ut+6lotuxyL3m9Xv3MHXJ/Fdho1zqml+KY 7+OzdkuENmiFSpw2OO1Fz45v7XStK2XFk9zcWYkuGnO0qxAIOBjgjPHc46VMP+RF8Vf9fV5/OsPV i6+GfDBSS7H+h8pbru3cAcrkZ/OnFJ6Ndf0FJtap9P1PULGZ7iwt55Nm+SJXbYcrkgE49qKTTwRp 1sCZCRCnMww/Qfe9/WiuR7nWtjzvxf4e1y48fWusWOlyXdtAImJR1XcVYkjk1dubzxS3i231q38L XKwpbG3mheePLAtuyCD9K7+itfa6JNbGXsldtM8+1s63NoF5pejeFLuA38jvPJPNGcFjlsAMetQX 2h3U+kaPZ3Oj6u09jaKu+1eLZkjlSGPXtXpFFCqtbIHST3ZW05Gj0y1jdGjZYUBRm3FSFHBPf60V ZorE2P/Z ------=_NextPart_000_0631_01C8C757.31A554A0-- --===============1032173765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1032173765==-- From sip-bounces@ietf.org Thu Jun 12 05:32:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EE53A6892; Thu, 12 Jun 2008 05:32:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7526D3A6A75 for ; Thu, 12 Jun 2008 05:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmrBIVa0niJP for ; Thu, 12 Jun 2008 05:32:08 -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 E49BD3A6892 for ; Thu, 12 Jun 2008 05:32:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,631,1204520400"; d="scan'208";a="10819682" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2008 08:32:35 -0400 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 m5CCWZbE001990; Thu, 12 Jun 2008 08:32:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5CCWZ8f017710; Thu, 12 Jun 2008 12:32:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 08:32:35 -0400 Received: from [10.86.240.29] ([10.86.240.29]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 08:32:35 -0400 Message-ID: <4851178E.9060103@cisco.com> Date: Thu, 12 Jun 2008 08:33:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dean Willis References: <200806112215.m5BMFuTo002475@dragon.ariadne.com> <4850515D.8040008@cisco.com> In-Reply-To: X-OriginalArrivalTime: 12 Jun 2008 12:32:35.0191 (UTC) FILETIME=[64635870:01C8CC88] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2139; t=1213273955; x=1214137955; 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[Sip]=20Request/response=20question... |Sender:=20 |To:=20Dean=20Willis=20; bh=GGhfN2ERqJJ+XJHDTU8TPT2aIFjD2wZGvSRS9ObU2FE=; b=yB63nnZP8ASnJYt1efd3Y7ZQBvs236yrKLU3xKNTOLrYONCTN6z74z+aN2 0tmcKKF5iGvgXEAI/JnJpWuRxyldt02eZeyAmbY2NKZYCfceots5bZt8P+oT XudWAcmRKe; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Request/response question... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ok, I stand corrected. Thanks, Paul Dean Willis wrote: > > On Jun 11, 2008, at 5:27 PM, Paul Kyzivat wrote: > >> >> >> Dale.Worley@comcast.net wrote: >>> From: >>> >>> I have a basic SIP question. The way I understood RFC3261, the >>> "To:" header >>> field in a response has to match the "To:" header field of the >>> corresponding request (if no To tag is present in the request). >>> This is >>> true for 99% of the SIP conversations I've seen but not for the >>> (real-life) >>> example below (note that the "To:" header fields differ). >>> Wireshark has no >>> problem with analyzing this SIP conversation, so I suspect I'm >>> misinterpreting the RFC. >>> >>> Can the "To:" header fields be different, and if so, how can the >>> response be correlated to the request? >>> >>> The RFC does require the To (and From) headers to match, but everybody >>> believes that is an obsolete requirement and will probably be relaxed >>> in the near future. So generate requests with matching To/From >>> headers, but do not depend on them. >> >> AFAIK there is no agreement that they shouldn't match in a request and >> its *response*. Most do now agree that they might change for subsequent >> requests within a dialog. >> >> At one point there may have been a little talk about changing the To in >> a response to indicate the actual identity of the called party. But once >> it was realized there was no good way to authenticate that we stopped >> talking about it. (At least that is what I remember.) >> > > Changing it in a response is critical to extending RFC 4474 for use in > responses where there are certificates available in the UAs or where > identity-based signatures are used. > > In other words, IF we solve the PKI problem and don't get distracted by > the unanticipated respondent problem, then we NEED variant To in > responses to be able to se response-identity, because connected-identity > is a) late in a dialog and b) useless for non-dialog transactions, like > MESSAGE. > > -- > Dean > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 05:46:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD603A689B; Thu, 12 Jun 2008 05:46:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCF93A689B for ; Thu, 12 Jun 2008 05:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 eqqoZ4bmylLr for ; Thu, 12 Jun 2008 05:46:36 -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 253383A67D9 for ; Thu, 12 Jun 2008 05:46:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,631,1204520400"; d="scan'208";a="10821035" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2008 08:47:04 -0400 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 m5CCl4m7005808; Thu, 12 Jun 2008 08:47:04 -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.13.8) with ESMTP id m5CCl406007444; Thu, 12 Jun 2008 12:47:04 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 08:47:04 -0400 Received: from [10.86.240.29] ([10.86.240.29]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 08:47:03 -0400 Message-ID: <48511AF3.8000305@cisco.com> Date: Thu, 12 Jun 2008 08:47:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Maciej Kowalski References: <4850F5E4.30408@o2.pl> In-Reply-To: <4850F5E4.30408@o2.pl> X-OriginalArrivalTime: 12 Jun 2008 12:47:03.0804 (UTC) FILETIME=[6A1F2BC0:01C8CC8A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=947; t=1213274824; x=1214138824; 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[Sip]=20Both=20sides=20of=20dialog=20se nding=20request=20at=20the=20same=20time |Sender:=20 |To:=20Maciej=20Kowalski=20; bh=cI+gPbvCS+DfUjwa9sOg/LPxBXS7xykkMIoVRUZ6zvI=; b=SNwjxvj3mEw673w6Lls4nnWXz2uCZKh0JC2bqEu3GaPDfIXk4LSOR+JxkY p9Pc+sjk+qVN36olMAV298ltM46zI0wJgpkFJPT0xnS9A91uGb+XMuLIuzXL dp1US0SSGv; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Both sides of dialog sending request at the same time X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This situation is known as "glare". It is discussed in rfc 3261 and in http://www.ietf.org/internet-drafts/draft-ietf-sipping-race-examples-05.txt. In short, both sides should send a 491 response, back off, and retry. Paul Maciej Kowalski wrote: > Hi Everybody. > > I'm currently working on SIP/TDM Gateway application. > I've encountered following problem. > During Sip dialog both sides at the exactly same moment send Re-Invite > requests. > Those are reaching their destinations while both client are expecting > replies. What should be the behavior of SIP client in a situation like that. > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 05:53:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573FA3A6A86; Thu, 12 Jun 2008 05:53:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2656F3A6ABF for ; Thu, 12 Jun 2008 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 2YnYS4IEKnjy for ; Thu, 12 Jun 2008 05:53:17 -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 1B31C3A6A75 for ; Thu, 12 Jun 2008 05:53:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,631,1204520400"; d="scan'208";a="10821817" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2008 08:53:45 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5CCri01012132; Thu, 12 Jun 2008 08:53:44 -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.13.8) with ESMTP id m5CCrjEs010214; Thu, 12 Jun 2008 12:53:45 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.1830); Thu, 12 Jun 2008 08:53:45 -0400 Received: from [10.86.240.29] ([10.86.240.29]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 08:53:44 -0400 Message-ID: <48511C83.8090808@cisco.com> Date: Thu, 12 Jun 2008 08:54:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: shivalk_80@yahoo.co.in References: <37104.78503.qm@web8413.mail.in.yahoo.com> In-Reply-To: <37104.78503.qm@web8413.mail.in.yahoo.com> X-OriginalArrivalTime: 12 Jun 2008 12:53:44.0547 (UTC) FILETIME=[58FBB330:01C8CC8B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1063; t=1213275225; x=1214139225; 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[Sip]=20PTT=20query |Sender:=20 |To:=20shivalk_80@yahoo.co.in; bh=7CeDdOxDTPoUnZSera1xC9B7mFazZ69/IngeBgoQ6sY=; b=pw5gLIwlvWgt+DScmj4u8TB1BIipuR/xmjU/LC/vY8Y7qIxQGgFdkC+dM8 zS1d3lqcGAdwI3zNdK7aar3h/zVhX9hC+6DZoDuK00LUFPEG6mcZA5ht62wW 01MVpuek0k; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] PTT query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org atul garg wrote: > Hello, > > I have a question regarding push to talk message . > > Is there any way through which I can identify that particular SIP message is meant for PTT ie. this sip message is a part of some Push To Talk session.. > > Like through which I can filter that such message is for PTT. > > Such criteria which can be applicable on all SIP messages ie. > > 1) Invite > 2) Register > 3) 2xx/1xx/4xx/3xx etc. responces > .. > .. > etc. Are you talking specifically about the 3gpp IMS form of PTT? Or is your question more general? If you are talking about IMS PTT then you should be asking the IMS community, because their soluitons are very unique to their environment. Beyond that, AFAIK there is no specification for how PTT should work. IMO the concept of PTT is about the characteristics of a media session. I don't see why it has anything to do with REGISTER, etc. aside possibly the communication of capabilities, which can be handled via callerprefs / callee capabilities. Thanks, Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 06:18:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A843A6A5E; Thu, 12 Jun 2008 06:18:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88DDD3A6ACF for ; Thu, 12 Jun 2008 06:18:12 -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 r0TZw+9zdOr2 for ; Thu, 12 Jun 2008 06:18:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 453C43A6A5E for ; Thu, 12 Jun 2008 06:18:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5CDIXmq005624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 15:18:33 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5CDIV6m030911; Thu, 12 Jun 2008 15:18:31 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 15:18:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 15:18:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-02 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgAWxgY1AAUrJcgA== References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> From: "Schmidt, Christian 1. (NSN - DE/Muenich)" To: "ext Stuart Hoggan" , "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 12 Jun 2008 13:18:30.0910 (UTC) FILETIME=[CEECB1E0:01C8CC8E] Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, There is a small error in the link, it should be: http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-03.txt It is useful and it should become SIP WG item. Regards Christian -----Urspr=FCngliche Nachricht----- Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im Auftrag von ext = Stuart Hoggan Gesendet: Mittwoch, 11. Juni 2008 00:01 An: DRAGE, Keith (Keith); sip@ietf.org Betreff: Re: [Sip] draft-dotson-sip-mutual-auth-02 All, We have updated the document to incorporate feedback received so far. It now contains a section that helps clarify the motivation. Let us know if you have further comments. = -Stuart > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: Wednesday, June 04, 2008 3:48 AM > To: sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > = > (As SIP WG cochair) > = > This has been raised in the SIP group a couple of times, and we have not > yet gained an idea of whether to proceed with it in the SIP WG or not. > = > There have been a couple of technical comments raised in the past from > the security experts; my understanding is that these have now been > clarified. > = > I believe in the past there has been an interested community that says > this is useful. It has also been clarified that 3GPP would like to use > it in their specifications. > = > So could I ask the WG to look at this document, and formally to indicate > whether they believe some work with this scope should be progressed as a > SIP WG item. > = > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-02.txt > = > So if you support it please indicate to the SIP WG chairs. > = > If you have technical concerns (i.e. it should not proceed because it is > technically flawed beyond fixing) then please ideally mail the list, > although the SIP WG chairs will also accept input. > = > Responses please in 1 calendar week from this date. > = > Regards > = > Keith > = > = > ________________________________ > = > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Stuart Hoggan > Sent: Friday, May 02, 2008 5:15 PM > To: sip@ietf.org > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > = > = > = > Folks, > = > = > = > Based on the feedback received in Philadelphia, we have updated > draft-dotson-sip-mutual-auth. The changes clarify the usage of the > Proxy-Authentication-Info header, including support for multiple values. > = > = > = > = > Any further comments or suggestions will be appreciated. It > would also be nice to obtain WG feedback on pursuing this I-D as a WG > document. > = > = > = > Regards, > = > Stuart > = > = > = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 06:28:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CD63A6AD6; Thu, 12 Jun 2008 06:28:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897493A692C for ; Thu, 12 Jun 2008 06:28:30 -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 l5T8dn9rTwcz for ; Thu, 12 Jun 2008 06:28:26 -0700 (PDT) Received: from dlxapp2.laszlomail.com (dlxapp2.laszlomail.com [168.75.100.14]) by core3.amsl.com (Postfix) with ESMTP id B67CD28C126 for ; Thu, 12 Jun 2008 06:28:26 -0700 (PDT) Received: from dlxapp2 (localhost [127.0.0.1]) by dlxapp2.laszlomail.com (8.14.0/8.14.0) with ESMTP id m5CDT7Pu020753; Thu, 12 Jun 2008 06:29:07 -0700 Received: from [116.233.144.173] by gowebtop.com with HTTP; Thu, 12 Jun 2008 06:29:03 -0700 Date: Thu, 12 Jun 2008 06:29:03 -0700 (PDT) From: Rockson Zhengyu Li To: Maciej Kowalski Message-ID: <1516209671.278911213277347044.JavaMail.lzyiii@localhost> MIME-Version: 1.0 User-Agent: Laszlo Mail 2 X-Originating-IP: [116.233.144.173] Content-Disposition: inline Cc: sip@ietf.org Subject: Re: [Sip] Both sides of dialog sending request at the same time X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org CkJvdGggc2lkZXMgbmVlZCBzZW5kIDQ5MSBQZW5kaW5nIFJlcXVlc3QgYW5kIHN0YXJ0IHRpbWVy IHRvIHJlLXNlbmQgCnJlLUlOVklURSBsYXRlcgoKUmVnYXJkcywKLVJvY2tzb24o5p2O5b6B5a6H KQoKCgpPbiBUaHUsIEp1biAxMiwgMjAwOCBhdCAgNjowOSBQTSwgTWFjaWVqIEtvd2Fsc2tpIHdy b3RlOgoKPiBIaSBFdmVyeWJvZHkuCj4KPiBJJ20gY3VycmVudGx5IHdvcmtpbmcgb24gU0lQL1RE TSBHYXRld2F5IGFwcGxpY2F0aW9uLgo+IEkndmUgZW5jb3VudGVyZWQgZm9sbG93aW5nIHByb2Js ZW0uCj4gRHVyaW5nIFNpcCBkaWFsb2cgYm90aCBzaWRlcyBhdCB0aGUgZXhhY3RseSBzYW1lIG1v bWVudCBzZW5kIFJlLUludml0ZSAKPiByZXF1ZXN0cy4KPiBUaG9zZSBhcmUgcmVhY2hpbmcgdGhl aXIgZGVzdGluYXRpb25zIHdoaWxlIGJvdGggY2xpZW50IGFyZSBleHBlY3RpbmcgCj4gcmVwbGll cy4gV2hhdCBzaG91bGQgYmUgdGhlIGJlaGF2aW9yIG9mIFNJUCBjbGllbnQgaW4gYSBzaXR1YXRp b24gbGlrZSAKPiB0aGF0Lgo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCj4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXAKPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBv ZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wKPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJp YS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcAo+IFVzZSBzaXBwaW5nQGlldGYub3Jn IGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXAKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU2lwIG1haWxpbmcgbGlzdCAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAKVGhpcyBsaXN0IGlzIGZv ciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sClVzZSBzaXAtaW1wbGVt ZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwClVzZSBz aXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBv ZiBzaXA= From sip-bounces@ietf.org Thu Jun 12 06:49:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60663A695E; Thu, 12 Jun 2008 06:49:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A443A6767 for ; Thu, 12 Jun 2008 06:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 0AEDdk4X9uYG for ; Thu, 12 Jun 2008 06:49:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 576003A6818 for ; Thu, 12 Jun 2008 06:49:51 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m5CDoJfU025646 for ; Thu, 12 Jun 2008 08:50:19 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 08:50:19 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 15:50:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 15:50:15 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800202187E@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-03 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgAWxgY1AAU+QSkA== References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 12 Jun 2008 13:50:16.0423 (UTC) FILETIME=[3EB2E770:01C8CC93] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) The document has now been updated based on comments received. http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-03.txt I will give a few more days for responses to the question of support / no support. Please read the draft and indicate your postion. Regards Keith > -----Original Message----- > From: Stuart Hoggan [mailto:s.hoggan@CableLabs.com] > Sent: Tuesday, June 10, 2008 11:01 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > > All, > > We have updated the document to incorporate feedback received so far. > It now contains a section that helps clarify the motivation. > Let us know if you have further comments. > > -Stuart > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 04, 2008 3:48 AM > > To: sip@ietf.org > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > > > (As SIP WG cochair) > > > > This has been raised in the SIP group a couple of times, and we have > not > > yet gained an idea of whether to proceed with it in the SIP > WG or not. > > > > There have been a couple of technical comments raised in > the past from > > the security experts; my understanding is that these have now been > > clarified. > > > > I believe in the past there has been an interested > community that says > > this is useful. It has also been clarified that 3GPP would > like to use > > it in their specifications. > > > > So could I ask the WG to look at this document, and formally to > indicate > > whether they believe some work with this scope should be > progressed as > a > > SIP WG item. > > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > th-02.txt > > > > So if you support it please indicate to the SIP WG chairs. > > > > If you have technical concerns (i.e. it should not proceed > because it > is > > technically flawed beyond fixing) then please ideally mail > the list, > > although the SIP WG chairs will also accept input. > > > > Responses please in 1 calendar week from this date. > > > > Regards > > > > Keith > > > > > > ________________________________ > > > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of > > Stuart Hoggan > > Sent: Friday, May 02, 2008 5:15 PM > > To: sip@ietf.org > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > > > > > > > Folks, > > > > > > > > Based on the feedback received in Philadelphia, we have updated > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the > > Proxy-Authentication-Info header, including support for multiple > values. > > > > > > > > > > Any further comments or suggestions will be > appreciated. It would > > also be nice to obtain WG feedback on pursuing this I-D as a WG > > document. > > > > > > > > Regards, > > > > Stuart > > > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 07:29:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B3B3A6ABF; Thu, 12 Jun 2008 07:29:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10013A6ABF for ; Thu, 12 Jun 2008 07:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 BhWRcnZd7-WV for ; Thu, 12 Jun 2008 07:29:06 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 9E19D3A686D for ; Thu, 12 Jun 2008 07:29:06 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id d1fL1Z0050cQ2SLA306700; Thu, 12 Jun 2008 14:29:34 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id d2VX1Z00302AVH08W2VYAX; Thu, 12 Jun 2008 14:29:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=6_TGXClxP9AA:10 a=SQachpcvphwA:10 a=H0OMuWUdKNwYePGHe_MA:9 a=dWgPBm7zbdPBJiC43WMA:7 a=WjwgAjtIe2x3jTvW-_-0JzFeAioA:4 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5CETUPO009077 for ; Thu, 12 Jun 2008 10:29:30 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5CETU6T009073; Thu, 12 Jun 2008 10:29:30 -0400 Date: Thu, 12 Jun 2008 10:29:30 -0400 Message-Id: <200806121429.m5CETU6T009073@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4850F5E4.30408@o2.pl> (macius_13@o2.pl) References: <4850F5E4.30408@o2.pl> Subject: Re: [Sip] Both sides of dialog sending request at the same time X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Maciej Kowalski I'm currently working on SIP/TDM Gateway application. I've encountered following problem. During Sip dialog both sides at the exactly same moment send Re-Invite requests. Those are reaching their destinations while both client are expecting replies. What should be the behavior of SIP client in a situation like that. Sections 14.1 and 14.2 of RFC 3261 give detailed instructions on how this situation must be handled. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 08:32:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF09A3A6968; Thu, 12 Jun 2008 08:32:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025663A6B02 for ; Thu, 12 Jun 2008 08:32:31 -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 l9el0b61vjGi for ; Thu, 12 Jun 2008 08:32:30 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 110B53A6968 for ; Thu, 12 Jun 2008 08:32:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1213284778!6889471!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 3360 invoked from network); 12 Jun 2008 15:32:58 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-153.messagelabs.com with SMTP; 12 Jun 2008 15:32:58 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m5CFWvwi004488 for ; Thu, 12 Jun 2008 08:32:57 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m5CFWuxf006250 for ; Thu, 12 Jun 2008 10:32:57 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m5CFWs4F006224 for ; Thu, 12 Jun 2008 10:32:55 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 23:32:54 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E60310C099@ZMY16EXM67.ds.mot.com> In-Reply-To: <48511C83.8090808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] PTT query Thread-Index: AcjMi2BEImsvomg7TNe8KpnJ6G+lfAAEj87g References: <37104.78503.qm@web8413.mail.in.yahoo.com> <48511C83.8090808@cisco.com> From: "T Satyanarayana-A12694" To: "Paul Kyzivat" , X-CFilter-Loop: Reflected Cc: sip@ietf.org Subject: Re: [Sip] PTT query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If you are talking about OMA PoC (PTT over Cellular), there is a way defined in OMA standards to do this. It specifies a feature-tag in contact header to identify PoC calls. However, this is outside the purview of SIP. Regards Satya T -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, June 12, 2008 6:24 PM To: shivalk_80@yahoo.co.in Cc: sip@ietf.org Subject: Re: [Sip] PTT query atul garg wrote: > Hello, > > I have a question regarding push to talk message . > > Is there any way through which I can identify that particular SIP message is meant for PTT ie. this sip message is a part of some Push To Talk session.. > > Like through which I can filter that such message is for PTT. > > Such criteria which can be applicable on all SIP messages ie. > > 1) Invite > 2) Register > 3) 2xx/1xx/4xx/3xx etc. responces > .. > .. > etc. Are you talking specifically about the 3gpp IMS form of PTT? Or is your question more general? If you are talking about IMS PTT then you should be asking the IMS community, because their soluitons are very unique to their environment. Beyond that, AFAIK there is no specification for how PTT should work. IMO the concept of PTT is about the characteristics of a media session. I don't see why it has anything to do with REGISTER, etc. aside possibly the communication of capabilities, which can be handled via callerprefs / callee capabilities. Thanks, Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 09:40:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7FE3A686D; Thu, 12 Jun 2008 09:40:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA983A686D for ; Thu, 12 Jun 2008 09:40:10 -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 RZVapzWQgKPM for ; Thu, 12 Jun 2008 09:40:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 91F9C3A6830 for ; Thu, 12 Jun 2008 09:40:09 -0700 (PDT) Received: from [192.168.1.7] (adsl-75-53-54-124.dsl.rcsntx.sbcglobal.net [75.53.54.124]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5CGeape027821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Jun 2008 11:40:38 -0500 Message-Id: From: Dean Willis To: shivalk_80@yahoo.co.in In-Reply-To: <37104.78503.qm@web8413.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 12 Jun 2008 11:40:31 -0500 References: <37104.78503.qm@web8413.mail.in.yahoo.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] PTT query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 12, 2008, at 5:58 AM, atul garg wrote: > Hello, > > I have a question regarding push to talk message . > > Is there any way through which I can identify that particular SIP > message is meant for PTT ie. this sip message is a part of some Push > To Talk session.. > > Like through which I can filter that such message is for PTT. > > Such criteria which can be applicable on all SIP messages ie. > > 1) Invite > 2) Register > 3) 2xx/1xx/4xx/3xx etc. responces I believe that requires reading the PTT specification. There is no IETF PTT specification. You might want to look at OMA's publicly-available specs: http://member.openmobilealliance.org/ftp/Public_documents/POC -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 16:01:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F663A691E; Thu, 12 Jun 2008 16:01:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1031A3A691E for ; Thu, 12 Jun 2008 16:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZKEFpM84JFn for ; Thu, 12 Jun 2008 16:01:44 -0700 (PDT) Received: from bay0-omc3-s4.bay0.hotmail.com (bay0-omc3-s4.bay0.hotmail.com [65.54.246.204]) by core3.amsl.com (Postfix) with ESMTP id 662803A68C6 for ; Thu, 12 Jun 2008 16:01:44 -0700 (PDT) Received: from BAYC1-PASMTP12 ([65.54.191.185]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 16:02:14 -0700 X-Originating-IP: [70.49.138.155] X-Originating-Email: [barcaroller@sympatico.ca] Message-ID: Received: from fgt4t01 ([70.49.138.155]) by BAYC1-PASMTP12.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668); Thu, 12 Jun 2008 16:02:13 -0700 From: To: References: Date: Thu, 12 Jun 2008 19:00:55 -0400 MIME-Version: 1.0 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.5512 X-OriginalArrivalTime: 12 Jun 2008 23:02:13.0680 (UTC) FILETIME=[5A1F4B00:01C8CCE0] Subject: [Sip] Questions regarding SDPs and dialogs... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks to all who answered my request/response question. I have a couple more of SIP questions. -1- I've seen SIP calls where the callee's SDP is transmitted not through the usual 200 OK response but through other responses (like 183 Session Progress). In fact, the callee starts sending/receiving RTP/RTCP streams long before he/she sends out the 200 OK response. Is this legit? -2- Are RTP/RTCP streams associated with dialogs or with sessions? In other words, assuming a SIP session with multiple dialogs, can each dialog have its own (private) set of RTP/RTCP streams? _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 16:10:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F4A3A6B08; Thu, 12 Jun 2008 16:10:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACF33A6AF9 for ; Thu, 12 Jun 2008 16:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 oPCd8vbo4o2W for ; Thu, 12 Jun 2008 16:10:08 -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 E9EB33A68C6 for ; Thu, 12 Jun 2008 16:10:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,631,1204531200"; d="scan'208";a="79278516" Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2008 16:10:38 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id m5CNAbp6006842; Thu, 12 Jun 2008 16:10:37 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5CNAatu022498; Thu, 12 Jun 2008 23:10:36 GMT From: "Dan Wing" To: , References: Date: Thu, 12 Jun 2008 16:10:35 -0700 Message-ID: <011301c8cce1$8548d570$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjM4GRyW2i3jnGRS/C79o2laMRiXAAAPJPw In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1426; t=1213312237; x=1214176237; c=relaxed/simple; s=sjdkim5002; 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[Sip]=20Questions=20regarding=20SDPs=20 and=20dialogs... |Sender:=20; bh=Us9V/L/Q0uKsvHrU1wYfNJj/W7PcaB5MxAKMhUgbDRU=; b=EoQ3A/WsSms0jB+wZ8XxAPteQCMJkm0DehL3sUEJlamDmSI3FxlPeHTfTZ 4ikL7RcrdhiBXuowRUMBOQTSO8abyHq3PQcnfrK8PUZdL5Olr9iI7+fzOoKP UMWIt0ku02; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); Subject: Re: [Sip] Questions regarding SDPs and dialogs... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of barcaroller@sympatico.ca > Sent: Thursday, June 12, 2008 4:01 PM > To: sip@ietf.org > Subject: [Sip] Questions regarding SDPs and dialogs... > > Thanks to all who answered my request/response question. I > have a couple > more of SIP questions. > > -1- > I've seen SIP calls where the callee's SDP is transmitted not > through the > usual 200 OK response but through other responses (like 183 Session > Progress). In fact, the callee starts sending/receiving > RTP/RTCP streams > long before he/she sends out the 200 OK response. Is this legit? Yes, it's called "early media". One of the better discussions of all sorts of cases where this occurs is in http://tools.ietf.org/html/draft-stucker-sipping-early-media-coping-03 (expired). -d > -2- > Are RTP/RTCP streams associated with dialogs or with > sessions? In other > words, assuming a SIP session with multiple dialogs, can each > dialog have > its own (private) set of RTP/RTCP streams? > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 19:54:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F2B3A6A4C; Thu, 12 Jun 2008 19:54:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BE53A6A4C for ; Thu, 12 Jun 2008 19:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 Pp7HEhAVoYuS for ; Thu, 12 Jun 2008 19:54:47 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id D69533A6848 for ; Thu, 12 Jun 2008 19:54:46 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA10.westchester.pa.mail.comcast.net with comcast id dA071Z00D0SCNGk5A0KY00; Fri, 13 Jun 2008 02:55:16 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA09.westchester.pa.mail.comcast.net with comcast id dEv31Z00702AVH03VEv3MJ; Fri, 13 Jun 2008 02:55:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=WPCZQANMUbwA:10 a=-TzPRHrdgPoA:10 a=8Zz9llINaFeX3cMKGg8A:9 a=iKO5nVHPAgXMfznuEVIA:7 a=Z4-_aH_JbTUNBtAGtHoF8PUx_J8A:4 a=b8hG5vVbyAkA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5D2t3PO031050 for ; Thu, 12 Jun 2008 22:55:03 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5D2t0gC031044; Thu, 12 Jun 2008 22:55:00 -0400 Date: Thu, 12 Jun 2008 22:55:00 -0400 Message-Id: <200806130255.m5D2t0gC031044@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (christer.holmberg@ericsson.com) References: Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Here are some comments on this I-D. I don't think that any of them modify our understanding of the proposal. I guess this is very terse; please use these suggestions as you see fit. * Abstract Clarify: This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP entity can use to indicate upstream that an early dialog has been terminated. The response code can be used by a SIP entity (a SIP proxy or UAS), to inform the UAC that an early dialog has been terminated. As the 199 response is a provisional response, often the UAC will receive it before receiving a final response to its request. * Section 1 When a forking proxy receives a non-2xx final response, it does not always immediately forward the response upstream towards the sender of the associated request. Instead, the forking proxy "stores" it and waits for further final responses from remote destinations where the forked request was forwarded. The text does not allow for serial forking, only parallel forking, which might be confusing to people who are more aware of serial forking. So amend the last sentence to: Instead, the forking proxy "stores" it and waits for further final responses from remote destinations where the forked request was forwarded, and possibly forwards the request to additional destinations. Also, Avoid using "..." except when indicating that the word is used in a non-standard way or that one is discussing the word itself: Instead, the forking proxy "stores" it [...] should be: Instead, the forking proxy stores it [...] * Section 3. REQ 1: It must be possible to indicate to the UAC that an early dialog has been terminated before a final response is sent. Oddly, though everyone thinks they understand this sentence, it doesn't really say what we want. To really ensure that the UAC understands the early dialog has been terminated before the UAS sends a final response, the UAS would have to send 199 *and get the PRACK saying that it was received* before sending a final response. This may well be worse than the present state of affairs. What we really mean is: REQ 1: It must be possible for a UAS or proxy to send an indication to the UAC that an early dialog has been terminated, which indication will not be delayed waiting for a final response from any UAS. * Section 4 When a client receives a 199 Early Dialog Terminated provisional response it MAY release resources and procedures associated with the early dialog the 199 response is received on. Amend to clarify the meaning of 199 independently of the consequences of that meaning: When a client receives a 199 Early Dialog Terminated provisional response, it has positive knowledge that the UAS that created the early dialog has terminated it, and so the client MAY release resources and procedures associated with the early dialog for which the 199 response is received. * Section 4 Add this paragraph before the last paragraph: A UAC that receives a 199 response for an early dialog MUST NOT send any further requests on that dialog, except for a PRACK if the 199 response was sent reliably, and PRACKs for other reliable provisional responses that are to be acknowledged. This is copied from section 7 (Backward Compatibility), but since it is a constraint on UACs, it should also be stated in this section. * Section 4 The UAC MAY use additional information (for example the final response which triggered the 199 response) received in the 199 response when initiating new sessions, if it is possible to avoid the new session initiation request to be rejected. What is the meaning of the final clause? * Section 5 Add "early" as marked: When a UAS wants to terminate *an early* dialog it sends a non-2xx SIP final response, as specified in [RFC3261]. In addition, prior to sending the non-2xx SIP final response, the UAS MAY send a 199 response to indicate that the dialog is being terminated. This clarifies that 199 cannot be used to terminate a confirmed dialog. (The reason a UAS may want to send a 199 is to provide this information even when the upstream proxy does not support 199.) There is a subtlty to the second sentence: Sending the 199 *before* the final response is not necessary due to the semantics of 199 (as it will probably reach the UAC first anyway, and it would not matter if it did not), but rather to prevent the upstream proxy from generating a 199 based on the final response, and then to transmit the UAS's 199 immediately after -- if the UAS sends the 199 first, any upstream proxy will (most likely) see the 199 before seeing the final response (which might induce the proxy to send its own 199). * Section 6 When a forking proxy receives a non-2xx final response which terminates one or more early dialogs and the proxy does not intend to forward the final response immediately (due to the rules for a forking proxy) it MUST send a 199 provisional response, for each associated early dialog that it can associate with the final response, upstream towards the sender of the associated request. Clarify, and note that if the proxy has already passed a 199 for an early dialog, it need not generate one itself. Also, I've reduced MUST to SHOULD, because (as the following NOTE explains), the proxy may not know of all early dialogs which are terminated by the final response. [...] it SHOULD initiate a 199 provisional response upstream towards the sender of the associated request, for each terminated early dialog, excepting those for which it has already transmitted a 199 response. Note that the "already transmitted 199 responses" may have come from downstream proxies as well as downstream UASs, so this consideration applies even if we do not allow UASs to send 199s. * Section 7 Since all SIP entities involved in a session setup do not necessarily support the specific meaning of the 199 Early Dialog Terminated provisional response, the sender of the response MUST be prepared to receive SIP requests associated with the dialog for which the 199 response was sent. This situation can also result due to race conditions. Amend to: Because of race conditions and because the client may not support the specific meaning of the 199 provisional response, the sender of the response MUST be prepared to receive SIP requests associated with the dialog for which the 199 response was sent. And add a qualifier to this sentence: If such request is received, and the receiver maintains state of the dialogs, the receiver MUST reply to such requests with a 481 final response (unless another error response is more appropriate). * Section 7 Remove "..." from this sentence and add "even" as marked: The 199 Early Dialog Terminated response code MUST NOT replace a final response. A final response MUST always be sent, *even* after one or many 199 Early Dialog Terminated provisional responses have been sent. * Section 8 Clarify this sentence to: The 199 Early Dialog Terminated response code allows a SIP entity to indicate to upstream entities that a specific early dialog has been terminated, before a final response reaches the upstream entities. Add the following: The early dialog that has been terminated is identified by the Call-Id header and the to-tag value of the 199 response. Future standards may define optional additional information carried in the headers and/or body of the response. * Section 9 A 199 Early Dialog Terminated provisional response MUST NOT contain a new SDP offer/answer message body, but the sender of the response MAY insert a copy of a previously sent offer/answer message body as otherwise allowed by the offer/answer rules for a provisional response. This rule seems excessively strict, as it seems OK to send a new SDP answer in a 199, even if the dialog will be immediately terminated. Certainly, the UAC cannot tell the difference, as there could have been a previous but lost 1xx response carrying the same SDP. The interaction of 199 and SDP probably needs further study... * Section 11 Nit: Use "reject" here rather than "rejects": UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. Here is a modification of the example, showing how a UAS can send a 199, and how the proxy handles it. (You may or may not want to use this.) I've also added the ACK's for the 4xx's, which were missing in the original. [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error response. UAS_3 sends a 199 with its 4xx. When P1 receives the 4xx response from UAS_2 it immediately sends a 199 Early Dialog Terminated associated with UAS_2's dialog towards the UAC. P1 transmits UAS_3's 199, and so does not initiate one itself for UAS_3's dialog when it receives UAS_3's 4xx response. UAC P1 UAS_2 UAS_3 UAS_4 --- INVITE ------> --- INVITE (leg 2) -> --- INVITE (leg 3) ----------> --- INVITE (leg 4) -------------------> <-- 18x (leg 2) ----- <-- 18x (leg 2) -- <-- 18x (leg 3) -------------- <-- 18x (leg 3) -- <-- 18x (leg 4) ----------------------- <-- 18x (leg 4) -- <-- 4xx (leg 2) ----- <-- 199 (leg 2) -- --- ACK (leg 2) ----> <-- 199 (leg 3) -------------- <-- 199 (leg 3) -- <-- 4xx (leg 3) -------------- --- ACK (leg 3) -------------> <-- 200 (leg 4) ----------------------- <-- 200 (leg 4) -- --- ACK (leg 4) -> --- ACK (leg 4) ----------------------> Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 20:05:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814BC3A68C4; Thu, 12 Jun 2008 20:05:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11533A68C4 for ; Thu, 12 Jun 2008 20:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 TtDXgij-RtXX for ; Thu, 12 Jun 2008 20:05:04 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id DEA1F3A6831 for ; Thu, 12 Jun 2008 20:05:03 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with comcast id d6yf1Z00L16LCl0510Mm00; Fri, 13 Jun 2008 03:05:33 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA06.westchester.pa.mail.comcast.net with comcast id dF5W1Z00402AVH03SF5WhA; Fri, 13 Jun 2008 03:05:31 +0000 X-Authority-Analysis: v=1.0 c=1 a=F2aST7H-MCkA:10 a=cyX9bF_4L6kA:10 a=LN_acVB5XRJtNEiYkPMA:9 a=pRG6WO-2lh0AIOCeRnUA:7 a=7B7pwmEcFxRWYcLu1NwkD9cjVxQA:4 a=ZPn7O4N2MpQA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5D35UPO031791 for ; Thu, 12 Jun 2008 23:05:30 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5D35UKr031787; Thu, 12 Jun 2008 23:05:30 -0400 Date: Thu, 12 Jun 2008 23:05:30 -0400 Message-Id: <200806130305.m5D35UKr031787@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1ECE0EB50388174790F9694F77522CCF1715753D@zrc2hxm0.corp.nortel.com> (audet@nortel.com) References: <20080523171502.3779528C27B@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1715753D@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Francois Audet" I really think that this draft should make the inclusion of the original non-2XX final response in the 199 MANDATORY by the forking proxy. This would be in a message/sip body as described in sectin 23.4/RFC 3261. (This is outside the scope of the I-D itself.) If we envision having the 199 carry information from the associated failure response, I suggest we use a message/sipfrag body excerpted from the failure response, rather than copying headers from the failure response into the 199's headers, or copying the entire failure response as the body of the 199. The syntax of sipfrag is unambiguous but extremely flexible (RFC 3420): sipfrag = [ start-line ] *message-header [ CRLF [ message-body ] ] Essentially, it is any subset of the headers of the response, optionally followed by the body. This subsetting capability allows small responses (e.g., omit the Via's, Call-Id, To, From, Record-Route's, etc.), as well as making topology-hiding straightforward. It's also inherently extensible, in that if a proxy/UAS decides to add more headers to the sipfrag, the UAC knows how to identify and/or ignore them. It's also terse, in that carrying any header from the response in a message/sipfrag body is no longer than carrying it as a header of the 199 response. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 20:23:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0604B3A6A4C; Thu, 12 Jun 2008 20:23:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F60F3A6A4C for ; Thu, 12 Jun 2008 20:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwnL667yjlny for ; Thu, 12 Jun 2008 20:23:33 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 590573A6848 for ; Thu, 12 Jun 2008 20:23:33 -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 m5D3Nkc28490; Fri, 13 Jun 2008 03:23:46 GMT Received: from 47.102.170.202 ([47.102.170.202]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 03:23:30 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 20:23:29 -0700 From: "Francois Audet" To: , SIP IETF Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjNBNlX+UnhqIBoSm6MMwTAhcHVJg== In-Reply-To: <200806130305.m5D35UKr031787@dragon.ariadne.com> Mime-version: 1.0 Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org And do you think we should specify what are the minimum headers thatshould be carried? What about MIME bodies? There might be cases where they are really important, no? I'm a little worried that the proxy may remove important information. Especially when we extend SIP. Maybe instead we should list the removable headers (e.g., all the ones that are identical to their counterpart in the 199 itself), and then explain "don't remove what you don't understand"? Opinions? On Jun12 2008 20:05 , "Dale.Worley@comcast.net" wrote: > From: "Francois Audet" > > I really think that this draft should make the inclusion of the original > non-2XX final response in the 199 MANDATORY by the forking proxy. This > would > be in a message/sip body as described in sectin 23.4/RFC 3261. > > (This is outside the scope of the I-D itself.) > > If we envision having the 199 carry information from the associated > failure response, I suggest we use a message/sipfrag body excerpted > from the failure response, rather than copying headers from the > failure response into the 199's headers, or copying the entire failure > response as the body of the 199. > > The syntax of sipfrag is unambiguous but extremely flexible (RFC > 3420): > > sipfrag = [ start-line ] > *message-header > [ CRLF [ message-body ] ] > > Essentially, it is any subset of the headers of the response, > optionally followed by the body. This subsetting capability allows > small responses (e.g., omit the Via's, Call-Id, To, From, > Record-Route's, etc.), as well as making topology-hiding > straightforward. > > It's also inherently extensible, in that if a proxy/UAS decides to add > more headers to the sipfrag, the UAC knows how to identify and/or > ignore them. > > It's also terse, in that carrying any header from the response in a > message/sipfrag body is no longer than carrying it as a header of the > 199 response. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 23:25:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5533A697E; Thu, 12 Jun 2008 23:25:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D453A67A2 for ; Thu, 12 Jun 2008 23:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.136 X-Spam-Level: * X-Spam-Status: No, score=1.136 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTaR1ZXXMFKk for ; Thu, 12 Jun 2008 23:25:05 -0700 (PDT) Received: from poczta.o2.pl (mx12.go2.pl [193.17.41.142]) by core3.amsl.com (Postfix) with ESMTP id DD7563A67C0 for ; Thu, 12 Jun 2008 23:25:03 -0700 (PDT) Received: from poczta.o2.pl (mx12 [127.0.0.1]) by poczta.o2.pl (Postfix) with ESMTP id 5A8AE10400C for ; Fri, 13 Jun 2008 08:25:30 +0200 (CEST) Received: from [192.168.6.244] (unknown [195.117.141.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP for ; Fri, 13 Jun 2008 08:25:30 +0200 (CEST) Message-ID: <485212D9.20902@o2.pl> Date: Fri, 13 Jun 2008 08:25:29 +0200 From: Maciej Kowalski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: sip@ietf.org References: <4850F5E4.30408@o2.pl> In-Reply-To: <4850F5E4.30408@o2.pl> Subject: Re: [Sip] Both sides of dialog sending request at the same time X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thank You for such quick and detailed response. Maciej Maciej Kowalski pisze: > Hi Everybody. > > I'm currently working on SIP/TDM Gateway application. > I've encountered following problem. > During Sip dialog both sides at the exactly same moment send Re-Invite > requests. > Those are reaching their destinations while both client are expecting > replies. What should be the behavior of SIP client in a situation like that. > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 12 23:41:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360953A6AA4; Thu, 12 Jun 2008 23:41:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3233A6A87 for ; Thu, 12 Jun 2008 23:41:54 -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 dKxCLnqu-ifQ for ; Thu, 12 Jun 2008 23:41:53 -0700 (PDT) Received: from dlxapp2.laszlomail.com (dlxapp2.laszlomail.com [168.75.100.14]) by core3.amsl.com (Postfix) with ESMTP id 408493A69DF for ; Thu, 12 Jun 2008 23:41:53 -0700 (PDT) Received: from dlxapp2 (localhost [127.0.0.1]) by dlxapp2.laszlomail.com (8.14.0/8.14.0) with ESMTP id m5D6gMXB000455; Thu, 12 Jun 2008 23:42:23 -0700 Received: from [64.104.169.108] by gowebtop.com with HTTP; Thu, 12 Jun 2008 23:42:18 -0700 Date: Thu, 12 Jun 2008 23:42:18 -0700 (PDT) From: Rockson Zhengyu Li To: KevinKuei Message-ID: <191184266.281861213339342634.JavaMail.lzyiii@localhost> MIME-Version: 1.0 User-Agent: Laszlo Mail 2 X-Originating-IP: [64.104.169.108] Content-Disposition: inline Cc: sip@ietf.org Subject: Re: [Sip] [sip] handling ACK for 2xx response in proxy?? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ACK received from upstream at transport layer would be forwarded to proxy core directly, which would action as per sec 16. sec 18.2.1 Next, the server transport attempts to match the request to a server transaction. It does so using the matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed to that transaction for processing. If no match is found, the request is passed to the core, which may decide to construct a new server transaction for that request. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. Regards, -Rockson On Mon, Oct 29, 2007 at 12:06 PM, KevinKuei wrote: > Hello all, > > In RFC3261 sec.16, is there anywhere talking about stateful proxy > handling ACK?? > Since ACK for 2xx response is not send thru transaction, it should not > be > received by server transaction in proxy. Is that correct?? then.. how > proxy > core got ACK?? > > > -- > Kevin Kuei > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 03:09:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B452F3A6B6A; Fri, 13 Jun 2008 03:09:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079113A6B6A for ; Fri, 13 Jun 2008 03:09: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=[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 Axy3F3v79+GG for ; Fri, 13 Jun 2008 03:09:48 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 848A23A6B69 for ; Fri, 13 Jun 2008 03:09:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1213351819!8983572!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28034 invoked from network); 13 Jun 2008 10:10:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 13 Jun 2008 10:10:19 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m5DAADxf006615 for ; Fri, 13 Jun 2008 03:10:18 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m5DAACDN007200 for ; Fri, 13 Jun 2008 05:10:12 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m5DAAAKa007177 for ; Fri, 13 Jun 2008 05:10:11 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 18:10:07 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B057802C2@ZMY16EXM66.ds.mot.com> In-Reply-To: <37104.78503.qm@web8413.mail.in.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] PTT query Thread-Index: AcjMe1Mva5cDs5N5RzOftK6Y3EzpAwAwjc4A References: <37104.78503.qm@web8413.mail.in.yahoo.com> From: "Avasarala Ranjit-A20990" To: , X-CFilter-Loop: Reflected Subject: Re: [Sip] PTT query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Atul Have a look at the OMA PoC spec http://www.openmobilealliance.org/technical/release_program/docs/PoC/V2_ 0-20080507-C/OMA-TS-PoC_ControlPlane-V2_0-20080507-C.pdf to see what media feature tags are used in SIP Messages for PoC. Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of atul garg Sent: Thursday, June 12, 2008 4:28 PM To: sip@ietf.org Subject: [Sip] PTT query Hello, I have a question regarding push to talk message . Is there any way through which I can identify that particular SIP message is meant for PTT ie. this sip message is a part of some Push To Talk session.. Like through which I can filter that such message is for PTT. Such criteria which can be applicable on all SIP messages ie. 1) Invite 2) Register 3) 2xx/1xx/4xx/3xx etc. responces .. .. etc. Thnx Atul From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 03:37:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABFF53A69F3; Fri, 13 Jun 2008 03:37:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF32F3A6810 for ; Fri, 13 Jun 2008 03:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 XBwCZ2zMIWq8 for ; Fri, 13 Jun 2008 03:37:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CCE103A69F3 for ; Fri, 13 Jun 2008 03:37:13 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 02C9F206D0; Fri, 13 Jun 2008 12:37:44 +0200 (CEST) X-AuditID: c1b4fb3e-ad196bb000004ec0-80-48524df794dc Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CD6A0212B1; Fri, 13 Jun 2008 12:37:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 12:37:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 12:37:51 +0200 Message-ID: In-Reply-To: <200806130255.m5D2t0gC031044@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNAPqDYCE2Ybq+QImT8aaJNWP4SgACBC0g References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> From: "Christer Holmberg" To: , X-OriginalArrivalTime: 13 Jun 2008 10:37:52.0525 (UTC) FILETIME=[88699BD0:01C8CD41] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Dale, >Here are some comments on this I-D. I don't think that any of them modify our understanding of the proposal. I guess >this is very terse; please use these suggestions as you see fit. > >* Abstract > >Clarify: > > This specification defines a new SIP response code, 199 Early > Dialog Terminated, which a SIP entity can use to indicate upstream > that an early dialog has been terminated. The response code can be > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > an early dialog has been terminated. As the 199 response is a > provisional response, often the UAC will receive it before > receiving a final response to its request. [CHH] Ok. >* Section 1 > > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations where > the forked request was forwarded. > >The text does not allow for serial forking, only parallel forking, which might be confusing to people who are more aware >of serial forking. So amend the last sentence to: > > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. [CHH] I can change the text. My intention was not to prevent serial forking. Because, no matter what type of forking it is, the forking proxy will "store" final responses from the different forked legs. >Also, Avoid using "..." except when indicating that the word is used in a non-standard way or that one is discussing the >word itself: > > Instead, the forking proxy "stores" it [...] > >should be: > > Instead, the forking proxy stores it [...] [CHH] Ok. >* Section 3. > > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. > >Oddly, though everyone thinks they understand this sentence, it doesn't really say what we want. To really ensure that >the UAC understands the early dialog has been terminated before the UAS sends a final response, the UAS would have to >send 199 *and get the PRACK saying that it was received* before sending a final response. This may well be worse than >the present state of affairs. > >What we really mean is: > > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. [CHH] I hear what you are saying, but it is a copy of the requirement text we agreed to in SIPPING. >* Section 4 > > When a client receives a 199 Early Dialog Terminated provisional > response it MAY release resources and procedures associated with the > early dialog the 199 response is received on. > >Amend to clarify the meaning of 199 independently of the consequences of that meaning: > > When a client receives a 199 Early Dialog Terminated provisional > response, it has positive knowledge that the UAS that created the > early dialog has terminated it, and so the client MAY release > resources and procedures associated with the early dialog for which > the 199 response is received. [CHH] Ok. >* Section 4 > >Add this paragraph before the last paragraph: > > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. > >This is copied from section 7 (Backward Compatibility), but since it is a constraint on UACs, it should also be stated in >this section. [CHH] Whether the text should be in the document at all depends on if we allow 199 to be sent reliably in the first place. Based on the comments received so far we should not mandate 199 to be sent reliably, even if 100rel is required by the UAC. But, the question if whether we want to FORBID sending it reliably. >* Section 4 > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initiation request to be rejected. > >What is the meaning of the final clause? [CHH] Others have asked the same, so I guess it needs some modification. The meaning is that the information received in the 199 may be used to solve the HERFP problem. It is not in the scope of the document to solve that problem, just to mention that the information may be used for a future mechanism solving it. >* Section 5 > >Add "early" as marked: > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. > >This clarifies that 199 cannot be used to terminate a confirmed dialog. [CHH] I have nothing against your proposal as such, but is this marking method that you are proposing something we normally use in IETF specs? >(The reason a UAS may want to send a 199 is to provide this information even when the upstream proxy does not support >199.) > >There is a subtlty to the second sentence: > >Sending the 199 *before* the final response is not necessary due to the semantics of 199 (as it will probably reach the >UAC first anyway, and it would not matter if it did not), but rather to prevent the upstream proxy from generating a 199 >based on the final response, and then to transmit the UAS's 199 immediately after -- if the UAS sends the 199 first, any >upstream proxy will (most likely) see the 199 before seeing the final response (which might induce the proxy to send its >own 199). [CHH] This depends on whether we should keep the UAS text in the first place, or only describe when proxies send 199. Based on the comments I've received so far, we should not describe UAS behavior for sending 199. >* Section 6 > > When a forking proxy receives a non-2xx final response which > terminates one or more early dialogs and the proxy does not intend to > forward the final response immediately (due to the rules for a > forking proxy) it MUST send a 199 provisional response, for each > associated early dialog that it can associate with the final > response, upstream towards the sender of the associated request. > >Clarify, and note that if the proxy has already passed a 199 for an early dialog, it need not generate one itself. Also, >I've reduced MUST to SHOULD, because (as the following NOTE explains), the proxy may not know of all early dialogs which >are terminated by the final response. > > [...] it SHOULD initiate a 199 provisional response upstream > towards the sender of the associated request, for each terminated > early dialog, excepting those for which it has already transmitted > a 199 response. > >Note that the "already transmitted 199 responses" may have come from downstream proxies as well as downstream UASs, so >this consideration applies even if we do not allow UASs to send 199s. [CHH] I need to think a little more, but it looks ok. >* Section 7 > > Since all SIP entities involved in a session setup do not necessarily > support the specific meaning of the 199 Early Dialog Terminated > provisional response, the sender of the response MUST be prepared to > receive SIP requests associated with the dialog for which the 199 > response was sent. > >This situation can also result due to race conditions. Amend to: > > Because of race conditions and because the client may not support the > specific meaning of the 199 provisional response, the sender of the > response MUST be prepared to receive SIP requests associated with > the dialog for which the 199 response was sent. > >And add a qualifier to this sentence: > > If such request is received, and the receiver maintains state of > the dialogs, the receiver MUST reply to such requests with a 481 > final response (unless another error response is more appropriate). [CHH Ok. >* Section 7 > >Remove "..." from this sentence and add "even" as marked: > > The 199 Early Dialog Terminated response code MUST NOT replace a > final response. A final response MUST always be sent, *even* after > one or many 199 Early Dialog Terminated provisional responses have > been sent. [CHH] Same issue as before regarding the marking method. >* Section 8 > >Clarify this sentence to: > > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. > >Add the following: > > The early dialog that has been terminated is identified by the Call-Id > header and the to-tag value of the 199 response. > > Future standards may define optional additional information carried > in the headers and/or body of the response. [CHH] I am ok with the first sentence, but I don't understand the meaning of the other ("Future standards...") in this context. >* Section 9 > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > >This rule seems excessively strict, as it seems OK to send a new SDP answer in a 199, even if the dialog will be >immediately terminated. >Certainly, the UAC cannot tell the difference, as there could have been a previous but lost 1xx response carrying the >same SDP. > >The interaction of 199 and SDP probably needs further study... [CHH] If we are not going to specify UAS sending of 199 then there will be no SDP in it. I don't think the forking proxy should store received SDPs, and then insert one when triggering the 199. >* Section 11 > >Nit: Use "reject" here rather than "rejects": > > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. [CHH] Ok. >Here is a modification of the example, showing how a UAS can send a 199, and how the proxy handles it. (You may or may >not want to usethis.) I've also added the ACK's for the 4xx's, which were missing in the original. > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > Terminated associated with UAS_2's dialog towards the UAC. P1 > transmits UAS_3's 199, and so does not initiate one itself for > UAS_3's dialog when it receives UAS_3's 4xx response. > > UAC P1 UAS_2 UAS_3 UAS_4 > > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > --- ACK (leg 2) ----> > <-- 199 (leg 3) -------------- > <-- 199 (leg 3) -- > <-- 4xx (leg 3) -------------- > --- ACK (leg 3) -------------> > <-- 200 (leg 4) ----------------------- > <-- 200 (leg 4) -- > --- ACK (leg 4) -> > --- ACK (leg 4) ----------------------> [CHH] I'm ok with your modficiation of the example. Thanks! Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 03:50:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6B13A69BE; Fri, 13 Jun 2008 03:50:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71F63A69BE for ; Fri, 13 Jun 2008 03:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 lCxVbf9iQkk6 for ; Fri, 13 Jun 2008 03:50:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 79F923A6810 for ; Fri, 13 Jun 2008 03:50:31 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5A00720D76; Fri, 13 Jun 2008 12:51:01 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-63-48525115a136 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 348A320471; Fri, 13 Jun 2008 12:51:01 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 12:51:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 12:50:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjNBNlX+UnhqIBoSm6MMwTAhcHVJgACEc7Q References: <200806130305.m5D35UKr031787@dragon.ariadne.com> From: "Christer Holmberg" To: "Francois Audet" , , "SIP IETF" X-OriginalArrivalTime: 13 Jun 2008 10:51:09.0826 (UTC) FILETIME=[63A41620:01C8CD43] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I assume there aren't going to be that many headers in the non-2xx error re= sponse, and I think most will be identical to what will be used in the 199 = anyway - To, From, Call-ID etc. I am ok with also talking about SIP headers, in addition to response code a= nd possible SDP body, but I don't think we should make this too complex. And, to answer Dale, the intention IS to use sipfrag - no matter how much/l= ittle information of the final response we include in the 199. Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Franc= ois Audet Sent: 13. kes=E4kuuta 2008 6:23 To: Dale.Worley@comcast.net; SIP IETF Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt And do you think we should specify what are the minimum headers thatshould = be carried? What about MIME bodies? There might be cases where they are really important, no? I'm a little worried that the proxy may remove important information. Especially when we extend SIP. Maybe instead we should list the removable headers (e.g., all the ones that= are identical to their counterpart in the 199 itself), and then explain "d= on't remove what you don't understand"? Opinions? On Jun12 2008 20:05 , "Dale.Worley@comcast.net" wrote: > From: "Francois Audet" > = > I really think that this draft should make the inclusion of the origin= al > non-2XX final response in the 199 MANDATORY by the forking proxy. = > This would > be in a message/sip body as described in sectin 23.4/RFC 3261. > = > (This is outside the scope of the I-D itself.) > = > If we envision having the 199 carry information from the associated = > failure response, I suggest we use a message/sipfrag body excerpted = > from the failure response, rather than copying headers from the = > failure response into the 199's headers, or copying the entire failure = > response as the body of the 199. > = > The syntax of sipfrag is unambiguous but extremely flexible (RFC > 3420): > = > sipfrag =3D [ start-line ] > *message-header > [ CRLF [ message-body ] ] > = > Essentially, it is any subset of the headers of the response, = > optionally followed by the body. This subsetting capability allows = > small responses (e.g., omit the Via's, Call-Id, To, From, = > Record-Route's, etc.), as well as making topology-hiding = > straightforward. > = > It's also inherently extensible, in that if a proxy/UAS decides to add = > more headers to the sipfrag, the UAC knows how to identify and/or = > ignore them. > = > It's also terse, in that carrying any header from the response in a = > message/sipfrag body is no longer than carrying it as a header of the > 199 response. > = > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 07:06:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053123A690F; Fri, 13 Jun 2008 07:06:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EE83A68AE for ; Fri, 13 Jun 2008 07:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 eu0im0hZfPCk for ; Fri, 13 Jun 2008 07:06:08 -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 5573F3A690F for ; Fri, 13 Jun 2008 07:06:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,638,1204520400"; d="scan'208";a="10949921" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2008 10:06:39 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5DE6dji006124; Fri, 13 Jun 2008 10:06:39 -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.13.8) with ESMTP id m5DE6dT2025212; Fri, 13 Jun 2008 14:06:39 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 10:06:39 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 10:06:38 -0400 Message-ID: <48527F1A.90302@cisco.com> Date: Fri, 13 Jun 2008 10:07:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> In-Reply-To: <200806130255.m5D2t0gC031044@dragon.ariadne.com> X-OriginalArrivalTime: 13 Jun 2008 14:06:38.0766 (UTC) FILETIME=[B2A24CE0:01C8CD5E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12343; t=1213365999; x=1214229999; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=LHaXCb3Y6J+jBpTa6pyqWgH0NJa8BbYsfG0CyV2dTj0=; b=DCCINDbaNJ5EDQG+20P0LLnDzAPOaD/Vy2aNsRf0Hx5R6xlwuk6ZwpIpYM clAT+9H6TvOw+gaN0qlRafUdNa/MJdghSmh5nwV+an8gOKIrPbAnSGZnBS9R rkBo9yc2Mj; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This all sounds like good stuff. However I am still scratching my head about the UAS sending a 199. While I see no reason to forbid it I'm trying to find a situation when it would be helpful. The only case I have been able to think of is: There is a forking proxy upstream of the UAS, but it doesn't support 199. Yet it may delay the final response while it tries other forks. So the UAS sending the 199 makes up for the inadequacy of the forking proxy. The trouble with this is that it is inefficient in many cases. If each proxy that forks also supports the sending of 199, and the UAS doesn't send one, then we avoid sending the message except in cases where it is helpful. If the UAS always sends it we have increased the message count by one for all failing calls. And the majority of failing calls get no benefit from a 199. This is one of those cases that could probably benefit from simulation to judge the merits. My gut feel is that the costs of the UAS sending the 199 outweigh the benefits. Barring some analysis to the contrary I think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, but without any guidance of when. Paul Dale.Worley@comcast.net wrote: > Here are some comments on this I-D. I don't think that any of them > modify our understanding of the proposal. I guess this is very terse; > please use these suggestions as you see fit. > > * Abstract > > Clarify: > > This specification defines a new SIP response code, 199 Early > Dialog Terminated, which a SIP entity can use to indicate upstream > that an early dialog has been terminated. The response code can be > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > an early dialog has been terminated. As the 199 response is a > provisional response, often the UAC will receive it before > receiving a final response to its request. > > * Section 1 > > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations where > the forked request was forwarded. > > The text does not allow for serial forking, only parallel forking, > which might be confusing to people who are more aware of serial > forking. So amend the last sentence to: > > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. > > Also, Avoid using "..." except when indicating that the word is used > in a non-standard way or that one is discussing the word itself: > > Instead, the forking proxy "stores" it [...] > > should be: > > Instead, the forking proxy stores it [...] > > * Section 3. > > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. > > Oddly, though everyone thinks they understand this sentence, it > doesn't really say what we want. To really ensure that the UAC > understands the early dialog has been terminated before the UAS sends > a final response, the UAS would have to send 199 *and get the PRACK > saying that it was received* before sending a final response. This may > well be worse than the present state of affairs. > > What we really mean is: > > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. > > * Section 4 > > When a client receives a 199 Early Dialog Terminated provisional > response it MAY release resources and procedures associated with the > early dialog the 199 response is received on. > > Amend to clarify the meaning of 199 independently of the consequences > of that meaning: > > When a client receives a 199 Early Dialog Terminated provisional > response, it has positive knowledge that the UAS that created the > early dialog has terminated it, and so the client MAY release > resources and procedures associated with the early dialog for which > the 199 response is received. > > * Section 4 > > Add this paragraph before the last paragraph: > > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. > > This is copied from section 7 (Backward Compatibility), but since it > is a constraint on UACs, it should also be stated in this section. > > * Section 4 > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initiation request to be rejected. > > What is the meaning of the final clause? > > * Section 5 > > Add "early" as marked: > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. > > This clarifies that 199 cannot be used to terminate a confirmed > dialog. > > (The reason a UAS may want to send a 199 is to provide this > information even when the upstream proxy does not support 199.) > > There is a subtlty to the second sentence: > > Sending the 199 *before* the final response is not necessary due to > the semantics of 199 (as it will probably reach the UAC first anyway, > and it would not matter if it did not), but rather to prevent the > upstream proxy from generating a 199 based on the final response, and > then to transmit the UAS's 199 immediately after -- if the UAS sends > the 199 first, any upstream proxy will (most likely) see the 199 > before seeing the final response (which might induce the proxy to send > its own 199). > > * Section 6 > > When a forking proxy receives a non-2xx final response which > terminates one or more early dialogs and the proxy does not intend to > forward the final response immediately (due to the rules for a > forking proxy) it MUST send a 199 provisional response, for each > associated early dialog that it can associate with the final > response, upstream towards the sender of the associated request. > > Clarify, and note that if the proxy has already passed a 199 for an > early dialog, it need not generate one itself. Also, I've reduced > MUST to SHOULD, because (as the following NOTE explains), the proxy > may not know of all early dialogs which are terminated by the final > response. > > [...] it SHOULD initiate a 199 provisional response upstream > towards the sender of the associated request, for each terminated > early dialog, excepting those for which it has already transmitted > a 199 response. > > Note that the "already transmitted 199 responses" may have come from > downstream proxies as well as downstream UASs, so this consideration > applies even if we do not allow UASs to send 199s. > > * Section 7 > > Since all SIP entities involved in a session setup do not necessarily > support the specific meaning of the 199 Early Dialog Terminated > provisional response, the sender of the response MUST be prepared to > receive SIP requests associated with the dialog for which the 199 > response was sent. > > This situation can also result due to race conditions. Amend to: > > Because of race conditions and because the client may not support the > specific meaning of the 199 provisional response, the sender of the > response MUST be prepared to receive SIP requests associated with > the dialog for which the 199 response was sent. > > And add a qualifier to this sentence: > > If such request is received, and the receiver maintains state of > the dialogs, the receiver MUST reply to such requests with a 481 > final response (unless another error response is more appropriate). > > * Section 7 > > Remove "..." from this sentence and add "even" as marked: > > The 199 Early Dialog Terminated response code MUST NOT replace a > final response. A final response MUST always be sent, *even* after > one or many 199 Early Dialog Terminated provisional responses have > been sent. > > * Section 8 > > Clarify this sentence to: > > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. > > Add the following: > > The early dialog that has been terminated is identified by the Call-Id > header and the to-tag value of the 199 response. > > Future standards may define optional additional information carried > in the headers and/or body of the response. > > * Section 9 > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > > This rule seems excessively strict, as it seems OK to send a new SDP > answer in a 199, even if the dialog will be immediately terminated. > Certainly, the UAC cannot tell the difference, as there could have > been a previous but lost 1xx response carrying the same SDP. > > The interaction of 199 and SDP probably needs further study... > > * Section 11 > > Nit: Use "reject" here rather than "rejects": > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. > > Here is a modification of the example, showing how a UAS can send a > 199, and how the proxy handles it. (You may or may not want to use > this.) I've also added the ACK's for the 4xx's, which were missing in > the original. > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > Terminated associated with UAS_2's dialog towards the UAC. P1 > transmits UAS_3's 199, and so does not initiate one itself for > UAS_3's dialog when it receives UAS_3's 4xx response. > > UAC P1 UAS_2 UAS_3 UAS_4 > > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > --- ACK (leg 2) ----> > <-- 199 (leg 3) -------------- > <-- 199 (leg 3) -- > <-- 4xx (leg 3) -------------- > --- ACK (leg 3) -------------> > <-- 200 (leg 4) ----------------------- > <-- 200 (leg 4) -- > --- ACK (leg 4) -> > --- ACK (leg 4) ----------------------> > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 07:38:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010D13A6817; Fri, 13 Jun 2008 07:38:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEB53A6804 for ; Fri, 13 Jun 2008 07:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 eJfr6PqZhVse for ; Fri, 13 Jun 2008 07:38:29 -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 BD1D73A6817 for ; Fri, 13 Jun 2008 07:38:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,638,1204531200"; d="scan'208";a="41122295" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2008 07:39:01 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5DEd0GR019996; Fri, 13 Jun 2008 10:39:00 -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.13.8) with ESMTP id m5DEcxLU006798; Fri, 13 Jun 2008 14:39:00 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.1830); Fri, 13 Jun 2008 10:38:47 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 10:38:47 -0400 Message-ID: <485286A3.5010401@cisco.com> Date: Fri, 13 Jun 2008 10:39:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francois Audet References: In-Reply-To: X-OriginalArrivalTime: 13 Jun 2008 14:38:47.0454 (UTC) FILETIME=[3038BBE0:01C8CD63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3879; t=1213367940; x=1214231940; 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[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-1 99-00.txt |Sender:=20 |To:=20Francois=20Audet=20; bh=vIxYIwNvzF1is2WhCE7/q2eLsWRenWkUJd9ZY3apYgg=; b=E0frNwN5w/CYjI7b/2KY5pHMsqeR16XcTD/l6V1tUEJGcq4jXYKixBpSCf L9mNVyslLvzRl581gweW9rYG8yRf44UvA+ltfZltaT4XS9Vbe0pNxH3LI0AU uJwX0ukESk; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My first thought was to agree with Dale, and in fact I already suggested use of sipfrag. But I already have experience from the refer NOTIFY that sipfrag info is difficult to take advantage of if you have no guarantee of what will be included. IIRC this 199 work was explicitly not expected to solve the full HERFP problem. Yet if it could serve for that it would be a good thing. Its just that thrashing out everything that is needed will take a bunch of time. Also, sending back the whole message will make more data to send in cases where it often isn't useful. We could allow a body containing *either* message/sip or message/sipfrag, and make them both conditional on presence of a corresponding Accept header in the request. If there was no Accept header for either then no body would be included. If there was an accept for both, message/sip would be be preferred. When a sipfrag is returned in a 199, we could require that it include at least the header line, and the rest would be at the discretion of the proxy. Paul Francois Audet wrote: > And do you think we should specify what are the minimum headers thatshould > be carried? > > What about MIME bodies? > > There might be cases where they are really important, no? > > I'm a little worried that the proxy may remove important information. > Especially when we extend SIP. > > Maybe instead we should list the removable headers (e.g., all the ones that > are identical to their counterpart in the 199 itself), and then explain > "don't remove what you don't understand"? > > Opinions? > > > On Jun12 2008 20:05 , "Dale.Worley@comcast.net" > wrote: > >> From: "Francois Audet" >> >> I really think that this draft should make the inclusion of the original >> non-2XX final response in the 199 MANDATORY by the forking proxy. This >> would >> be in a message/sip body as described in sectin 23.4/RFC 3261. >> >> (This is outside the scope of the I-D itself.) >> >> If we envision having the 199 carry information from the associated >> failure response, I suggest we use a message/sipfrag body excerpted >> from the failure response, rather than copying headers from the >> failure response into the 199's headers, or copying the entire failure >> response as the body of the 199. >> >> The syntax of sipfrag is unambiguous but extremely flexible (RFC >> 3420): >> >> sipfrag = [ start-line ] >> *message-header >> [ CRLF [ message-body ] ] >> >> Essentially, it is any subset of the headers of the response, >> optionally followed by the body. This subsetting capability allows >> small responses (e.g., omit the Via's, Call-Id, To, From, >> Record-Route's, etc.), as well as making topology-hiding >> straightforward. >> >> It's also inherently extensible, in that if a proxy/UAS decides to add >> more headers to the sipfrag, the UAC knows how to identify and/or >> ignore them. >> >> It's also terse, in that carrying any header from the response in a >> message/sipfrag body is no longer than carrying it as a header of the >> 199 response. >> >> Dale >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 10:14:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A643A6984; Fri, 13 Jun 2008 10:14:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36C73A698D for ; Fri, 13 Jun 2008 10:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 jzXdwhbw1l3P for ; Fri, 13 Jun 2008 10:14:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 19CB73A6984 for ; Fri, 13 Jun 2008 10:14:52 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5DHFLDl002115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jun 2008 12:15:22 -0500 Message-ID: <4852AB19.2020606@softarmor.com> Date: Fri, 13 Jun 2008 12:15:05 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Kyzivat , sip@ietf.org References: <485286A3.5010401@cisco.com> In-Reply-To: <485286A3.5010401@cisco.com> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Also, sending back the whole message will make more data to send in > cases where it often isn't useful. It is also likely to break UDP. See the problems we had with diagnostic responses in general. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 10:43:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF913A693B; Fri, 13 Jun 2008 10:43:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA983A68CE for ; Fri, 13 Jun 2008 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 1QnJ5IEYUBIf for ; Fri, 13 Jun 2008 10:43:05 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 913E13A693B for ; Fri, 13 Jun 2008 10:43:05 -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 m5DHhNE03792; Fri, 13 Jun 2008 17:43:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 12:43:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> In-Reply-To: <48527F1A.90302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNXtWuuKxHlQ7eQAy8ounJpYGq4gAHgYIA References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I can think of one scenario... If the UAS in question is actually some sort of B2BUA. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, June 13, 2008 07:07 > To: Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > This all sounds like good stuff. > > However I am still scratching my head about the UAS sending a > 199. While I see no reason to forbid it I'm trying to find a > situation when it would be helpful. The only case I have been > able to think of is: > > There is a forking proxy upstream of the UAS, but it doesn't > support 199. Yet it may delay the final response while it > tries other forks. So the UAS sending the 199 makes up for > the inadequacy of the forking proxy. > > The trouble with this is that it is inefficient in many > cases. If each proxy that forks also supports the sending of > 199, and the UAS doesn't send one, then we avoid sending the > message except in cases where it is helpful. If the UAS > always sends it we have increased the message count by one > for all failing calls. And the majority of failing calls get > no benefit from a 199. > > This is one of those cases that could probably benefit from > simulation to judge the merits. My gut feel is that the costs > of the UAS sending the 199 outweigh the benefits. Barring > some analysis to the contrary I think I would say that a UAS > SHOULD NOT send a 199. Or perhaps MAY send, but without any > guidance of when. > > Paul > > Dale.Worley@comcast.net wrote: > > Here are some comments on this I-D. I don't think that any of them > > modify our understanding of the proposal. I guess this is > very terse; > > please use these suggestions as you see fit. > > > > * Abstract > > > > Clarify: > > > > This specification defines a new SIP response code, 199 Early > > Dialog Terminated, which a SIP entity can use to > indicate upstream > > that an early dialog has been terminated. The response > code can be > > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > > an early dialog has been terminated. As the 199 response is a > > provisional response, often the UAC will receive it before > > receiving a final response to its request. > > > > * Section 1 > > > > When a forking proxy receives a non-2xx final response, > it does not > > always immediately forward the response upstream towards > the sender > > of the associated request. Instead, the forking proxy > "stores" it > > and waits for further final responses from remote > destinations where > > the forked request was forwarded. > > > > The text does not allow for serial forking, only parallel forking, > > which might be confusing to people who are more aware of serial > > forking. So amend the last sentence to: > > > > Instead, the forking proxy "stores" it and waits for > further final > > responses from remote destinations where the forked request was > > forwarded, and possibly forwards the request to additional > > destinations. > > > > Also, Avoid using "..." except when indicating that the > word is used > > in a non-standard way or that one is discussing the word itself: > > > > Instead, the forking proxy "stores" it [...] > > > > should be: > > > > Instead, the forking proxy stores it [...] > > > > * Section 3. > > > > REQ 1: It must be possible to indicate to the UAC that an early > > dialog has been terminated before a final response is sent. > > > > Oddly, though everyone thinks they understand this sentence, it > > doesn't really say what we want. To really ensure that the UAC > > understands the early dialog has been terminated before the > UAS sends > > a final response, the UAS would have to send 199 *and get the PRACK > > saying that it was received* before sending a final response. This > > may well be worse than the present state of affairs. > > > > What we really mean is: > > > > REQ 1: It must be possible for a UAS or proxy to send an > indication > > to the UAC that an early dialog has been terminated, which > > indication will not be delayed waiting for a final response from > > any UAS. > > > > * Section 4 > > > > When a client receives a 199 Early Dialog Terminated provisional > > response it MAY release resources and procedures > associated with the > > early dialog the 199 response is received on. > > > > Amend to clarify the meaning of 199 independently of the > consequences > > of that meaning: > > > > When a client receives a 199 Early Dialog Terminated provisional > > response, it has positive knowledge that the UAS that created the > > early dialog has terminated it, and so the client MAY release > > resources and procedures associated with the early > dialog for which > > the 199 response is received. > > > > * Section 4 > > > > Add this paragraph before the last paragraph: > > > > A UAC that receives a 199 response for an early dialog MUST NOT > > send any further requests on that dialog, except for a > PRACK if the > > 199 response was sent reliably, and PRACKs for other reliable > > provisional responses that are to be acknowledged. > > > > This is copied from section 7 (Backward Compatibility), but > since it > > is a constraint on UACs, it should also be stated in this section. > > > > * Section 4 > > > > The UAC MAY use additional information (for example the final > > response which triggered the 199 response) received in the 199 > > response when initiating new sessions, if it is possible > to avoid the > > new session initiation request to be rejected. > > > > What is the meaning of the final clause? > > > > * Section 5 > > > > Add "early" as marked: > > > > When a UAS wants to terminate *an early* dialog it sends > a non-2xx > > SIP final response, as specified in [RFC3261]. In > addition, prior > > to sending the non-2xx SIP final response, the UAS MAY send a 199 > > response to indicate that the dialog is being terminated. > > > > This clarifies that 199 cannot be used to terminate a confirmed > > dialog. > > > > (The reason a UAS may want to send a 199 is to provide this > > information even when the upstream proxy does not support 199.) > > > > There is a subtlty to the second sentence: > > > > Sending the 199 *before* the final response is not necessary due to > > the semantics of 199 (as it will probably reach the UAC > first anyway, > > and it would not matter if it did not), but rather to prevent the > > upstream proxy from generating a 199 based on the final > response, and > > then to transmit the UAS's 199 immediately after -- if the > UAS sends > > the 199 first, any upstream proxy will (most likely) see the 199 > > before seeing the final response (which might induce the > proxy to send > > its own 199). > > > > * Section 6 > > > > When a forking proxy receives a non-2xx final response which > > terminates one or more early dialogs and the proxy does > not intend to > > forward the final response immediately (due to the rules for a > > forking proxy) it MUST send a 199 provisional response, for each > > associated early dialog that it can associate with the final > > response, upstream towards the sender of the associated request. > > > > Clarify, and note that if the proxy has already passed a 199 for an > > early dialog, it need not generate one itself. Also, I've reduced > > MUST to SHOULD, because (as the following NOTE explains), the proxy > > may not know of all early dialogs which are terminated by the final > > response. > > > > [...] it SHOULD initiate a 199 provisional response upstream > > towards the sender of the associated request, for each terminated > > early dialog, excepting those for which it has already > transmitted > > a 199 response. > > > > Note that the "already transmitted 199 responses" may have > come from > > downstream proxies as well as downstream UASs, so this > consideration > > applies even if we do not allow UASs to send 199s. > > > > * Section 7 > > > > Since all SIP entities involved in a session setup do > not necessarily > > support the specific meaning of the 199 Early Dialog Terminated > > provisional response, the sender of the response MUST be > prepared to > > receive SIP requests associated with the dialog for which the 199 > > response was sent. > > > > This situation can also result due to race conditions. Amend to: > > > > Because of race conditions and because the client may > not support the > > specific meaning of the 199 provisional response, the > sender of the > > response MUST be prepared to receive SIP requests associated with > > the dialog for which the 199 response was sent. > > > > And add a qualifier to this sentence: > > > > If such request is received, and the receiver maintains state of > > the dialogs, the receiver MUST reply to such requests with a 481 > > final response (unless another error response is more > appropriate). > > > > * Section 7 > > > > Remove "..." from this sentence and add "even" as marked: > > > > The 199 Early Dialog Terminated response code MUST NOT replace a > > final response. A final response MUST always be sent, > *even* after > > one or many 199 Early Dialog Terminated provisional > responses have > > been sent. > > > > * Section 8 > > > > Clarify this sentence to: > > > > The 199 Early Dialog Terminated response code allows a SIP entity > > to indicate to upstream entities that a specific early dialog has > > been terminated, before a final response reaches the upstream > > entities. > > > > Add the following: > > > > The early dialog that has been terminated is identified > by the Call-Id > > header and the to-tag value of the 199 response. > > > > Future standards may define optional additional > information carried > > in the headers and/or body of the response. > > > > * Section 9 > > > > A 199 Early Dialog Terminated provisional response MUST > NOT contain a > > new SDP offer/answer message body, but the sender of the > response MAY > > insert a copy of a previously sent offer/answer message body as > > otherwise allowed by the offer/answer rules for a provisional > > response. > > > > This rule seems excessively strict, as it seems OK to send > a new SDP > > answer in a 199, even if the dialog will be immediately terminated. > > Certainly, the UAC cannot tell the difference, as there could have > > been a previous but lost 1xx response carrying the same SDP. > > > > The interaction of 199 and SDP probably needs further study... > > > > * Section 11 > > > > Nit: Use "reject" here rather than "rejects": > > > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx > error response. > > > > Here is a modification of the example, showing how a UAS can send a > > 199, and how the proxy handles it. (You may or may not want to use > > this.) I've also added the ACK's for the 4xx's, which were > missing in > > the original. > > > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > > Terminated associated with UAS_2's dialog towards the UAC. P1 > > transmits UAS_3's 199, and so does not initiate one itself for > > UAS_3's dialog when it receives UAS_3's 4xx response. > > > > UAC P1 UAS_2 UAS_3 UAS_4 > > > > --- INVITE ------> > > --- INVITE (leg 2) -> > > --- INVITE (leg 3) ----------> > > --- INVITE (leg 4) -------------------> > > <-- 18x (leg 2) ----- > > <-- 18x (leg 2) -- > > <-- 18x (leg 3) -------------- > > <-- 18x (leg 3) -- > > <-- 18x (leg 4) ----------------------- > > <-- 18x (leg 4) -- > > <-- 4xx (leg 2) ----- > > <-- 199 (leg 2) -- > > --- ACK (leg 2) ----> > > <-- 199 (leg 3) -------------- > > <-- 199 (leg 3) -- > > <-- 4xx (leg 3) -------------- > > --- ACK (leg 3) -------------> > > <-- 200 (leg 4) ----------------------- > > <-- 200 (leg 4) -- > > --- ACK (leg 4) -> > > --- ACK (leg 4) ----------------------> > > > > Dale > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 12:09:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799F03A68FA; Fri, 13 Jun 2008 12:09:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0FC3A6890 for ; Fri, 13 Jun 2008 12:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 R35EpdUcEy2m for ; Fri, 13 Jun 2008 12:09:21 -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 E60A23A6804 for ; Fri, 13 Jun 2008 12:09:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,640,1204520400"; d="scan'208";a="10977370" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2008 15:09:53 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5DJ9rZo018555; Fri, 13 Jun 2008 15:09:53 -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.13.8) with ESMTP id m5DJ9qlI019545; Fri, 13 Jun 2008 19:09:52 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.1830); Fri, 13 Jun 2008 15:09:52 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 15:09:52 -0400 Message-ID: <4852C62F.4030007@cisco.com> Date: Fri, 13 Jun 2008 15:10:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francois Audet References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 13 Jun 2008 19:09:52.0405 (UTC) FILETIME=[0EE34C50:01C8CD89] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14056; t=1213384193; x=1214248193; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Francois=20Audet=20; bh=qBMlSBjkJ5c2paOwbHEsnrM//dzABuWCEER6NA0jLmA=; b=Wj/J5WHKww1bHL8sF9eQMBaLVF2oeEMnaUTMsVCFcKgpRQHJElHTHlHdAo 1M6o8ENXZdYsnIg5AUNtLDRY47gigB7FW9mQgfl02o78ln5Lry9++wwT6L1G EL1bU/IdOS; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I can think of one scenario... > > If the UAS in question is actually some sort of B2BUA. OK. That is a good one. That is certainly a reason not to forbid it. And in that case we would expect the B2BUA to follow the rules for proxies about handling and generating 199. Thanks, Paul >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Friday, June 13, 2008 07:07 >> To: Dale.Worley@comcast.net >> Cc: sip@ietf.org >> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >> >> This all sounds like good stuff. >> >> However I am still scratching my head about the UAS sending a >> 199. While I see no reason to forbid it I'm trying to find a >> situation when it would be helpful. The only case I have been >> able to think of is: >> >> There is a forking proxy upstream of the UAS, but it doesn't >> support 199. Yet it may delay the final response while it >> tries other forks. So the UAS sending the 199 makes up for >> the inadequacy of the forking proxy. >> >> The trouble with this is that it is inefficient in many >> cases. If each proxy that forks also supports the sending of >> 199, and the UAS doesn't send one, then we avoid sending the >> message except in cases where it is helpful. If the UAS >> always sends it we have increased the message count by one >> for all failing calls. And the majority of failing calls get >> no benefit from a 199. >> >> This is one of those cases that could probably benefit from >> simulation to judge the merits. My gut feel is that the costs >> of the UAS sending the 199 outweigh the benefits. Barring >> some analysis to the contrary I think I would say that a UAS >> SHOULD NOT send a 199. Or perhaps MAY send, but without any >> guidance of when. >> >> Paul >> >> Dale.Worley@comcast.net wrote: >>> Here are some comments on this I-D. I don't think that any of them >>> modify our understanding of the proposal. I guess this is >> very terse; >>> please use these suggestions as you see fit. >>> >>> * Abstract >>> >>> Clarify: >>> >>> This specification defines a new SIP response code, 199 Early >>> Dialog Terminated, which a SIP entity can use to >> indicate upstream >>> that an early dialog has been terminated. The response >> code can be >>> used by a SIP entity (a SIP proxy or UAS), to inform the UAC that >>> an early dialog has been terminated. As the 199 response is a >>> provisional response, often the UAC will receive it before >>> receiving a final response to its request. >>> >>> * Section 1 >>> >>> When a forking proxy receives a non-2xx final response, >> it does not >>> always immediately forward the response upstream towards >> the sender >>> of the associated request. Instead, the forking proxy >> "stores" it >>> and waits for further final responses from remote >> destinations where >>> the forked request was forwarded. >>> >>> The text does not allow for serial forking, only parallel forking, >>> which might be confusing to people who are more aware of serial >>> forking. So amend the last sentence to: >>> >>> Instead, the forking proxy "stores" it and waits for >> further final >>> responses from remote destinations where the forked request was >>> forwarded, and possibly forwards the request to additional >>> destinations. >>> >>> Also, Avoid using "..." except when indicating that the >> word is used >>> in a non-standard way or that one is discussing the word itself: >>> >>> Instead, the forking proxy "stores" it [...] >>> >>> should be: >>> >>> Instead, the forking proxy stores it [...] >>> >>> * Section 3. >>> >>> REQ 1: It must be possible to indicate to the UAC that an early >>> dialog has been terminated before a final response is sent. >>> >>> Oddly, though everyone thinks they understand this sentence, it >>> doesn't really say what we want. To really ensure that the UAC >>> understands the early dialog has been terminated before the >> UAS sends >>> a final response, the UAS would have to send 199 *and get the PRACK >>> saying that it was received* before sending a final response. This >>> may well be worse than the present state of affairs. >>> >>> What we really mean is: >>> >>> REQ 1: It must be possible for a UAS or proxy to send an >> indication >>> to the UAC that an early dialog has been terminated, which >>> indication will not be delayed waiting for a final response from >>> any UAS. >>> >>> * Section 4 >>> >>> When a client receives a 199 Early Dialog Terminated provisional >>> response it MAY release resources and procedures >> associated with the >>> early dialog the 199 response is received on. >>> >>> Amend to clarify the meaning of 199 independently of the >> consequences >>> of that meaning: >>> >>> When a client receives a 199 Early Dialog Terminated provisional >>> response, it has positive knowledge that the UAS that created the >>> early dialog has terminated it, and so the client MAY release >>> resources and procedures associated with the early >> dialog for which >>> the 199 response is received. >>> >>> * Section 4 >>> >>> Add this paragraph before the last paragraph: >>> >>> A UAC that receives a 199 response for an early dialog MUST NOT >>> send any further requests on that dialog, except for a >> PRACK if the >>> 199 response was sent reliably, and PRACKs for other reliable >>> provisional responses that are to be acknowledged. >>> >>> This is copied from section 7 (Backward Compatibility), but >> since it >>> is a constraint on UACs, it should also be stated in this section. >>> >>> * Section 4 >>> >>> The UAC MAY use additional information (for example the final >>> response which triggered the 199 response) received in the 199 >>> response when initiating new sessions, if it is possible >> to avoid the >>> new session initiation request to be rejected. >>> >>> What is the meaning of the final clause? >>> >>> * Section 5 >>> >>> Add "early" as marked: >>> >>> When a UAS wants to terminate *an early* dialog it sends >> a non-2xx >>> SIP final response, as specified in [RFC3261]. In >> addition, prior >>> to sending the non-2xx SIP final response, the UAS MAY send a 199 >>> response to indicate that the dialog is being terminated. >>> >>> This clarifies that 199 cannot be used to terminate a confirmed >>> dialog. >>> >>> (The reason a UAS may want to send a 199 is to provide this >>> information even when the upstream proxy does not support 199.) >>> >>> There is a subtlty to the second sentence: >>> >>> Sending the 199 *before* the final response is not necessary due to >>> the semantics of 199 (as it will probably reach the UAC >> first anyway, >>> and it would not matter if it did not), but rather to prevent the >>> upstream proxy from generating a 199 based on the final >> response, and >>> then to transmit the UAS's 199 immediately after -- if the >> UAS sends >>> the 199 first, any upstream proxy will (most likely) see the 199 >>> before seeing the final response (which might induce the >> proxy to send >>> its own 199). >>> >>> * Section 6 >>> >>> When a forking proxy receives a non-2xx final response which >>> terminates one or more early dialogs and the proxy does >> not intend to >>> forward the final response immediately (due to the rules for a >>> forking proxy) it MUST send a 199 provisional response, for each >>> associated early dialog that it can associate with the final >>> response, upstream towards the sender of the associated request. >>> >>> Clarify, and note that if the proxy has already passed a 199 for an >>> early dialog, it need not generate one itself. Also, I've reduced >>> MUST to SHOULD, because (as the following NOTE explains), the proxy >>> may not know of all early dialogs which are terminated by the final >>> response. >>> >>> [...] it SHOULD initiate a 199 provisional response upstream >>> towards the sender of the associated request, for each terminated >>> early dialog, excepting those for which it has already >> transmitted >>> a 199 response. >>> >>> Note that the "already transmitted 199 responses" may have >> come from >>> downstream proxies as well as downstream UASs, so this >> consideration >>> applies even if we do not allow UASs to send 199s. >>> >>> * Section 7 >>> >>> Since all SIP entities involved in a session setup do >> not necessarily >>> support the specific meaning of the 199 Early Dialog Terminated >>> provisional response, the sender of the response MUST be >> prepared to >>> receive SIP requests associated with the dialog for which the 199 >>> response was sent. >>> >>> This situation can also result due to race conditions. Amend to: >>> >>> Because of race conditions and because the client may >> not support the >>> specific meaning of the 199 provisional response, the >> sender of the >>> response MUST be prepared to receive SIP requests associated with >>> the dialog for which the 199 response was sent. >>> >>> And add a qualifier to this sentence: >>> >>> If such request is received, and the receiver maintains state of >>> the dialogs, the receiver MUST reply to such requests with a 481 >>> final response (unless another error response is more >> appropriate). >>> * Section 7 >>> >>> Remove "..." from this sentence and add "even" as marked: >>> >>> The 199 Early Dialog Terminated response code MUST NOT replace a >>> final response. A final response MUST always be sent, >> *even* after >>> one or many 199 Early Dialog Terminated provisional >> responses have >>> been sent. >>> >>> * Section 8 >>> >>> Clarify this sentence to: >>> >>> The 199 Early Dialog Terminated response code allows a SIP entity >>> to indicate to upstream entities that a specific early dialog has >>> been terminated, before a final response reaches the upstream >>> entities. >>> >>> Add the following: >>> >>> The early dialog that has been terminated is identified >> by the Call-Id >>> header and the to-tag value of the 199 response. >>> >>> Future standards may define optional additional >> information carried >>> in the headers and/or body of the response. >>> >>> * Section 9 >>> >>> A 199 Early Dialog Terminated provisional response MUST >> NOT contain a >>> new SDP offer/answer message body, but the sender of the >> response MAY >>> insert a copy of a previously sent offer/answer message body as >>> otherwise allowed by the offer/answer rules for a provisional >>> response. >>> >>> This rule seems excessively strict, as it seems OK to send >> a new SDP >>> answer in a 199, even if the dialog will be immediately terminated. >>> Certainly, the UAC cannot tell the difference, as there could have >>> been a previous but lost 1xx response carrying the same SDP. >>> >>> The interaction of 199 and SDP probably needs further study... >>> >>> * Section 11 >>> >>> Nit: Use "reject" here rather than "rejects": >>> >>> UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx >> error response. >>> Here is a modification of the example, showing how a UAS can send a >>> 199, and how the proxy handles it. (You may or may not want to use >>> this.) I've also added the ACK's for the 4xx's, which were >> missing in >>> the original. >>> >>> [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error >>> response. UAS_3 sends a 199 with its 4xx. When P1 receives the >>> 4xx response from UAS_2 it immediately sends a 199 Early Dialog >>> Terminated associated with UAS_2's dialog towards the UAC. P1 >>> transmits UAS_3's 199, and so does not initiate one itself for >>> UAS_3's dialog when it receives UAS_3's 4xx response. >>> >>> UAC P1 UAS_2 UAS_3 UAS_4 >>> >>> --- INVITE ------> >>> --- INVITE (leg 2) -> >>> --- INVITE (leg 3) ----------> >>> --- INVITE (leg 4) -------------------> >>> <-- 18x (leg 2) ----- >>> <-- 18x (leg 2) -- >>> <-- 18x (leg 3) -------------- >>> <-- 18x (leg 3) -- >>> <-- 18x (leg 4) ----------------------- >>> <-- 18x (leg 4) -- >>> <-- 4xx (leg 2) ----- >>> <-- 199 (leg 2) -- >>> --- ACK (leg 2) ----> >>> <-- 199 (leg 3) -------------- >>> <-- 199 (leg 3) -- >>> <-- 4xx (leg 3) -------------- >>> --- ACK (leg 3) -------------> >>> <-- 200 (leg 4) ----------------------- >>> <-- 200 (leg 4) -- >>> --- ACK (leg 4) -> >>> --- ACK (leg 4) ----------------------> >>> >>> Dale >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 12:11:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628863A6845; Fri, 13 Jun 2008 12:11:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2A53A6804 for ; Fri, 13 Jun 2008 12:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 fYro0FamYe90 for ; Fri, 13 Jun 2008 12:11:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7F9103A6845 for ; Fri, 13 Jun 2008 12:11:43 -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 m5DJACv12524; Fri, 13 Jun 2008 19:10:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 14:10:54 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> In-Reply-To: <4852C62F.4030007@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNiRQPCIMAOFOhT9OhVQ/1KV8BxwAABJSQ References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yeah, exactly. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, June 13, 2008 12:11 > To: Audet, Francois (SC100:3055) > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > > > Francois Audet wrote: > > I can think of one scenario... > > > > If the UAS in question is actually some sort of B2BUA. > > OK. That is a good one. > > That is certainly a reason not to forbid it. > > And in that case we would expect the B2BUA to follow the > rules for proxies about handling and generating 199. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 14:02:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D163A69E9; Fri, 13 Jun 2008 14:02:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945A43A6931 for ; Fri, 13 Jun 2008 14:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 fA5GY1sV4Lit for ; Fri, 13 Jun 2008 14:02:27 -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 711573A69E9 for ; Fri, 13 Jun 2008 14:02:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,641,1204520400"; d="scan'208";a="10979421" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2008 17:02:59 -0400 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 m5DL2xMo006139; Fri, 13 Jun 2008 17:02:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5DL2x1P007702; Fri, 13 Jun 2008 21:02:59 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.1830); Fri, 13 Jun 2008 17:02:59 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:02:59 -0400 Message-ID: <4852E0B2.3000306@cisco.com> Date: Fri, 13 Jun 2008 17:03:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francois Audet References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 13 Jun 2008 21:02:59.0075 (UTC) FILETIME=[DC0EF530:01C8CD98] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1083; t=1213390979; x=1214254979; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Francois=20Audet=20; bh=T9z24uXd+UqyJwjqcThvLfxrGXCaYJoOyTwak7arp8g=; b=Wgh+GMcP9859kYcpMTOnO6vjMBTPv+HeOudyJ8wvVYbEtyclybQFjdFocF P2iPwcq09UzSbpiKRFraiNw/Z5z6qjnEPuJRDZRhIUb7GDubjMa0TbqBP0Z+ nRzY67PwXc; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org So the text certainly needs to permit this case. But I think some care is needed about a UAS that is really at the end of the end of the stream (downstream, where the packets soak into the ground.) Do we want to allow that UAS to send 199 responses? If so, what if any guidelines should be given? Seems to me we need a pretty strong SHOULD NOT here, with the B2BUA being the known exception. Paul Francois Audet wrote: > Yeah, exactly. > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, June 13, 2008 12:11 >> To: Audet, Francois (SC100:3055) >> Cc: Dale.Worley@comcast.net; sip@ietf.org >> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >> >> >> >> Francois Audet wrote: >>> I can think of one scenario... >>> >>> If the UAS in question is actually some sort of B2BUA. >> OK. That is a good one. >> >> That is certainly a reason not to forbid it. >> >> And in that case we would expect the B2BUA to follow the >> rules for proxies about handling and generating 199. > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 14:56:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9294E3A686C; Fri, 13 Jun 2008 14:56:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E783A686C for ; Fri, 13 Jun 2008 14:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrpsalpvbRyp for ; Fri, 13 Jun 2008 14:56:35 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id E08503A67A7 for ; Fri, 13 Jun 2008 14:56:34 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id dSdY1Z00z0cZkys590Ji00; Fri, 13 Jun 2008 21:57:06 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA10.westchester.pa.mail.comcast.net with comcast id dZx51Z00E02AVH03WZx5qx; Fri, 13 Jun 2008 21:57:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=WPCZQANMUbwA:10 a=-TzPRHrdgPoA:10 a=VCBkfJssAa0o2mncLggA:9 a=jlVwTTNyrciuCP8MQ6QA:7 a=DHaykWXwa2Dpeatbo1zfOcL6ne4A:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5DLv5PO017446 for ; Fri, 13 Jun 2008 17:57:05 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5DLv5ov017442; Fri, 13 Jun 2008 17:57:05 -0400 Date: Fri, 13 Jun 2008 17:57:05 -0400 Message-Id: <200806132157.m5DLv5ov017442@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <48527F1A.90302@cisco.com> (pkyzivat@cisco.com) References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Paul Kyzivat However I am still scratching my head about the UAS sending a 199. While I see no reason to forbid it I'm trying to find a situation when it would be helpful. The only case I have been able to think of is: I admit I hadn't considered whether a UAS sending 199 is useful. But in giving the rules for proxies, we must take care of the case where a downstream proxy sends a 199. This is where we get the rule that if a proxy propagates a 199 for an early dialog, then it should not send a 199 for that early dialog itself. Once we've set that rule for proxies, then a UAS can also send a 199 without breaking anything. But it does look like there is no gain from sending a 199 unless the corresponding final response will not be sent immediately. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 15:17:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0A33A691B; Fri, 13 Jun 2008 15:17:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08333A68AA for ; Fri, 13 Jun 2008 15:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 a0c7hIVlFqvX for ; Fri, 13 Jun 2008 15:17:24 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 9F6E73A6806 for ; Fri, 13 Jun 2008 15:17:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5DMH5127968; Fri, 13 Jun 2008 22:17:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 17:16:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF176104CF@zrc2hxm0.corp.nortel.com> In-Reply-To: <4852E0B2.3000306@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNmN2heiksbtHRR7SRkkHufdIp0wACh12Q References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yeah, I think we should say that this feature is intended to be used by Proxies and not by UAS. The reason it is allowed for UAS is for B2BUA who often act in many ways like a proxy. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, June 13, 2008 14:04 > To: Audet, Francois (SC100:3055) > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > So the text certainly needs to permit this case. > > But I think some care is needed about a UAS that is really at > the end of the end of the stream (downstream, where the > packets soak into the > ground.) Do we want to allow that UAS to send 199 responses? > If so, what if any guidelines should be given? > > Seems to me we need a pretty strong SHOULD NOT here, with the > B2BUA being the known exception. > > Paul > > Francois Audet wrote: > > Yeah, exactly. > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, June 13, 2008 12:11 > >> To: Audet, Francois (SC100:3055) > >> Cc: Dale.Worley@comcast.net; sip@ietf.org > >> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > >> > >> > >> > >> Francois Audet wrote: > >>> I can think of one scenario... > >>> > >>> If the UAS in question is actually some sort of B2BUA. > >> OK. That is a good one. > >> > >> That is certainly a reason not to forbid it. > >> > >> And in that case we would expect the B2BUA to follow the rules for > >> proxies about handling and generating 199. > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 13 23:59:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421253A6905; Fri, 13 Jun 2008 23:59:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257E23A6905 for ; Fri, 13 Jun 2008 23:59:01 -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 1FbycPYopbnJ for ; Fri, 13 Jun 2008 23:59:00 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 235523A6815 for ; Fri, 13 Jun 2008 23:58:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id E810B1EC27A; Sat, 14 Jun 2008 09:59:31 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaAdVPJHUl-E; Sat, 14 Jun 2008 09:59:25 +0300 (EEST) Received: from taimen (h151152.gprs.dnafinland.fi [87.93.151.152]) by tutpro.com (Postfix) with ESMTP; Sat, 14 Jun 2008 09:59:25 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id BF81F1C800A; Sat, 14 Jun 2008 09:59:18 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18515.27718.204853.637776@taimen.test.fi> Date: Sat, 14 Jun 2008 09:59:18 +0300 To: Paul Kyzivat In-Reply-To: <4852E0B2.3000306@cisco.com> References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> X-Mailer: VM 7.19 under Emacs 22.1.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > Seems to me we need a pretty strong SHOULD NOT here, with the B2BUA > being the known exception. i don't agree excepting B2BUA for anything as long as b2bua has been officially added and defined as a new sip related entity in addition to UAs, registrars and proxies. once that is done, then every sip specification has to state if/when ua procedures also apply to these B2BUAs. -- juha _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 14 05:45:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B823A692A; Sat, 14 Jun 2008 05:45:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699AE3A6A66 for ; Sat, 14 Jun 2008 05:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 UNiMKmUpvINT for ; Sat, 14 Jun 2008 05:45:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EF4F53A692A for ; Sat, 14 Jun 2008 05:45:35 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7DB572078E; Sat, 14 Jun 2008 14:46:08 +0200 (CEST) X-AuditID: c1b4fb3c-ab095bb00000193b-af-4853bd908d80 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6019620688; Sat, 14 Jun 2008 14:46:08 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jun 2008 14:46:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 14 Jun 2008 14:46:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjN7EbpE0V7wzkjRJSkwpWDpnqdZAALrq1y References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><48527F1A.90302@cisco.com><1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com><4852C62F.4030007@cisco.com><1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com><4852E0B2.3000306@cisco.com> <18515.27718.204853.637776@taimen.test.fi> From: "Christer Holmberg" To: "Juha Heinanen" , "Paul Kyzivat" X-OriginalArrivalTime: 14 Jun 2008 12:46:18.0857 (UTC) FILETIME=[A4284D90:01C8CE1C] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Juha, Chapter 6 of RFC3261 DOES define Back-to-Back User Agent. Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. We could of course say something like: "UAS, when part of a B2BUA" Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Juha Heinanen Sent: Sat 14/06/2008 08:59 To: Paul Kyzivat Cc: sip@ietf.org; Francois Audet Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Paul Kyzivat writes: > Seems to me we need a pretty strong SHOULD NOT here, with the B2BUA > being the known exception. i don't agree excepting B2BUA for anything as long as b2bua has been officially added and defined as a new sip related entity in addition to UAs, registrars and proxies. once that is done, then every sip specification has to state if/when ua procedures also apply to these B2BUAs. -- juha _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 14 05:55:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56373A6A83; Sat, 14 Jun 2008 05:55:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0276D3A692A for ; Sat, 14 Jun 2008 05:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 itgMEIIGrUCt for ; Sat, 14 Jun 2008 05:55:19 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A8DCF3A6A83 for ; Sat, 14 Jun 2008 05:55:18 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CDB2C20373; Sat, 14 Jun 2008 14:55:51 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-e5-4853bfd7221b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A390A200C6; Sat, 14 Jun 2008 14:55:51 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jun 2008 14:56:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 14 Jun 2008 14:52:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjNY0+N0dMtGwcBQqqs0pOQQKsVpgAujspa References: <485286A3.5010401@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Francois Audet" X-OriginalArrivalTime: 14 Jun 2008 12:56:02.0131 (UTC) FILETIME=[FFD0DA30:01C8CE1D] X-Brightmail-Tracker: AAAAAA== Cc: SIP IETF Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I think Paul's suggestion sounds good. I think it's also alligned with what Francois suggested earlier, to say "MUST include response code". Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Paul Kyzivat Sent: Fri 13/06/2008 16:39 To: Francois Audet Cc: SIP IETF Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt My first thought was to agree with Dale, and in fact I already suggested use of sipfrag. But I already have experience from the refer NOTIFY that sipfrag info is difficult to take advantage of if you have no guarantee of what will be included. IIRC this 199 work was explicitly not expected to solve the full HERFP problem. Yet if it could serve for that it would be a good thing. Its just that thrashing out everything that is needed will take a bunch of time. Also, sending back the whole message will make more data to send in cases where it often isn't useful. We could allow a body containing *either* message/sip or message/sipfrag, and make them both conditional on presence of a corresponding Accept header in the request. If there was no Accept header for either then no body would be included. If there was an accept for both, message/sip would be be preferred. When a sipfrag is returned in a 199, we could require that it include at least the header line, and the rest would be at the discretion of the proxy. Paul Francois Audet wrote: > And do you think we should specify what are the minimum headers thatshould > be carried? > > What about MIME bodies? > > There might be cases where they are really important, no? > > I'm a little worried that the proxy may remove important information. > Especially when we extend SIP. > > Maybe instead we should list the removable headers (e.g., all the ones that > are identical to their counterpart in the 199 itself), and then explain > "don't remove what you don't understand"? > > Opinions? > > > On Jun12 2008 20:05 , "Dale.Worley@comcast.net" > wrote: > >> From: "Francois Audet" >> >> I really think that this draft should make the inclusion of the original >> non-2XX final response in the 199 MANDATORY by the forking proxy. This >> would >> be in a message/sip body as described in sectin 23.4/RFC 3261. >> >> (This is outside the scope of the I-D itself.) >> >> If we envision having the 199 carry information from the associated >> failure response, I suggest we use a message/sipfrag body excerpted >> from the failure response, rather than copying headers from the >> failure response into the 199's headers, or copying the entire failure >> response as the body of the 199. >> >> The syntax of sipfrag is unambiguous but extremely flexible (RFC >> 3420): >> >> sipfrag = [ start-line ] >> *message-header >> [ CRLF [ message-body ] ] >> >> Essentially, it is any subset of the headers of the response, >> optionally followed by the body. This subsetting capability allows >> small responses (e.g., omit the Via's, Call-Id, To, From, >> Record-Route's, etc.), as well as making topology-hiding >> straightforward. >> >> It's also inherently extensible, in that if a proxy/UAS decides to add >> more headers to the sipfrag, the UAC knows how to identify and/or >> ignore them. >> >> It's also terse, in that carrying any header from the response in a >> message/sipfrag body is no longer than carrying it as a header of the >> 199 response. >> >> Dale >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 14 06:20:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310873A68C8; Sat, 14 Jun 2008 06:20:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29A83A6A9D for ; Sat, 14 Jun 2008 06:20: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 FyqaU0GFWEHB for ; Sat, 14 Jun 2008 06:20:17 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 37C703A6850 for ; Sat, 14 Jun 2008 06:20:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 1DC991EC27A; Sat, 14 Jun 2008 16:20:51 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwz3hgEWHZkx; Sat, 14 Jun 2008 16:20:44 +0300 (EEST) Received: from taimen (h15635.gprs.dnafinland.fi [87.93.156.35]) by tutpro.com (Postfix) with ESMTP; Sat, 14 Jun 2008 16:20:44 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 912111C800A; Sat, 14 Jun 2008 16:20:38 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18515.50598.566583.38032@taimen.test.fi> Date: Sat, 14 Jun 2008 16:20:38 +0300 To: "Christer Holmberg" In-Reply-To: References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> <18515.27718.204853.637776@taimen.test.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, Paul Kyzivat , Francois Audet Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg writes: > Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a > logical entity that receives a request and processes it as a > user agent server (UAS). In order to determine how the request > should be answered, it acts as a user agent client (UAC) and > generates requests. Unlike a proxy server, it maintains dialog > state and must participate in all requests sent on the dialogs > it has established. > > We could of course say something like: > > "UAS, when part of a B2BUA" according to the B2BUA definition: Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. this means that there is no need to say anything special about 199 either. b2bus in terms of protocol specification, is just an uas like any other. -- juha _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 14 07:51:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55423A69AE; Sat, 14 Jun 2008 07:51:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A283A67ED for ; Sat, 14 Jun 2008 07:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 YgF80XHKmWEv for ; Sat, 14 Jun 2008 07:51:13 -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 6C8A03A69AE for ; Sat, 14 Jun 2008 07:51:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,644,1204520400"; d="scan'208";a="11028128" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2008 10:51:48 -0400 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 m5EEplqY013334; Sat, 14 Jun 2008 10:51:48 -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.13.8) with ESMTP id m5EEpldT025440; Sat, 14 Jun 2008 14:51:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jun 2008 10:51:47 -0400 Received: from [10.86.240.88] ([10.86.240.88]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jun 2008 10:51:47 -0400 Message-ID: <4853DB2D.7060209@cisco.com> Date: Sat, 14 Jun 2008 10:52:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Juha Heinanen References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> <18515.27718.204853.637776@taimen.test.fi> <18515.50598.566583.38032@taimen.test.fi> In-Reply-To: <18515.50598.566583.38032@taimen.test.fi> X-OriginalArrivalTime: 14 Jun 2008 14:51:47.0566 (UTC) FILETIME=[2B9E20E0:01C8CE2E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1392; t=1213455108; x=1214319108; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Juha=20Heinanen=20; bh=nxidCgQPLxliYzFwbq7mENnvfgJekYjVwxhpTtz1KN0=; b=bfG3CFlSiC8Xmw7104BpyTF/X3aQg5UwIrWWzEJ9TF6StproMRUd2x7IpC q7gbS/iRucLw4V7qZKBwBH87q3argelJGsDo4lwSysFqoUfmjJQR9o7/BQGx K043qB1mgk; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, Francois Audet , Christer Holmberg Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, the specification could be abstracted to remove the mention of the B2BUA while still having the same effect. It would have to say something about a UAS should send a 199 if it knows the dialog will be terminated before it can send the final response. But I think we would still need to include an example of a B2BUA in order for anybody to have a clue what we were talking about. Paul Juha Heinanen wrote: > Christer Holmberg writes: > > > Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a > > logical entity that receives a request and processes it as a > > user agent server (UAS). In order to determine how the request > > should be answered, it acts as a user agent client (UAC) and > > generates requests. Unlike a proxy server, it maintains dialog > > state and must participate in all requests sent on the dialogs > > it has established. > > > > We could of course say something like: > > > > "UAS, when part of a B2BUA" > > according to the B2BUA definition: > > Since it is a concatenation of a UAC and > UAS, no explicit definitions are needed for its behavior. > > this means that there is no need to say anything special about 199 > either. b2bus in terms of protocol specification, is just an uas like > any other. > > -- juha > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 14 08:59:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5BC3A6A5A; Sat, 14 Jun 2008 08:59:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1613A695D for ; Sat, 14 Jun 2008 08:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, 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 AM5Hj2vz7V8J for ; Sat, 14 Jun 2008 08:59:32 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.119.2.190]) by core3.amsl.com (Postfix) with ESMTP id 7DDF43A6A5A for ; Sat, 14 Jun 2008 08:59:31 -0700 (PDT) Received: from rly09f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly09f.srv.mailcontrol.com (MailControl) with ESMTP id m5EG02xS022688 for ; Sat, 14 Jun 2008 17:00:02 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly09f.srv.mailcontrol.com (MailControl) id m5EFxmuT021983 for sip@ietf.org; Sat, 14 Jun 2008 16:59:48 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly09f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id m5EFxjQi021727; Sat, 14 Jun 2008 16:59:47 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jun 2008 17:01:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 14 Jun 2008 16:59:36 +0100 Message-ID: <680808427CF931459462C3D78CB5EC601CCF2C@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNXzah/o/xCGVESEOOeRMvhrFHbgA2G5uy References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> From: "Attila Sipos" To: "Paul Kyzivat" , X-OriginalArrivalTime: 14 Jun 2008 16:01:12.0519 (UTC) FILETIME=[DE1F8570:01C8CE37] X-Scanned-By: MailControl A-08-50-03 (www.mailcontrol.com) on 10.70.1.119 Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1044738027==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1044738027== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CE37.DE386554" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CE37.DE386554 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>However I am still scratching my head about the UAS sending a 199. While= =20 >>I see no reason to forbid it I'm trying to find a situation when it=20 >>would be helpful.=20 It may or may not be helpful but as you say, you can see no reason to forbid it. Why restrict it if the restriction isn't needed? As someone has pointed out, a B2BUA scenario might benefit from 199. In fact, any kind of SIP gateway might benefit. > This is one of those cases that could probably benefit from > simulation to judge the merits. My gut feel is that the costs > of the UAS sending the 199 outweigh the benefits.=20 If the UAS wants to send it, that is a decision for them - not something that needs to be prevented. SIP forking, in the technical sense of sending a response with a different to-tag, is always legal. So, any UA which has used forking should also be able to use 199. I don't think we need to include any specific text about UAS except to say that a UAS can use it if the UAS has created the forking. Regards, Attila -----Original Message----- From: sip-bounces@ietf.org on behalf of Paul Kyzivat Sent: Fri 13/06/2008 15:07 To: Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 =20 This all sounds like good stuff. However I am still scratching my head about the UAS sending a 199. While=20 I see no reason to forbid it I'm trying to find a situation when it=20 would be helpful. The only case I have been able to think of is: There is a forking proxy upstream of the UAS, but it doesn't support 199. Yet it may delay the final response while it tries other forks. So the UAS sending the 199 makes up for the inadequacy of the forking proxy. The trouble with this is that it is inefficient in many cases. If each=20 proxy that forks also supports the sending of 199, and the UAS doesn't=20 send one, then we avoid sending the message except in cases where it is=20 helpful. If the UAS always sends it we have increased the message count=20 by one for all failing calls. And the majority of failing calls get no=20 benefit from a 199. This is one of those cases that could probably benefit from simulation=20 to judge the merits. My gut feel is that the costs of the UAS sending=20 the 199 outweigh the benefits. Barring some analysis to the contrary I=20 think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send,=20 but without any guidance of when. Paul Dale.Worley@comcast.net wrote: > Here are some comments on this I-D. I don't think that any of them > modify our understanding of the proposal. I guess this is very terse; > please use these suggestions as you see fit. >=20 > * Abstract >=20 > Clarify: >=20 > This specification defines a new SIP response code, 199 Early > Dialog Terminated, which a SIP entity can use to indicate upstream > that an early dialog has been terminated. The response code can be > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > an early dialog has been terminated. As the 199 response is a > provisional response, often the UAC will receive it before > receiving a final response to its request. >=20 > * Section 1 >=20 > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations where > the forked request was forwarded. >=20 > The text does not allow for serial forking, only parallel forking, > which might be confusing to people who are more aware of serial > forking. So amend the last sentence to: >=20 > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. >=20 > Also, Avoid using "..." except when indicating that the word is used > in a non-standard way or that one is discussing the word itself: >=20 > Instead, the forking proxy "stores" it [...] >=20 > should be: >=20 > Instead, the forking proxy stores it [...] >=20 > * Section 3. >=20 > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. >=20 > Oddly, though everyone thinks they understand this sentence, it > doesn't really say what we want. To really ensure that the UAC > understands the early dialog has been terminated before the UAS sends > a final response, the UAS would have to send 199 *and get the PRACK > saying that it was received* before sending a final response. This may > well be worse than the present state of affairs. >=20 > What we really mean is: >=20 > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. >=20 > * Section 4 >=20 > When a client receives a 199 Early Dialog Terminated provisional > response it MAY release resources and procedures associated with the > early dialog the 199 response is received on. >=20 > Amend to clarify the meaning of 199 independently of the consequences > of that meaning: >=20 > When a client receives a 199 Early Dialog Terminated provisional > response, it has positive knowledge that the UAS that created the > early dialog has terminated it, and so the client MAY release > resources and procedures associated with the early dialog for which > the 199 response is received. >=20 > * Section 4 >=20 > Add this paragraph before the last paragraph: >=20 > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. >=20 > This is copied from section 7 (Backward Compatibility), but since it > is a constraint on UACs, it should also be stated in this section. >=20 > * Section 4 >=20 > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initiation request to be rejected. >=20 > What is the meaning of the final clause? >=20 > * Section 5 >=20 > Add "early" as marked: >=20 > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. >=20 > This clarifies that 199 cannot be used to terminate a confirmed > dialog. >=20 > (The reason a UAS may want to send a 199 is to provide this > information even when the upstream proxy does not support 199.) >=20 > There is a subtlty to the second sentence: >=20 > Sending the 199 *before* the final response is not necessary due to > the semantics of 199 (as it will probably reach the UAC first anyway, > and it would not matter if it did not), but rather to prevent the > upstream proxy from generating a 199 based on the final response, and > then to transmit the UAS's 199 immediately after -- if the UAS sends > the 199 first, any upstream proxy will (most likely) see the 199 > before seeing the final response (which might induce the proxy to send > its own 199). >=20 > * Section 6 >=20 > When a forking proxy receives a non-2xx final response which > terminates one or more early dialogs and the proxy does not intend to > forward the final response immediately (due to the rules for a > forking proxy) it MUST send a 199 provisional response, for each > associated early dialog that it can associate with the final > response, upstream towards the sender of the associated request. >=20 > Clarify, and note that if the proxy has already passed a 199 for an > early dialog, it need not generate one itself. Also, I've reduced > MUST to SHOULD, because (as the following NOTE explains), the proxy > may not know of all early dialogs which are terminated by the final > response. >=20 > [...] it SHOULD initiate a 199 provisional response upstream > towards the sender of the associated request, for each terminated > early dialog, excepting those for which it has already transmitted > a 199 response. >=20 > Note that the "already transmitted 199 responses" may have come from > downstream proxies as well as downstream UASs, so this consideration > applies even if we do not allow UASs to send 199s. >=20 > * Section 7 >=20 > Since all SIP entities involved in a session setup do not necessarily > support the specific meaning of the 199 Early Dialog Terminated > provisional response, the sender of the response MUST be prepared to > receive SIP requests associated with the dialog for which the 199 > response was sent. >=20 > This situation can also result due to race conditions. Amend to: >=20 > Because of race conditions and because the client may not support the > specific meaning of the 199 provisional response, the sender of the > response MUST be prepared to receive SIP requests associated with > the dialog for which the 199 response was sent. >=20 > And add a qualifier to this sentence: >=20 > If such request is received, and the receiver maintains state of > the dialogs, the receiver MUST reply to such requests with a 481 > final response (unless another error response is more appropriate). >=20 > * Section 7 >=20 > Remove "..." from this sentence and add "even" as marked: >=20 > The 199 Early Dialog Terminated response code MUST NOT replace a > final response. A final response MUST always be sent, *even* after > one or many 199 Early Dialog Terminated provisional responses have > been sent. >=20 > * Section 8 >=20 > Clarify this sentence to: >=20 > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. >=20 > Add the following: >=20 > The early dialog that has been terminated is identified by the Call-Id > header and the to-tag value of the 199 response. >=20 > Future standards may define optional additional information carried > in the headers and/or body of the response. >=20 > * Section 9 >=20 > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. >=20 > This rule seems excessively strict, as it seems OK to send a new SDP > answer in a 199, even if the dialog will be immediately terminated. > Certainly, the UAC cannot tell the difference, as there could have > been a previous but lost 1xx response carrying the same SDP. >=20 > The interaction of 199 and SDP probably needs further study... >=20 > * Section 11 >=20 > Nit: Use "reject" here rather than "rejects": >=20 > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. >=20 > Here is a modification of the example, showing how a UAS can send a > 199, and how the proxy handles it. (You may or may not want to use > this.) I've also added the ACK's for the 4xx's, which were missing in > the original. >=20 > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > Terminated associated with UAS_2's dialog towards the UAC. P1 > transmits UAS_3's 199, and so does not initiate one itself for > UAS_3's dialog when it receives UAS_3's 4xx response. >=20 > UAC P1 UAS_2 UAS_3 UAS_4 >=20 > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > --- ACK (leg 2) ----> > <-- 199 (leg 3) -------------- > <-- 199 (leg 3) -- > <-- 4xx (leg 3) -------------- > --- ACK (leg 3) -------------> > <-- 200 (leg 4) ----------------------- > <-- 200 (leg 4) -- > --- ACK (leg 4) -> > --- ACK (leg 4) ----------------------> >=20 > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C8CE37.DE386554 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Draft submission: draft-ietf-sip-199-00

>>However I am still scratching my head about the U= AS sending a 199. While
>>I see no reason to forbid it I'm trying to find a situation when it=
>>would be helpful.

It may or may not be helpful but as you say, you can
see no reason to forbid it.

Why restrict it if the restriction isn't needed?

As someone has pointed out, a B2BUA scenario might benefit
from 199.  In fact, any kind of SIP gateway might benefit.

> This is one of those cases that could probably benefit from
> simulation to judge the merits. My gut feel is that the costs
> of the UAS sending the 199 outweigh the benefits.

If the UAS wants to send it, that is a decision for
them - not something that needs to be prevented.

SIP forking, in the technical sense of sending a
response with a different to-tag, is always legal.
So, any UA which has used forking
should also be able to use 199.

I don't think we need to include any specific text about UAS
except to say that a UAS can use it if the UAS has created
the forking.

Regards,

Attila



-----Original Message-----
From: sip-bounces@ietf.org on behalf of Paul Kyzivat
Sent: Fri 13/06/2008 15:07
To: Dale.Worley@comcast.net
Cc: sip@ietf.org
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

This all sounds like good stuff.

However I am still scratching my head about the UAS sending a 199. While
I see no reason to forbid it I'm trying to find a situation when it
would be helpful. The only case I have been able to think of is:

   There is a forking proxy upstream of the UAS, but it doesn't    support 199. Yet it may delay the final response while it
   tries other forks. So the UAS sending the 199 makes up for
   the inadequacy of the forking proxy.

The trouble with this is that it is inefficient in many cases. If each
proxy that forks also supports the sending of 199, and the UAS doesn't
send one, then we avoid sending the message except in cases where it is
helpful. If the UAS always sends it we have increased the message count
by one for all failing calls. And the majority of failing calls get no
benefit from a 199.

This is one of those cases that could probably benefit from simulation
to judge the merits. My gut feel is that the costs of the UAS sending
the 199 outweigh the benefits. Barring some analysis to the contrary I
think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send,
but without any guidance of when.

        Paul

Dale.Worley@comcast.net wrote:
> Here are some comments on this I-D.  I don't think that any of th= em
> modify our understanding of the proposal.  I guess this is very t= erse;
> please use these suggestions as you see fit.
>
> * Abstract
>
> Clarify:
>
>    This specification defines a new SIP response code, = 199 Early
>    Dialog Terminated, which a SIP entity can use to ind= icate upstream
>    that an early dialog has been terminated.  The = response code can be
>    used by a SIP entity (a SIP proxy or UAS), to inform= the UAC that
>    an early dialog has been terminated.  As the 19= 9 response is a
>    provisional response, often the UAC will receive it = before
>    receiving a final response to its request.
>
> * Section 1
>
>    When a forking proxy receives a non-2xx final respon= se, it does not
>    always immediately forward the response upstream tow= ards the sender
>    of the associated request.  Instead, the forkin= g proxy "stores" it
>    and waits for further final responses from remote de= stinations where
>    the forked request was forwarded.
>
> The text does not allow for serial forking, only parallel forking,
> which might be confusing to people who are more aware of serial
> forking.  So amend the last sentence to:
>
>    Instead, the forking proxy "stores" it and= waits for further final
>    responses from remote destinations where the forked = request was
>    forwarded, and possibly forwards the request to addi= tional
>    destinations.
>
> Also, Avoid using "..." except when indicating that the word= is used
> in a non-standard way or that one is discussing the word itself:
>
>    Instead, the forking proxy "stores" it [..= .]
>
> should be:
>
>    Instead, the forking proxy stores it [...]
>
> * Section 3.
>
>    REQ 1: It must be possible to indicate to the UAC th= at an early
>    dialog has been terminated before a final response i= s sent.
>
> Oddly, though everyone thinks they understand this sentence, it
> doesn't really say what we want.  To really ensure that the UAC > understands the early dialog has been terminated before the UAS sends<= BR> > a final response, the UAS would have to send 199 *and get the PRACK
> saying that it was received* before sending a final response.  Th= is may
> well be worse than the present state of affairs.
>
> What we really mean is:
>
>    REQ 1: It must be possible for a UAS or proxy to sen= d an indication
>    to the UAC that an early dialog has been terminated,= which
>    indication will not be delayed waiting for a final r= esponse from
>    any UAS.
>
> * Section 4
>
>    When a client receives a 199 Early Dialog Terminated= provisional
>    response it MAY release resources and procedures ass= ociated with the
>    early dialog the 199 response is received on.
>
> Amend to clarify the meaning of 199 independently of the consequences<= BR> > of that meaning:
>
>    When a client receives a 199 Early Dialog Terminated= provisional
>    response, it has positive knowledge that the UAS tha= t created the
>    early dialog has terminated it, and so the client MA= Y release
>    resources and procedures associated with the early d= ialog for which
>    the 199 response is received.
>
> * Section 4
>
> Add this paragraph before the last paragraph:
>
>    A UAC that receives a 199 response for an early dial= og MUST NOT
>    send any further requests on that dialog, except for= a PRACK if the
>    199 response was sent reliably, and PRACKs for other= reliable
>    provisional responses that are to be acknowledged. >
> This is copied from section 7 (Backward Compatibility), but since it > is a constraint on UACs, it should also be stated in this section.
>
> * Section 4
>
>    The UAC MAY use additional information (for example = the final
>    response which triggered the 199 response) received = in the 199
>    response when initiating new sessions, if it is poss= ible to avoid the
>    new session initiation request to be rejected.
>
> What is the meaning of the final clause?
>
> * Section 5
>
> Add "early" as marked:
>
>    When a UAS wants to terminate *an early* dialog it s= ends a non-2xx
>    SIP final response, as specified in [RFC3261]. = In addition, prior
>    to sending the non-2xx SIP final response, the UAS M= AY send a 199
>    response to indicate that the dialog is being termin= ated.
>
> This clarifies that 199 cannot be used to terminate a confirmed
> dialog.
>
> (The reason a UAS may want to send a 199 is to provide this
> information even when the upstream proxy does not support 199.)
>
> There is a subtlty to the second sentence:
>
> Sending the 199 *before* the final response is not necessary due to
> the semantics of 199 (as it will probably reach the UAC first anyway,<= BR> > and it would not matter if it did not), but rather to prevent the
> upstream proxy from generating a 199 based on the final response, and<= BR> > then to transmit the UAS's 199 immediately after -- if the UAS sends > the 199 first, any upstream proxy will (most likely) see the 199
> before seeing the final response (which might induce the proxy to send=
> its own 199).
>
> * Section 6
>
>    When a forking proxy receives a non-2xx final respon= se which
>    terminates one or more early dialogs and the proxy d= oes not intend to
>    forward the final response immediately (due to the r= ules for a
>    forking proxy) it MUST send a 199 provisional respon= se, for each
>    associated early dialog that it can associate with t= he final
>    response, upstream towards the sender of the associa= ted request.
>
> Clarify, and note that if the proxy has already passed a 199 for an
> early dialog, it need not generate one itself.  Also, I've reduce= d
> MUST to SHOULD, because (as the following NOTE explains), the proxy
> may not know of all early dialogs which are terminated by the final
> response.
>
>    [...] it SHOULD initiate a 199 provisional response = upstream
>    towards the sender of the associated request, for ea= ch terminated
>    early dialog, excepting those for which it has alrea= dy transmitted
>    a 199 response.
>
> Note that the "already transmitted 199 responses" may have c= ome from
> downstream proxies as well as downstream UASs, so this consideration > applies even if we do not allow UASs to send 199s.
>
> * Section 7
>
>    Since all SIP entities involved in a session setup d= o not necessarily
>    support the specific meaning of the 199 Early Dialog= Terminated
>    provisional response, the sender of the response MUS= T be prepared to
>    receive SIP requests associated with the dialog for = which the 199
>    response was sent.
>
> This situation can also result due to race conditions.  Amend to:=
>
>    Because of race conditions and because the client ma= y not support the
>    specific meaning of the 199 provisional response, th= e sender of the
>    response MUST be prepared to receive SIP requests as= sociated with
>    the dialog for which the 199 response was sent.
>
> And add a qualifier to this sentence:
>
>    If such request is received, and the receiver mainta= ins state of
>    the dialogs, the receiver MUST reply to such request= s with a 481
>    final response (unless another error response is mor= e appropriate).
>
> * Section 7
>
> Remove "..." from this sentence and add "even" as = marked:
>
>    The 199 Early Dialog Terminated response code MUST N= OT replace a
>    final response.  A final response MUST always b= e sent, *even* after
>    one or many 199 Early Dialog Terminated provisional = responses have
>    been sent.
>
> * Section 8
>
> Clarify this sentence to:
>
>    The 199 Early Dialog Terminated response code allows= a SIP entity
>    to indicate to upstream entities that a specific ear= ly dialog has
>    been terminated, before a final response reaches the= upstream
>    entities.
>
> Add the following:
>
>    The early dialog that has been terminated is identif= ied by the Call-Id
>    header and the to-tag value of the 199 response.
>
>    Future standards may define optional additional info= rmation carried
>    in the headers and/or body of the response.
>
> * Section 9
>
>    A 199 Early Dialog Terminated provisional response M= UST NOT contain a
>    new SDP offer/answer message body, but the sender of= the response MAY
>    insert a copy of a previously sent offer/answer mess= age body as
>    otherwise allowed by the offer/answer rules for a pr= ovisional
>    response.
>
> This rule seems excessively strict, as it seems OK to send a new SDP > answer in a 199, even if the dialog will be immediately terminated.
> Certainly, the UAC cannot tell the difference, as there could have
> been a previous but lost 1xx response carrying the same SDP.
>
> The interaction of 199 and SDP probably needs further study...
>
> * Section 11
>
> Nit:  Use "reject" here rather than "rejects"= :
>
>    UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx= error response.
>
> Here is a modification of the example, showing how a UAS can send a
> 199, and how the proxy handles it.  (You may or may not want to u= se
> this.)  I've also added the ACK's for the 4xx's, which were missi= ng in
> the original.
>
>    [...] UAS_2 and UAS_3 reject the INVITE by sending a= 4xx error
>    response.  UAS_3 sends a 199 with its 4xx. = ; When P1 receives the
>    4xx response from UAS_2 it immediately sends a 199 E= arly Dialog
>    Terminated associated with UAS_2's dialog towards th= e UAC.  P1
>    transmits UAS_3's 199, and so does not initiate one = itself for
>    UAS_3's dialog when it receives UAS_3's 4xx response= .
>
>       UAC     &= nbsp;         P1   &= nbsp;           &nbs= p;  UAS_2    UAS_3    UAS_4
>
>        --- INVITE ------>
>            = ;            &n= bsp; --- INVITE (leg 2) ->
>            = ;            &n= bsp; --- INVITE (leg 3) ---------->
>            = ;            &n= bsp; --- INVITE (leg 4) ------------------->
>            = ;            &n= bsp; <-- 18x (leg 2) -----
>        <-- 18x (leg 2) --
>            = ;            &n= bsp; <-- 18x (leg 3) --------------
>        <-- 18x (leg 3) --
>            = ;            &n= bsp; <-- 18x (leg 4) -----------------------
>        <-- 18x (leg 4) --
>            = ;            &n= bsp; <-- 4xx (leg 2) -----
>        <-- 199 (leg 2) --
>            = ;            &n= bsp; --- ACK (leg 2) ---->
>            = ;            &n= bsp; <-- 199 (leg 3) --------------
>        <-- 199 (leg 3) --
>            = ;            &n= bsp; <-- 4xx (leg 3) --------------
>            = ;            &n= bsp; --- ACK (leg 3) ------------->
>            = ;            &n= bsp; <-- 200 (leg 4) -----------------------
>        <-- 200 (leg 4) --
>        --- ACK (leg 4) ->
>            = ;            &n= bsp; --- ACK (leg 4) ---------------------->
>
> Dale
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



.

= ------_=_NextPart_001_01C8CE37.DE386554-- --===============1044738027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1044738027==-- From sip-bounces@ietf.org Sat Jun 14 14:34:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEC83A6971; Sat, 14 Jun 2008 14:34:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476A23A6978 for ; Sat, 14 Jun 2008 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 hhsZhXlGkQgi for ; Sat, 14 Jun 2008 14:33:58 -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 174253A687B for ; Sat, 14 Jun 2008 14:33:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,645,1204520400"; d="scan'208";a="11034048" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2008 17:34:25 -0400 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 m5ELYPZO008292; Sat, 14 Jun 2008 17:34:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5ELYPDw016087; Sat, 14 Jun 2008 21:34:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jun 2008 17:34:25 -0400 Received: from [10.86.240.88] ([10.86.240.88]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jun 2008 17:34:24 -0400 Message-ID: <4854398B.7020006@cisco.com> Date: Sat, 14 Jun 2008 17:35:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Attila Sipos References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <680808427CF931459462C3D78CB5EC601CCF2C@EXVS02.nasstar-t1.net> In-Reply-To: <680808427CF931459462C3D78CB5EC601CCF2C@EXVS02.nasstar-t1.net> X-OriginalArrivalTime: 14 Jun 2008 21:34:24.0746 (UTC) FILETIME=[6A6B44A0:01C8CE66] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15183; t=1213479265; x=1214343265; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Attila=20Sipos=20; bh=XeQva2MVCFgIpISUXuqv3S91bBpKn1ZE2OBlXLAqWtk=; b=j3+G7jDOJpgvjhVI24qkZT09dxG57JAisX3Q2zk9sHOnzzzzlYYjaFABts w20dwR9VZddboqXmi9u/iPREkCMV72OgD3EaprZrQRe9Lt0plfflQAGrBIBq InAyzQXn/b; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Attila, Sure we can take the approach of leaving it to the UAS to decide whether to send a 199. My concern is that it may be inefficient, not just for that UA, but for the system as a whole. So I think we need to be a little careful here. I'm not suggesting forbidding this - clearly there are cases where it is the right thing to do. Paul Attila Sipos wrote: > > >>However I am still scratching my head about the UAS sending a 199. While > >>I see no reason to forbid it I'm trying to find a situation when it > >>would be helpful. > > It may or may not be helpful but as you say, you can > see no reason to forbid it. > > Why restrict it if the restriction isn't needed? > > As someone has pointed out, a B2BUA scenario might benefit > from 199. In fact, any kind of SIP gateway might benefit. > > > This is one of those cases that could probably benefit from > > simulation to judge the merits. My gut feel is that the costs > > of the UAS sending the 199 outweigh the benefits. > > If the UAS wants to send it, that is a decision for > them - not something that needs to be prevented. > > SIP forking, in the technical sense of sending a > response with a different to-tag, is always legal. > So, any UA which has used forking > should also be able to use 199. > > I don't think we need to include any specific text about UAS > except to say that a UAS can use it if the UAS has created > the forking. > > Regards, > > Attila > > > > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Paul Kyzivat > Sent: Fri 13/06/2008 15:07 > To: Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > This all sounds like good stuff. > > However I am still scratching my head about the UAS sending a 199. While > I see no reason to forbid it I'm trying to find a situation when it > would be helpful. The only case I have been able to think of is: > > There is a forking proxy upstream of the UAS, but it doesn't > support 199. Yet it may delay the final response while it > tries other forks. So the UAS sending the 199 makes up for > the inadequacy of the forking proxy. > > The trouble with this is that it is inefficient in many cases. If each > proxy that forks also supports the sending of 199, and the UAS doesn't > send one, then we avoid sending the message except in cases where it is > helpful. If the UAS always sends it we have increased the message count > by one for all failing calls. And the majority of failing calls get no > benefit from a 199. > > This is one of those cases that could probably benefit from simulation > to judge the merits. My gut feel is that the costs of the UAS sending > the 199 outweigh the benefits. Barring some analysis to the contrary I > think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, > but without any guidance of when. > > Paul > > Dale.Worley@comcast.net wrote: > > Here are some comments on this I-D. I don't think that any of them > > modify our understanding of the proposal. I guess this is very terse; > > please use these suggestions as you see fit. > > > > * Abstract > > > > Clarify: > > > > This specification defines a new SIP response code, 199 Early > > Dialog Terminated, which a SIP entity can use to indicate upstream > > that an early dialog has been terminated. The response code can be > > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > > an early dialog has been terminated. As the 199 response is a > > provisional response, often the UAC will receive it before > > receiving a final response to its request. > > > > * Section 1 > > > > When a forking proxy receives a non-2xx final response, it does not > > always immediately forward the response upstream towards the sender > > of the associated request. Instead, the forking proxy "stores" it > > and waits for further final responses from remote destinations where > > the forked request was forwarded. > > > > The text does not allow for serial forking, only parallel forking, > > which might be confusing to people who are more aware of serial > > forking. So amend the last sentence to: > > > > Instead, the forking proxy "stores" it and waits for further final > > responses from remote destinations where the forked request was > > forwarded, and possibly forwards the request to additional > > destinations. > > > > Also, Avoid using "..." except when indicating that the word is used > > in a non-standard way or that one is discussing the word itself: > > > > Instead, the forking proxy "stores" it [...] > > > > should be: > > > > Instead, the forking proxy stores it [...] > > > > * Section 3. > > > > REQ 1: It must be possible to indicate to the UAC that an early > > dialog has been terminated before a final response is sent. > > > > Oddly, though everyone thinks they understand this sentence, it > > doesn't really say what we want. To really ensure that the UAC > > understands the early dialog has been terminated before the UAS sends > > a final response, the UAS would have to send 199 *and get the PRACK > > saying that it was received* before sending a final response. This may > > well be worse than the present state of affairs. > > > > What we really mean is: > > > > REQ 1: It must be possible for a UAS or proxy to send an indication > > to the UAC that an early dialog has been terminated, which > > indication will not be delayed waiting for a final response from > > any UAS. > > > > * Section 4 > > > > When a client receives a 199 Early Dialog Terminated provisional > > response it MAY release resources and procedures associated with the > > early dialog the 199 response is received on. > > > > Amend to clarify the meaning of 199 independently of the consequences > > of that meaning: > > > > When a client receives a 199 Early Dialog Terminated provisional > > response, it has positive knowledge that the UAS that created the > > early dialog has terminated it, and so the client MAY release > > resources and procedures associated with the early dialog for which > > the 199 response is received. > > > > * Section 4 > > > > Add this paragraph before the last paragraph: > > > > A UAC that receives a 199 response for an early dialog MUST NOT > > send any further requests on that dialog, except for a PRACK if the > > 199 response was sent reliably, and PRACKs for other reliable > > provisional responses that are to be acknowledged. > > > > This is copied from section 7 (Backward Compatibility), but since it > > is a constraint on UACs, it should also be stated in this section. > > > > * Section 4 > > > > The UAC MAY use additional information (for example the final > > response which triggered the 199 response) received in the 199 > > response when initiating new sessions, if it is possible to avoid the > > new session initiation request to be rejected. > > > > What is the meaning of the final clause? > > > > * Section 5 > > > > Add "early" as marked: > > > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > > SIP final response, as specified in [RFC3261]. In addition, prior > > to sending the non-2xx SIP final response, the UAS MAY send a 199 > > response to indicate that the dialog is being terminated. > > > > This clarifies that 199 cannot be used to terminate a confirmed > > dialog. > > > > (The reason a UAS may want to send a 199 is to provide this > > information even when the upstream proxy does not support 199.) > > > > There is a subtlty to the second sentence: > > > > Sending the 199 *before* the final response is not necessary due to > > the semantics of 199 (as it will probably reach the UAC first anyway, > > and it would not matter if it did not), but rather to prevent the > > upstream proxy from generating a 199 based on the final response, and > > then to transmit the UAS's 199 immediately after -- if the UAS sends > > the 199 first, any upstream proxy will (most likely) see the 199 > > before seeing the final response (which might induce the proxy to send > > its own 199). > > > > * Section 6 > > > > When a forking proxy receives a non-2xx final response which > > terminates one or more early dialogs and the proxy does not intend to > > forward the final response immediately (due to the rules for a > > forking proxy) it MUST send a 199 provisional response, for each > > associated early dialog that it can associate with the final > > response, upstream towards the sender of the associated request. > > > > Clarify, and note that if the proxy has already passed a 199 for an > > early dialog, it need not generate one itself. Also, I've reduced > > MUST to SHOULD, because (as the following NOTE explains), the proxy > > may not know of all early dialogs which are terminated by the final > > response. > > > > [...] it SHOULD initiate a 199 provisional response upstream > > towards the sender of the associated request, for each terminated > > early dialog, excepting those for which it has already transmitted > > a 199 response. > > > > Note that the "already transmitted 199 responses" may have come from > > downstream proxies as well as downstream UASs, so this consideration > > applies even if we do not allow UASs to send 199s. > > > > * Section 7 > > > > Since all SIP entities involved in a session setup do not necessarily > > support the specific meaning of the 199 Early Dialog Terminated > > provisional response, the sender of the response MUST be prepared to > > receive SIP requests associated with the dialog for which the 199 > > response was sent. > > > > This situation can also result due to race conditions. Amend to: > > > > Because of race conditions and because the client may not support the > > specific meaning of the 199 provisional response, the sender of the > > response MUST be prepared to receive SIP requests associated with > > the dialog for which the 199 response was sent. > > > > And add a qualifier to this sentence: > > > > If such request is received, and the receiver maintains state of > > the dialogs, the receiver MUST reply to such requests with a 481 > > final response (unless another error response is more appropriate). > > > > * Section 7 > > > > Remove "..." from this sentence and add "even" as marked: > > > > The 199 Early Dialog Terminated response code MUST NOT replace a > > final response. A final response MUST always be sent, *even* after > > one or many 199 Early Dialog Terminated provisional responses have > > been sent. > > > > * Section 8 > > > > Clarify this sentence to: > > > > The 199 Early Dialog Terminated response code allows a SIP entity > > to indicate to upstream entities that a specific early dialog has > > been terminated, before a final response reaches the upstream > > entities. > > > > Add the following: > > > > The early dialog that has been terminated is identified by the Call-Id > > header and the to-tag value of the 199 response. > > > > Future standards may define optional additional information carried > > in the headers and/or body of the response. > > > > * Section 9 > > > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > > new SDP offer/answer message body, but the sender of the response MAY > > insert a copy of a previously sent offer/answer message body as > > otherwise allowed by the offer/answer rules for a provisional > > response. > > > > This rule seems excessively strict, as it seems OK to send a new SDP > > answer in a 199, even if the dialog will be immediately terminated. > > Certainly, the UAC cannot tell the difference, as there could have > > been a previous but lost 1xx response carrying the same SDP. > > > > The interaction of 199 and SDP probably needs further study... > > > > * Section 11 > > > > Nit: Use "reject" here rather than "rejects": > > > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. > > > > Here is a modification of the example, showing how a UAS can send a > > 199, and how the proxy handles it. (You may or may not want to use > > this.) I've also added the ACK's for the 4xx's, which were missing in > > the original. > > > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > > Terminated associated with UAS_2's dialog towards the UAC. P1 > > transmits UAS_3's 199, and so does not initiate one itself for > > UAS_3's dialog when it receives UAS_3's 4xx response. > > > > UAC P1 UAS_2 UAS_3 UAS_4 > > > > --- INVITE ------> > > --- INVITE (leg 2) -> > > --- INVITE (leg 3) ----------> > > --- INVITE (leg 4) -------------------> > > <-- 18x (leg 2) ----- > > <-- 18x (leg 2) -- > > <-- 18x (leg 3) -------------- > > <-- 18x (leg 3) -- > > <-- 18x (leg 4) ----------------------- > > <-- 18x (leg 4) -- > > <-- 4xx (leg 2) ----- > > <-- 199 (leg 2) -- > > --- ACK (leg 2) ----> > > <-- 199 (leg 3) -------------- > > <-- 199 (leg 3) -- > > <-- 4xx (leg 3) -------------- > > --- ACK (leg 3) -------------> > > <-- 200 (leg 4) ----------------------- > > <-- 200 (leg 4) -- > > --- ACK (leg 4) -> > > --- ACK (leg 4) ----------------------> > > > > Dale > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > . > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 15 04:02:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D873A6972; Sun, 15 Jun 2008 04:02:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4223A6972 for ; Sun, 15 Jun 2008 04:02:28 -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.035, 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 JWcDeGRANCRZ for ; Sun, 15 Jun 2008 04:02:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8358B3A693D for ; Sun, 15 Jun 2008 04:02:26 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 779722051E; Sun, 15 Jun 2008 13:03:02 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-51-4854f6e6d3c7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 42CBB20119; Sun, 15 Jun 2008 13:03:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jun 2008 13:03:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 15 Jun 2008 13:02:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjOZoQm8yH0dgWVS3yxOJj1cwHZcQAcL+Pd References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><48527F1A.90302@cisco.com><680808427CF931459462C3D78CB5EC601CCF2C@EXVS02.nasstar-t1.net> <4854398B.7020006@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Attila Sipos" X-OriginalArrivalTime: 15 Jun 2008 11:03:14.0628 (UTC) FILETIME=[687B9840:01C8CED7] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Maybe we could talk about the case when a UAS establishes more than one dialog? Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Paul Kyzivat Sent: Sat 14/06/2008 23:35 To: Attila Sipos Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Attila, Sure we can take the approach of leaving it to the UAS to decide whether to send a 199. My concern is that it may be inefficient, not just for that UA, but for the system as a whole. So I think we need to be a little careful here. I'm not suggesting forbidding this - clearly there are cases where it is the right thing to do. Paul Attila Sipos wrote: > > >>However I am still scratching my head about the UAS sending a 199. While > >>I see no reason to forbid it I'm trying to find a situation when it > >>would be helpful. > > It may or may not be helpful but as you say, you can > see no reason to forbid it. > > Why restrict it if the restriction isn't needed? > > As someone has pointed out, a B2BUA scenario might benefit > from 199. In fact, any kind of SIP gateway might benefit. > > > This is one of those cases that could probably benefit from > > simulation to judge the merits. My gut feel is that the costs > > of the UAS sending the 199 outweigh the benefits. > > If the UAS wants to send it, that is a decision for > them - not something that needs to be prevented. > > SIP forking, in the technical sense of sending a > response with a different to-tag, is always legal. > So, any UA which has used forking > should also be able to use 199. > > I don't think we need to include any specific text about UAS > except to say that a UAS can use it if the UAS has created > the forking. > > Regards, > > Attila > > > > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Paul Kyzivat > Sent: Fri 13/06/2008 15:07 > To: Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > This all sounds like good stuff. > > However I am still scratching my head about the UAS sending a 199. While > I see no reason to forbid it I'm trying to find a situation when it > would be helpful. The only case I have been able to think of is: > > There is a forking proxy upstream of the UAS, but it doesn't > support 199. Yet it may delay the final response while it > tries other forks. So the UAS sending the 199 makes up for > the inadequacy of the forking proxy. > > The trouble with this is that it is inefficient in many cases. If each > proxy that forks also supports the sending of 199, and the UAS doesn't > send one, then we avoid sending the message except in cases where it is > helpful. If the UAS always sends it we have increased the message count > by one for all failing calls. And the majority of failing calls get no > benefit from a 199. > > This is one of those cases that could probably benefit from simulation > to judge the merits. My gut feel is that the costs of the UAS sending > the 199 outweigh the benefits. Barring some analysis to the contrary I > think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, > but without any guidance of when. > > Paul > > Dale.Worley@comcast.net wrote: > > Here are some comments on this I-D. I don't think that any of them > > modify our understanding of the proposal. I guess this is very terse; > > please use these suggestions as you see fit. > > > > * Abstract > > > > Clarify: > > > > This specification defines a new SIP response code, 199 Early > > Dialog Terminated, which a SIP entity can use to indicate upstream > > that an early dialog has been terminated. The response code can be > > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > > an early dialog has been terminated. As the 199 response is a > > provisional response, often the UAC will receive it before > > receiving a final response to its request. > > > > * Section 1 > > > > When a forking proxy receives a non-2xx final response, it does not > > always immediately forward the response upstream towards the sender > > of the associated request. Instead, the forking proxy "stores" it > > and waits for further final responses from remote destinations where > > the forked request was forwarded. > > > > The text does not allow for serial forking, only parallel forking, > > which might be confusing to people who are more aware of serial > > forking. So amend the last sentence to: > > > > Instead, the forking proxy "stores" it and waits for further final > > responses from remote destinations where the forked request was > > forwarded, and possibly forwards the request to additional > > destinations. > > > > Also, Avoid using "..." except when indicating that the word is used > > in a non-standard way or that one is discussing the word itself: > > > > Instead, the forking proxy "stores" it [...] > > > > should be: > > > > Instead, the forking proxy stores it [...] > > > > * Section 3. > > > > REQ 1: It must be possible to indicate to the UAC that an early > > dialog has been terminated before a final response is sent. > > > > Oddly, though everyone thinks they understand this sentence, it > > doesn't really say what we want. To really ensure that the UAC > > understands the early dialog has been terminated before the UAS sends > > a final response, the UAS would have to send 199 *and get the PRACK > > saying that it was received* before sending a final response. This may > > well be worse than the present state of affairs. > > > > What we really mean is: > > > > REQ 1: It must be possible for a UAS or proxy to send an indication > > to the UAC that an early dialog has been terminated, which > > indication will not be delayed waiting for a final response from > > any UAS. > > > > * Section 4 > > > > When a client receives a 199 Early Dialog Terminated provisional > > response it MAY release resources and procedures associated with the > > early dialog the 199 response is received on. > > > > Amend to clarify the meaning of 199 independently of the consequences > > of that meaning: > > > > When a client receives a 199 Early Dialog Terminated provisional > > response, it has positive knowledge that the UAS that created the > > early dialog has terminated it, and so the client MAY release > > resources and procedures associated with the early dialog for which > > the 199 response is received. > > > > * Section 4 > > > > Add this paragraph before the last paragraph: > > > > A UAC that receives a 199 response for an early dialog MUST NOT > > send any further requests on that dialog, except for a PRACK if the > > 199 response was sent reliably, and PRACKs for other reliable > > provisional responses that are to be acknowledged. > > > > This is copied from section 7 (Backward Compatibility), but since it > > is a constraint on UACs, it should also be stated in this section. > > > > * Section 4 > > > > The UAC MAY use additional information (for example the final > > response which triggered the 199 response) received in the 199 > > response when initiating new sessions, if it is possible to avoid the > > new session initiation request to be rejected. > > > > What is the meaning of the final clause? > > > > * Section 5 > > > > Add "early" as marked: > > > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > > SIP final response, as specified in [RFC3261]. In addition, prior > > to sending the non-2xx SIP final response, the UAS MAY send a 199 > > response to indicate that the dialog is being terminated. > > > > This clarifies that 199 cannot be used to terminate a confirmed > > dialog. > > > > (The reason a UAS may want to send a 199 is to provide this > > information even when the upstream proxy does not support 199.) > > > > There is a subtlty to the second sentence: > > > > Sending the 199 *before* the final response is not necessary due to > > the semantics of 199 (as it will probably reach the UAC first anyway, > > and it would not matter if it did not), but rather to prevent the > > upstream proxy from generating a 199 based on the final response, and > > then to transmit the UAS's 199 immediately after -- if the UAS sends > > the 199 first, any upstream proxy will (most likely) see the 199 > > before seeing the final response (which might induce the proxy to send > > its own 199). > > > > * Section 6 > > > > When a forking proxy receives a non-2xx final response which > > terminates one or more early dialogs and the proxy does not intend to > > forward the final response immediately (due to the rules for a > > forking proxy) it MUST send a 199 provisional response, for each > > associated early dialog that it can associate with the final > > response, upstream towards the sender of the associated request. > > > > Clarify, and note that if the proxy has already passed a 199 for an > > early dialog, it need not generate one itself. Also, I've reduced > > MUST to SHOULD, because (as the following NOTE explains), the proxy > > may not know of all early dialogs which are terminated by the final > > response. > > > > [...] it SHOULD initiate a 199 provisional response upstream > > towards the sender of the associated request, for each terminated > > early dialog, excepting those for which it has already transmitted > > a 199 response. > > > > Note that the "already transmitted 199 responses" may have come from > > downstream proxies as well as downstream UASs, so this consideration > > applies even if we do not allow UASs to send 199s. > > > > * Section 7 > > > > Since all SIP entities involved in a session setup do not necessarily > > support the specific meaning of the 199 Early Dialog Terminated > > provisional response, the sender of the response MUST be prepared to > > receive SIP requests associated with the dialog for which the 199 > > response was sent. > > > > This situation can also result due to race conditions. Amend to: > > > > Because of race conditions and because the client may not support the > > specific meaning of the 199 provisional response, the sender of the > > response MUST be prepared to receive SIP requests associated with > > the dialog for which the 199 response was sent. > > > > And add a qualifier to this sentence: > > > > If such request is received, and the receiver maintains state of > > the dialogs, the receiver MUST reply to such requests with a 481 > > final response (unless another error response is more appropriate). > > > > * Section 7 > > > > Remove "..." from this sentence and add "even" as marked: > > > > The 199 Early Dialog Terminated response code MUST NOT replace a > > final response. A final response MUST always be sent, *even* after > > one or many 199 Early Dialog Terminated provisional responses have > > been sent. > > > > * Section 8 > > > > Clarify this sentence to: > > > > The 199 Early Dialog Terminated response code allows a SIP entity > > to indicate to upstream entities that a specific early dialog has > > been terminated, before a final response reaches the upstream > > entities. > > > > Add the following: > > > > The early dialog that has been terminated is identified by the Call-Id > > header and the to-tag value of the 199 response. > > > > Future standards may define optional additional information carried > > in the headers and/or body of the response. > > > > * Section 9 > > > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > > new SDP offer/answer message body, but the sender of the response MAY > > insert a copy of a previously sent offer/answer message body as > > otherwise allowed by the offer/answer rules for a provisional > > response. > > > > This rule seems excessively strict, as it seems OK to send a new SDP > > answer in a 199, even if the dialog will be immediately terminated. > > Certainly, the UAC cannot tell the difference, as there could have > > been a previous but lost 1xx response carrying the same SDP. > > > > The interaction of 199 and SDP probably needs further study... > > > > * Section 11 > > > > Nit: Use "reject" here rather than "rejects": > > > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. > > > > Here is a modification of the example, showing how a UAS can send a > > 199, and how the proxy handles it. (You may or may not want to use > > this.) I've also added the ACK's for the 4xx's, which were missing in > > the original. > > > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > > Terminated associated with UAS_2's dialog towards the UAC. P1 > > transmits UAS_3's 199, and so does not initiate one itself for > > UAS_3's dialog when it receives UAS_3's 4xx response. > > > > UAC P1 UAS_2 UAS_3 UAS_4 > > > > --- INVITE ------> > > --- INVITE (leg 2) -> > > --- INVITE (leg 3) ----------> > > --- INVITE (leg 4) -------------------> > > <-- 18x (leg 2) ----- > > <-- 18x (leg 2) -- > > <-- 18x (leg 3) -------------- > > <-- 18x (leg 3) -- > > <-- 18x (leg 4) ----------------------- > > <-- 18x (leg 4) -- > > <-- 4xx (leg 2) ----- > > <-- 199 (leg 2) -- > > --- ACK (leg 2) ----> > > <-- 199 (leg 3) -------------- > > <-- 199 (leg 3) -- > > <-- 4xx (leg 3) -------------- > > --- ACK (leg 3) -------------> > > <-- 200 (leg 4) ----------------------- > > <-- 200 (leg 4) -- > > --- ACK (leg 4) -> > > --- ACK (leg 4) ----------------------> > > > > Dale > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > . > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 15 04:41:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4193A68A5; Sun, 15 Jun 2008 04:41:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C963A68A5 for ; Sun, 15 Jun 2008 04:41:50 -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=[AWL=-0.001, 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 fX7QIirdFFCH for ; Sun, 15 Jun 2008 04:41:49 -0700 (PDT) Received: from dlxapp2.laszlomail.com (dlxapp2.laszlomail.com [168.75.100.14]) by core3.amsl.com (Postfix) with ESMTP id A40813A687F for ; Sun, 15 Jun 2008 04:41:49 -0700 (PDT) Received: from dlxapp2 (localhost [127.0.0.1]) by dlxapp2.laszlomail.com (8.14.0/8.14.0) with ESMTP id m5FBgdho013259 for ; Sun, 15 Jun 2008 04:42:39 -0700 Received: from [116.233.144.173] by gowebtop.com with HTTP; Sun, 15 Jun 2008 04:42:36 -0700 Date: Sun, 15 Jun 2008 04:42:36 -0700 (PDT) From: Rockson Zhengyu Li To: sip@ietf.org Message-ID: <2127856552.291081213530159602.JavaMail.lzyiii@localhost> MIME-Version: 1.0 User-Agent: Laszlo Mail 2 X-Originating-IP: [116.233.144.173] Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0405690635==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0405690635== Content-Type: multipart/alternative; boundary="----=_Part_4218_1153857778.1213530156241" ------=_Part_4218_1153857778.1213530156241 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, one questions on this draft. Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog=20 creation. does this draft will normativly change the criteria, excluding 199? If, the answer is Yes, I think it need be stated explicitly in the=20 draft. thanks Regards, -Rockson On Sat, May 24, 2008 at 1:15 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working=20 Group of the IETF. =09Title=09=09: Response Code for Indication of Terminated Dialog =09Author(s)=09: C. Holmberg =09Filename=09: draft-ietf-sip-199-00.txt =09Pages=09=09: 9 =09Date=09=09: 2008-5-15 =09 This specification defines a new SIP response code, 199 Early Dialog =C2=A0=C2=A0 Terminated, which a SIP entity can use to indicate upstream th= at an =C2=A0=C2=A0 early dialog has been terminated.=C2=A0 The response code can = be used by a =C2=A0=C2=A0 SIP entity, normally a forking SIP proxy, to allow the UAC to = know =C2=A0=C2=A0 that an early dialog has been terminated before it a final res= ponse =C2=A0=C2=A0 is sent to the request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-199-00.txt=20 =C2=A0=20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/=20 =C2=A0=20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. > > ------------------------------ > > _______________________________________________ Sip mailing list=C2=A0 https://www.ietf.org/mailman/listinfo/sip=20 =C2=A0=20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu=20 =C2=A0=20 =C2=A0for questions on current si= p Use sipping@ietf.org =C2=A0=20 =C2=A0for new developments on the application of= =20 sip ------=_Part_4218_1153857778.1213530156241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,

one questions on this draft.

Since RFC3261 says, non-100 = 1xx response for INVITE cause early-dialog creation.
does this draft will normativly change the criteria, e= xcluding 199?

If, the answer is Yes, I think it need be stated explicitly in the draf= t.


thanks

Regards,
-Rockson&= nbsp;


On Sat, May 24, 2008 at  1:15 AM, Internet-Drafts= @ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Dra= fts
directories.
This draft is a work item of the Session Initi= ation Protocol Working Group of the IETF.

=09Title=09=09: Response Code for Indicatio= n of Terminated Dialog
=09Author= (s)=09: C. Holmberg
=09Filename= =09: draft-ietf-sip-199-00.txt
=09Pages=09=09: 9
=09Date=09=09= : 2008-5-15
=09
This specification defines a new SIP response co= de, 199 Early Dialog
=C2=A0=C2= =A0 Terminated, which a SIP entity can use to indicate upstream that an
=C2=A0=C2=A0 early dialog has been = terminated.=C2=A0 The response code can be used by a
=C2=A0=C2=A0 SIP entity, normally a forking SIP proxy,= to allow the UAC to know
=C2=A0= =C2=A0 that an early dialog has been terminated before it a final response<= /FONT>
=C2=A0=C2=A0 is sent to the requ= est.

A URL= for this Internet-Draft is:

Internet-Drafts= are also available by anonymous FTP at:

Below = is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASC= II version of the
Internet-Draft= .

>
> -----------------------------= -
>
> _______________________________________________
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu=C2=A0=C2=A0for questions on current sip
Use sipping@ietf.org<= A HREF=3D"mailto:sipping@ietf.org">=C2=A0=C2=A0for new developments on = the application of sip
------=_Part_4218_1153857778.1213530156241-- --===============0405690635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0405690635==-- From sip-bounces@ietf.org Sun Jun 15 04:51:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7F63A6990; Sun, 15 Jun 2008 04:51:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A84B28C0E4 for ; Sun, 15 Jun 2008 04:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 bGOqLDTGMp37 for ; Sun, 15 Jun 2008 04:51:39 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 729B03A6990 for ; Sun, 15 Jun 2008 04:51:38 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 08BAA20374; Sun, 15 Jun 2008 13:52:15 +0200 (CEST) X-AuditID: c1b4fb3e-af19abb000004ec0-d8-4855026e0de6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D52FD200B9; Sun, 15 Jun 2008 13:52:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jun 2008 13:52:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 15 Jun 2008 13:52:24 +0200 Message-ID: In-Reply-To: <2127856552.291081213530159602.JavaMail.lzyiii@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjO3Pd5YxQSavuLToeCq+kZODoatgAAS3cw References: <2127856552.291081213530159602.JavaMail.lzyiii@localhost> From: "Christer Holmberg" To: "Rockson Zhengyu Li" , X-OriginalArrivalTime: 15 Jun 2008 11:52:27.0200 (UTC) FILETIME=[485A5400:01C8CEDE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0408188065==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0408188065== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CEDE.48171AF2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CEDE.48171AF2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 You wouldn't send a 199 unless you have already sent a non-100 1xx = response, so the early dialog has already been created. =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Rockson Zhengyu Li Sent: 15. kes=E4kuuta 2008 14:43 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Hi, one questions on this draft. Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog = creation. does this draft will normativly change the criteria, excluding 199? If, the answer is Yes, I think it need be stated explicitly in the = draft. thanks Regards, -Rockson =20 On Sat, May 24, 2008 at 1:15 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Session Initiation Protocol Working = Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sip-199-00.txt Pages : 9 Date : 2008-5-15 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP entity can use to indicate upstream that an early dialog has been terminated. The response code can be used by a SIP entity, normally a forking SIP proxy, to allow the UAC to know that an early dialog has been terminated before it a final response is sent to the request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-199-00.txt = = =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ = = =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. >=20 > ------------------------------ >=20 > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip = = =20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu = = for questions on current sip Use sipping@ietf.org = for new developments on the application of = sip ------_=_NextPart_001_01C8CEDE.48171AF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
You=20 wouldn't send a 199 unless you have already sent a non-100 1xx response, = so the=20 early dialog has already been created.
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Zhengyu=20 Li
Sent: 15. kes=E4kuuta 2008 14:43
To:=20 sip@ietf.org
Subject: Re: [Sip] I-D=20 ACTION:draft-ietf-sip-199-00.txt

Hi,
one questions on this draft.
Since RFC3261 says, non-100 1xx response for INVITE = cause=20 early-dialog creation.
does this draft will normativly change the criteria, = excluding=20 199?
If, the answer is Yes, I think it need be stated = explicitly in=20 the draft.
thanks
Regards,
-Rockson 


On Sat, May 24, 2008 at  1:15 AM,=20 Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the = on-line=20 Internet-Drafts
directories.
This draft is a work item of the Session Initiation = Protocol=20 Working Group of the IETF.
Title : Response Code for Indication of Terminated=20 Dialog
Author(s) : C. Holmberg
Filename : draft-ietf-sip-199-00.txt
Pages : 9
Date : 2008-5-15
This specification defines a new SIP response code, = 199 Early=20 Dialog
   Terminated, which a SIP entity can use = to=20 indicate upstream that an
   early dialog has been terminated.  = The=20 response code can be used by a
   SIP entity, normally a forking SIP = proxy, to=20 allow the UAC to know
   that an early dialog has been = terminated before=20 it a final response
   is sent to the = request.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-199= -00.txt 
Internet-Drafts are also available by anonymous FTP=20 at:
Below is the data which will enable a MIME compliant = mail=20 reader
implementation to automatically retrieve the ASCII = version of=20 the
Internet-Draft.
>
> ------------------------------
>
>=20 _______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip 
This list is for NEW development of the core SIP=20 Protocol
Use sip-implementors@cs.c= olumbia.edu  for = questions on=20 current sip
Use sipping@ietf.org  for new developments on = the=20 application of sip
------_=_NextPart_001_01C8CEDE.48171AF2-- --===============0408188065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0408188065==-- From sip-bounces@ietf.org Sun Jun 15 18:51:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C1B3A69F1; Sun, 15 Jun 2008 18:51:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD103A6A46 for ; Sun, 15 Jun 2008 18:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 bK93gqsX35yU for ; Sun, 15 Jun 2008 18:51:37 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 3B2FB3A6A45 for ; Sun, 15 Jun 2008 18:51:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,649,1204482600"; d="scan'208,217";a="110013066" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 16 Jun 2008 07:22:13 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5G1qBQh016656; Mon, 16 Jun 2008 09:52:11 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5G1pmeH008675; Mon, 16 Jun 2008 01:52:11 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 09:51:14 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 09:51:16 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjPU3bZz9N3bh92QbWe1LDuksy1rw== From: "Rockson Li (zhengyli)" To: , X-OriginalArrivalTime: 16 Jun 2008 01:51:14.0923 (UTC) FILETIME=[76036BB0:01C8CF53] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6208; t=1213581131; x=1214445131; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-1 99-00.txt |Sender:=20; bh=xL0o5dcRtL8BVRehH4B06HZUnLvGbyJRPZ9k51PnmeA=; b=hPmf4J6s7z6fZ4zJAwkaR3rrZYbxX+xSoaxurTqi1RpPfokeLoicqmWW1F oNjJ0KxFk++KNOvoRmuDytz/bcQnZMJIs/Y2magE/W5MgpuDiBwTfmAy5/kU /0sBz+03v8Mleo0yf4cHecQNt6eXJ3t49VpQBZsQHU0fbc3LDoWss=; Authentication-Results: hkg-dkim-2; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1979160237==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1979160237== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CF53.75C933C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CF53.75C933C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, =20 It would be easier for UAS to tell if it sends non-100 1xx response creating early-dialog before sending 199. However, it's a little bit difficult from UAC's perspective, since the non-100 1xx response might not be reliable. =20 If UAC does not get , say 180, but get 199 first, it looks like it does not make any sense. =20 One option is to mandate usage of 100rel, which might be too strict for this draft. =20 Regards, -Rockson ------------------------------------------------------------------------ ------------------- Date: Sun, 15 Jun 2008 13:52:24 +0200 From: "Christer Holmberg" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt To: "Rockson Zhengyu Li" , Message-ID: =20 Content-Type: text/plain; charset=3D"iso-8859-1" =20 Hi, =20 You wouldn't send a 199 unless you have already sent a non-100 1xx response, so the early dialog has already been created. =20 Regards, =20 Christer =20 ________________________________ =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Zhengyu Li Sent: 15. kes?kuuta 2008 14:43 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt =20 Hi, =20 one questions on this draft. =20 Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog creation. does this draft will normativly change the criteria, excluding 199? =20 If, the answer is Yes, I think it need be stated explicitly in the draft. =20 =20 =20 thanks =20 Regards, -Rockson =20 =20 =20 ------_=_NextPart_001_01C8CF53.75C933C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Christer,
 
It = would be easier=20 for UAS to tell if it sends non-100 1xx response creating early-dialog = before=20 sending 199.
However, it's=20 a little bit difficult from UAC's perspective, since the non-100 = 1xx response=20 might not be reliable.
 
If UAC = does not get=20 , say 180, but get 199 first, it looks like it does not make any=20 sense.
 
One = option is to=20 mandate usage of 100rel, which might be too strict for this=20 draft.
 
Regards,
-Rockson
----------------------------------------------= ---------------------------------------------
Date: Sun, 15 Jun 2008 13:52:24 = +0200
From:=20 "Christer Holmberg" <christer.holmberg@ericsson= .com>
Subject:=20 Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt
To: "Rockson Zhengyu = Li"=20 <lzyiii@laszlomail.com>, = ;<sip@ietf.org>
Message-ID:
 = ;<CA9998CD4A020D418654FCDEF4E707DF06B19A2E@esealmw113.eemea.er= icsson.se>
 
Content-Type:=20 text/plain; charset=3D"iso-8859-1"
 
Hi,
 
You wouldn't send a = 199 unless you=20 have already sent a non-100 1xx response, so the early dialog has = already been=20 created.
 
Regards,
 
Christer
 
________________________________
 
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Zhengyu Li
Sent: = 15.=20 kes?kuuta 2008 14:43
To: sip@ietf.org
Subject: Re: [Sip] I-D=20 ACTION:draft-ietf-sip-199-00.txt
 

Hi,
 

one questions on this draft.
 

Since RFC3261 says, non-100 1xx response for INVITE cause = early-dialog=20 creation.
does this draft will normativly change the criteria, = excluding=20 199?
 

If, the answer is Yes, I think it need be stated explicitly in = the=20 draft.
 
 
 
thanks
 

Regards,
-Rockson 
 
 
------_=_NextPart_001_01C8CF53.75C933C2-- --===============1979160237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1979160237==-- From sip-bounces@ietf.org Mon Jun 16 00:32:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A793A6A09; Mon, 16 Jun 2008 00:32:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81CBF3A681A for ; Mon, 16 Jun 2008 00:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWqW2EsVj1h3 for ; Mon, 16 Jun 2008 00:32:04 -0700 (PDT) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id BA2153A6A1C for ; Mon, 16 Jun 2008 00:31:13 -0700 (PDT) X-AuditID: cb5bdd58-aa655bb000000ca4-b9-485616e1132c Received: from blr-ec-aa03.wipro.com (unknown [10.201.18.42]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id 1C72F558002 for ; Mon, 16 Jun 2008 13:01:45 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 13:01:44 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 13:01:44 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 13:01:45 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE06F5C34C@BLR-EC-MBX02.wipro.com> In-Reply-To: <680808427CF931459462C3D78CB5EC601CCF2C@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNXzah/o/xCGVESEOOeRMvhrFHbgA2G5uyAFJZJFA= References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><48527F1A.90302@cisco.com> <680808427CF931459462C3D78CB5EC601CCF2C@EXVS02.nasstar-t1.net> From: To: , X-OriginalArrivalTime: 16 Jun 2008 07:31:44.0488 (UTC) FILETIME=[06FBA680:01C8CF83] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688404396==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0688404396== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CF83.070FF872" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CF83.070FF872 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Referring to introduction part in the draft. " At some point the proxy uses a specified mechanism to determine the "best" final response code, and forwards that final response upstream towards the sender of the associated request." =20 Considering a scenario where all the forks have failed in yielding a 2xx response from different UASes (UAS2 , 3 & 4 in the diagram) with different error codes, how will the proxy determine the "best" final response and to which leg would it send the best final response. What would happen after 199 to leg 4? =20 UAC P1 UAS_2 UAS_3 UAS_4 --- INVITE ------> --- INVITE (leg 2) -> --- INVITE (leg 3) ----------> --- INVITE (leg 4) -------------------> <-- 18x (leg 2) ----- <-- 18x (leg 2) -- <-- 18x (leg 3) -------------- <-- 18x (leg 3) -- <-- 18x (leg 4) ----------------------- <-- 18x (leg 4) -- <-- 4xx (leg 2) ----- <-- 199 (leg 2) -- <-- 5xx (leg 3) -------------- <-- 199 (leg 3) -- <-- 6xx (leg 4) ----------------------- <-- 199 (leg 4) -- Best Regards,=20 Ashish Saxena=20 877-5570=20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Attila Sipos Sent: Saturday, June 14, 2008 9:30 PM To: Paul Kyzivat; Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >>However I am still scratching my head about the UAS sending a 199. While >>I see no reason to forbid it I'm trying to find a situation when it >>would be helpful. It may or may not be helpful but as you say, you can see no reason to forbid it. Why restrict it if the restriction isn't needed? As someone has pointed out, a B2BUA scenario might benefit from 199. In fact, any kind of SIP gateway might benefit. > This is one of those cases that could probably benefit from > simulation to judge the merits. My gut feel is that the costs > of the UAS sending the 199 outweigh the benefits. If the UAS wants to send it, that is a decision for them - not something that needs to be prevented. SIP forking, in the technical sense of sending a response with a different to-tag, is always legal. So, any UA which has used forking should also be able to use 199. I don't think we need to include any specific text about UAS except to say that a UAS can use it if the UAS has created the forking. Regards, Attila -----Original Message----- From: sip-bounces@ietf.org on behalf of Paul Kyzivat Sent: Fri 13/06/2008 15:07 To: Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 This all sounds like good stuff. However I am still scratching my head about the UAS sending a 199. While I see no reason to forbid it I'm trying to find a situation when it would be helpful. The only case I have been able to think of is: There is a forking proxy upstream of the UAS, but it doesn't support 199. Yet it may delay the final response while it tries other forks. So the UAS sending the 199 makes up for the inadequacy of the forking proxy. The trouble with this is that it is inefficient in many cases. If each proxy that forks also supports the sending of 199, and the UAS doesn't send one, then we avoid sending the message except in cases where it is helpful. If the UAS always sends it we have increased the message count by one for all failing calls. And the majority of failing calls get no benefit from a 199. This is one of those cases that could probably benefit from simulation to judge the merits. My gut feel is that the costs of the UAS sending the 199 outweigh the benefits. Barring some analysis to the contrary I think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, but without any guidance of when. Paul Dale.Worley@comcast.net wrote: > Here are some comments on this I-D. I don't think that any of them > modify our understanding of the proposal. I guess this is very terse; > please use these suggestions as you see fit. > > * Abstract > > Clarify: > > This specification defines a new SIP response code, 199 Early > Dialog Terminated, which a SIP entity can use to indicate upstream > that an early dialog has been terminated. The response code can be > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > an early dialog has been terminated. As the 199 response is a > provisional response, often the UAC will receive it before > receiving a final response to its request. > > * Section 1 > > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations where > the forked request was forwarded. > > The text does not allow for serial forking, only parallel forking, > which might be confusing to people who are more aware of serial > forking. So amend the last sentence to: > > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. > > Also, Avoid using "..." except when indicating that the word is used > in a non-standard way or that one is discussing the word itself: > > Instead, the forking proxy "stores" it [...] > > should be: > > Instead, the forking proxy stores it [...] > > * Section 3. > > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. > > Oddly, though everyone thinks they understand this sentence, it > doesn't really say what we want. To really ensure that the UAC > understands the early dialog has been terminated before the UAS sends > a final response, the UAS would have to send 199 *and get the PRACK > saying that it was received* before sending a final response. This may > well be worse than the present state of affairs. > > What we really mean is: > > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. > > * Section 4 > > When a client receives a 199 Early Dialog Terminated provisional > response it MAY release resources and procedures associated with the > early dialog the 199 response is received on. > > Amend to clarify the meaning of 199 independently of the consequences > of that meaning: > > When a client receives a 199 Early Dialog Terminated provisional > response, it has positive knowledge that the UAS that created the > early dialog has terminated it, and so the client MAY release > resources and procedures associated with the early dialog for which > the 199 response is received. > > * Section 4 > > Add this paragraph before the last paragraph: > > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. > > This is copied from section 7 (Backward Compatibility), but since it > is a constraint on UACs, it should also be stated in this section. > > * Section 4 > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initiation request to be rejected. > > What is the meaning of the final clause? > > * Section 5 > > Add "early" as marked: > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. > > This clarifies that 199 cannot be used to terminate a confirmed > dialog. > > (The reason a UAS may want to send a 199 is to provide this > information even when the upstream proxy does not support 199.) > > There is a subtlty to the second sentence: > > Sending the 199 *before* the final response is not necessary due to > the semantics of 199 (as it will probably reach the UAC first anyway, > and it would not matter if it did not), but rather to prevent the > upstream proxy from generating a 199 based on the final response, and > then to transmit the UAS's 199 immediately after -- if the UAS sends > the 199 first, any upstream proxy will (most likely) see the 199 > before seeing the final response (which might induce the proxy to send > its own 199). > > * Section 6 > > When a forking proxy receives a non-2xx final response which > terminates one or more early dialogs and the proxy does not intend to > forward the final response immediately (due to the rules for a > forking proxy) it MUST send a 199 provisional response, for each > associated early dialog that it can associate with the final > response, upstream towards the sender of the associated request. > > Clarify, and note that if the proxy has already passed a 199 for an > early dialog, it need not generate one itself. Also, I've reduced > MUST to SHOULD, because (as the following NOTE explains), the proxy > may not know of all early dialogs which are terminated by the final > response. > > [...] it SHOULD initiate a 199 provisional response upstream > towards the sender of the associated request, for each terminated > early dialog, excepting those for which it has already transmitted > a 199 response. > > Note that the "already transmitted 199 responses" may have come from > downstream proxies as well as downstream UASs, so this consideration > applies even if we do not allow UASs to send 199s. > > * Section 7 > > Since all SIP entities involved in a session setup do not necessarily > support the specific meaning of the 199 Early Dialog Terminated > provisional response, the sender of the response MUST be prepared to > receive SIP requests associated with the dialog for which the 199 > response was sent. > > This situation can also result due to race conditions. Amend to: > > Because of race conditions and because the client may not support the > specific meaning of the 199 provisional response, the sender of the > response MUST be prepared to receive SIP requests associated with > the dialog for which the 199 response was sent. > > And add a qualifier to this sentence: > > If such request is received, and the receiver maintains state of > the dialogs, the receiver MUST reply to such requests with a 481 > final response (unless another error response is more appropriate). > > * Section 7 > > Remove "..." from this sentence and add "even" as marked: > > The 199 Early Dialog Terminated response code MUST NOT replace a > final response. A final response MUST always be sent, *even* after > one or many 199 Early Dialog Terminated provisional responses have > been sent. > > * Section 8 > > Clarify this sentence to: > > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. > > Add the following: > > The early dialog that has been terminated is identified by the Call-Id > header and the to-tag value of the 199 response. > > Future standards may define optional additional information carried > in the headers and/or body of the response. > > * Section 9 > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > > This rule seems excessively strict, as it seems OK to send a new SDP > answer in a 199, even if the dialog will be immediately terminated. > Certainly, the UAC cannot tell the difference, as there could have > been a previous but lost 1xx response carrying the same SDP. > > The interaction of 199 and SDP probably needs further study... > > * Section 11 > > Nit: Use "reject" here rather than "rejects": > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. > > Here is a modification of the example, showing how a UAS can send a > 199, and how the proxy handles it. (You may or may not want to use > this.) I've also added the ACK's for the 4xx's, which were missing in > the original. > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > Terminated associated with UAS_2's dialog towards the UAC. P1 > transmits UAS_3's 199, and so does not initiate one itself for > UAS_3's dialog when it receives UAS_3's 4xx response. > > UAC P1 UAS_2 UAS_3 UAS_4 > > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > --- ACK (leg 2) ----> > <-- 199 (leg 3) -------------- > <-- 199 (leg 3) -- > <-- 4xx (leg 3) -------------- > --- ACK (leg 3) -------------> > <-- 200 (leg 4) ----------------------- > <-- 200 (leg 4) -- > --- ACK (leg 4) -> > --- ACK (leg 4) ----------------------> > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip . ------_=_NextPart_001_01C8CF83.070FF872 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] Draft submission: = draft-ietf-sip-199-00
Referring to introduction part in the = draft.
   " At some point = the proxy=20 uses a specified mechanism to determine the "best" final response = code,=20 and forwards that final response upstream towards the sender of=20 the associated request."
 
Considering a scenario where all the forks have failed in = yielding a 2xx=20 response from different UASes (UAS2 , 3 & 4 in the diagram) with = different=20 error codes, how will the proxy determine the "best" final response and = to which=20 leg would it send the best final response. What would happen after 199 = to leg=20 4?
 
     =20 UAC           &nbs= p;  =20 P1            = ;     =20 UAS_2    UAS_3   =20 UAS_4

       --- INVITE=20 ------>
          = ;            =   =20 --- INVITE (leg 2)=20 ->
          &nbs= p;            = ; =20 --- INVITE (leg 3)=20 ---------->
         &= nbsp;           &n= bsp;  =20 --- INVITE (leg 4)=20 ------------------->
       &nbs= p;            = ;    =20 <-- 18x (leg 2) -----
       <-- = 18x (leg=20 2)=20 --
           &= nbsp;           &n= bsp;=20 <-- 18x (leg 3) = --------------
       <--=20 18x (leg 3)=20 --
           &= nbsp;           &n= bsp;=20 <-- 18x (leg 4)=20 -----------------------
       <-- = 18x (leg=20 4)=20 --
           &= nbsp;           &n= bsp;=20 <-- 4xx (leg 2)=20 -----
       <-- 199 (leg 2)=20 --
           &= nbsp;           &n= bsp;=20 <-- 5xx (leg 3)=20 --------------
       <-- 199 (leg = 3)=20 --
           &= nbsp;           &n= bsp;=20 <-- 6xx (leg 4)=20 -----------------------
       = <-- 199=20 (leg 4) --

Best = Regards,
Ashish Saxena
877-5570

 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Attila = Sipos
Sent:=20 Saturday, June 14, 2008 9:30 PM
To: Paul Kyzivat;=20 Dale.Worley@comcast.net
Cc: sip@ietf.org
Subject: = Re: [Sip]=20 Draft submission: draft-ietf-sip-199-00


>>However I am still scratching my head about = the UAS=20 sending a 199. While
>>I see no reason to forbid it I'm trying = to find=20 a situation when it
>>would be helpful.

It may or may = not be=20 helpful but as you say, you can
see no reason to forbid = it.

Why=20 restrict it if the restriction isn't needed?

As someone has = pointed out,=20 a B2BUA scenario might benefit
from 199.  In fact, any kind of = SIP=20 gateway might benefit.

> This is one of those cases that could = probably benefit from
> simulation to judge the merits. My gut = feel is=20 that the costs
> of the UAS sending the 199 outweigh the=20 benefits.

If the UAS wants to send it, that is a decision = for
them -=20 not something that needs to be prevented.

SIP forking, in the = technical=20 sense of sending a
response with a different to-tag, is always = legal.
So,=20 any UA which has used forking
should also be able to use = 199.

I don't=20 think we need to include any specific text about UAS
except to say = that a UAS=20 can use it if the UAS has created
the=20 forking.

Regards,

Attila



-----Original=20 Message-----
From: sip-bounces@ietf.org on behalf of Paul = Kyzivat
Sent:=20 Fri 13/06/2008 15:07
To: Dale.Worley@comcast.net
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Draft submission:=20 draft-ietf-sip-199-00

This all sounds like good = stuff.

However I=20 am still scratching my head about the UAS sending a 199. While
I see = no=20 reason to forbid it I'm trying to find a situation when it
would be = helpful.=20 The only case I have been able to think of is:

   There = is a=20 forking proxy upstream of the UAS, but it doesn't
   = support 199.=20 Yet it may delay the final response while it
   tries other = forks.=20 So the UAS sending the 199 makes up for
   the inadequacy = of the=20 forking proxy.

The trouble with this is that it is inefficient in = many=20 cases. If each
proxy that forks also supports the sending of 199, and = the UAS=20 doesn't
send one, then we avoid sending the message except in cases = where it=20 is
helpful. If the UAS always sends it we have increased the message=20 count
by one for all failing calls. And the majority of failing calls = get=20 no
benefit from a 199.

This is one of those cases that could = probably=20 benefit from simulation
to judge the merits. My gut feel is that the = costs of=20 the UAS sending
the 199 outweigh the benefits. Barring some analysis = to the=20 contrary I
think I would say that a UAS SHOULD NOT send a 199. Or = perhaps MAY=20 send,
but without any guidance of=20 when.

       =20 Paul

Dale.Worley@comcast.net wrote:
> Here are some = comments on=20 this I-D.  I don't think that any of them
> modify our = understanding=20 of the proposal.  I guess this is very terse;
> please use = these=20 suggestions as you see fit.
>
> * Abstract
>
>=20 Clarify:
>
>    This specification defines a = new SIP=20 response code, 199 Early
>    Dialog Terminated, = which a=20 SIP entity can use to indicate upstream
>    that = an early=20 dialog has been terminated.  The response code can=20 be
>    used by a SIP entity (a SIP proxy or UAS), = to=20 inform the UAC that
>    an early dialog has been=20 terminated.  As the 199 response is a
>    = provisional=20 response, often the UAC will receive it before
>    = receiving a final response to its request.
>
> * Section=20 1
>
>    When a forking proxy receives a = non-2xx=20 final response, it does not
>    always immediately = forward=20 the response upstream towards the sender
>    of = the=20 associated request.  Instead, the forking proxy "stores"=20 it
>    and waits for further final responses from = remote=20 destinations where
>    the forked request was=20 forwarded.
>
> The text does not allow for serial forking, = only=20 parallel forking,
> which might be confusing to people who are = more aware=20 of serial
> forking.  So amend the last sentence=20 to:
>
>    Instead, the forking proxy = "stores" it and=20 waits for further final
>    responses from remote=20 destinations where the forked request was
>    = forwarded,=20 and possibly forwards the request to = additional
>   =20 destinations.
>
> Also, Avoid using "..." except when = indicating=20 that the word is used
> in a non-standard way or that one is = discussing=20 the word itself:
>
>    Instead, the forking = proxy=20 "stores" it [...]
>
> should = be:
>
>   =20 Instead, the forking proxy stores it [...]
>
> * Section=20 3.
>
>    REQ 1: It must be possible to = indicate to=20 the UAC that an early
>    dialog has been = terminated=20 before a final response is sent.
>
> Oddly, though everyone = thinks=20 they understand this sentence, it
> doesn't really say what we = want. =20 To really ensure that the UAC
> understands the early dialog has = been=20 terminated before the UAS sends
> a final response, the UAS would = have to=20 send 199 *and get the PRACK
> saying that it was received* before = sending=20 a final response.  This may
> well be worse than the present = state of=20 affairs.
>
> What we really mean=20 is:
>
>    REQ 1: It must be possible for a = UAS or=20 proxy to send an indication
>    to the UAC that an = early=20 dialog has been terminated, which
>    indication = will not=20 be delayed waiting for a final response from
>    = any=20 UAS.
>
> * Section 4
>
>    When = a client=20 receives a 199 Early Dialog Terminated = provisional
>   =20 response it MAY release resources and procedures associated with=20 the
>    early dialog the 199 response is received=20 on.
>
> Amend to clarify the meaning of 199 independently of = the=20 consequences
> of that meaning:
>
>    = When a=20 client receives a 199 Early Dialog Terminated=20 provisional
>    response, it has positive = knowledge that=20 the UAS that created the
>    early dialog has = terminated=20 it, and so the client MAY release
>    resources = and=20 procedures associated with the early dialog for = which
>   =20 the 199 response is received.
>
> * Section = 4
>
> Add=20 this paragraph before the last = paragraph:
>
>    A=20 UAC that receives a 199 response for an early dialog MUST=20 NOT
>    send any further requests on that dialog, = except=20 for a PRACK if the
>    199 response was sent = reliably, and=20 PRACKs for other reliable
>    provisional = responses that=20 are to be acknowledged.
>
> This is copied from section 7 = (Backward=20 Compatibility), but since it
> is a constraint on UACs, it should = also be=20 stated in this section.
>
> * Section=20 4
>
>    The UAC MAY use additional = information (for=20 example the final
>    response which triggered the = 199=20 response) received in the 199
>    response when = initiating=20 new sessions, if it is possible to avoid the
>    = new=20 session initiation request to be rejected.
>
> What is the = meaning=20 of the final clause?
>
> * Section 5
>
> Add = "early" as=20 marked:
>
>    When a UAS wants to terminate = *an=20 early* dialog it sends a non-2xx
>    SIP final = response,=20 as specified in [RFC3261].  In addition, = prior
>    to=20 sending the non-2xx SIP final response, the UAS MAY send a=20 199
>    response to indicate that the dialog is = being=20 terminated.
>
> This clarifies that 199 cannot be used to = terminate=20 a confirmed
> dialog.
>
> (The reason a UAS may want = to send a=20 199 is to provide this
> information even when the upstream proxy = does not=20 support 199.)
>
> There is a subtlty to the second=20 sentence:
>
> Sending the 199 *before* the final response is = not=20 necessary due to
> the semantics of 199 (as it will probably reach = the UAC=20 first anyway,
> and it would not matter if it did not), but rather = to=20 prevent the
> upstream proxy from generating a 199 based on the = final=20 response, and
> then to transmit the UAS's 199 immediately after = -- if the=20 UAS sends
> the 199 first, any upstream proxy will (most likely) = see the=20 199
> before seeing the final response (which might induce the = proxy to=20 send
> its own 199).
>
> * Section=20 6
>
>    When a forking proxy receives a = non-2xx=20 final response which
>    terminates one or more = early=20 dialogs and the proxy does not intend to
>    = forward the=20 final response immediately (due to the rules for = a
>   =20 forking proxy) it MUST send a 199 provisional response, for=20 each
>    associated early dialog that it can = associate=20 with the final
>    response, upstream towards the = sender=20 of the associated request.
>
> Clarify, and note that if the = proxy=20 has already passed a 199 for an
> early dialog, it need not = generate one=20 itself.  Also, I've reduced
> MUST to SHOULD, because (as the = following NOTE explains), the proxy
> may not know of all early = dialogs=20 which are terminated by the final
>=20 response.
>
>    [...] it SHOULD initiate a = 199=20 provisional response upstream
>    towards the = sender of=20 the associated request, for each terminated
>    = early=20 dialog, excepting those for which it has already=20 transmitted
>    a 199 response.
>
> = Note that=20 the "already transmitted 199 responses" may have come from
> = downstream=20 proxies as well as downstream UASs, so this consideration
> = applies even=20 if we do not allow UASs to send 199s.
>
> * Section=20 7
>
>    Since all SIP entities involved in a = session=20 setup do not necessarily
>    support the specific = meaning=20 of the 199 Early Dialog Terminated
>    provisional = response, the sender of the response MUST be prepared=20 to
>    receive SIP requests associated with the = dialog for=20 which the 199
>    response was = sent.
>
> This=20 situation can also result due to race conditions.  Amend=20 to:
>
>    Because of race conditions and = because the=20 client may not support the
>    specific meaning of = the 199=20 provisional response, the sender of the
>    = response MUST=20 be prepared to receive SIP requests associated = with
>   =20 the dialog for which the 199 response was sent.
>
> And add = a=20 qualifier to this sentence:
>
>    If such = request is=20 received, and the receiver maintains state of
>    = the=20 dialogs, the receiver MUST reply to such requests with a=20 481
>    final response (unless another error = response is=20 more appropriate).
>
> * Section 7
>
> Remove = "..." from=20 this sentence and add "even" as = marked:
>
>    The=20 199 Early Dialog Terminated response code MUST NOT replace=20 a
>    final response.  A final response MUST = always=20 be sent, *even* after
>    one or many 199 Early = Dialog=20 Terminated provisional responses have
>    been=20 sent.
>
> * Section 8
>
> Clarify this sentence=20 to:
>
>    The 199 Early Dialog Terminated = response=20 code allows a SIP entity
>    to indicate to = upstream=20 entities that a specific early dialog has
>    been = terminated, before a final response reaches the=20 upstream
>    entities.
>
> Add the=20 following:
>
>    The early dialog that has = been=20 terminated is identified by the Call-Id
>    header = and the=20 to-tag value of the 199 response.
>
>    = Future=20 standards may define optional additional information=20 carried
>    in the headers and/or body of the=20 response.
>
> * Section 9
>
>    = A 199=20 Early Dialog Terminated provisional response MUST NOT contain=20 a
>    new SDP offer/answer message body, but the = sender of=20 the response MAY
>    insert a copy of a previously = sent=20 offer/answer message body as
>    otherwise allowed = by the=20 offer/answer rules for a provisional
>   =20 response.
>
> This rule seems excessively strict, as it = seems OK to=20 send a new SDP
> answer in a 199, even if the dialog will be = immediately=20 terminated.
> Certainly, the UAC cannot tell the difference, as = there=20 could have
> been a previous but lost 1xx response carrying the = same=20 SDP.
>
> The interaction of 199 and SDP probably needs = further=20 study...
>
> * Section 11
>
> Nit:  Use = "reject"=20 here rather than "rejects":
>
>    UAS_2 and = UAS_3=20 *reject* the INVITE by sending a 4xx error response.
>
> = Here is a=20 modification of the example, showing how a UAS can send a
> 199, = and how=20 the proxy handles it.  (You may or may not want to use
> = this.) =20 I've also added the ACK's for the 4xx's, which were missing in
> = the=20 original.
>
>    [...] UAS_2 and UAS_3 reject = the=20 INVITE by sending a 4xx error
>    response.  = UAS_3=20 sends a 199 with its 4xx.  When P1 receives = the
>   =20 4xx response from UAS_2 it immediately sends a 199 Early=20 Dialog
>    Terminated associated with UAS_2's = dialog=20 towards the UAC.  P1
>    transmits UAS_3's = 199, and=20 so does not initiate one itself for
>    UAS_3's = dialog=20 when it receives UAS_3's 4xx=20 response.
>
>      =20 UAC           &nbs= p;  =20 P1            = ;     =20 UAS_2    UAS_3   =20 UAS_4
>
>        --- = INVITE=20 ------>
>         &= nbsp;           &n= bsp;   =20 --- INVITE (leg 2)=20 ->
>          =             &= nbsp;  =20 --- INVITE (leg 3)=20 ---------->
>        &nb= sp;           &nbs= p;    =20 --- INVITE (leg 4)=20 ------------------->
>       =             &= nbsp;     =20 <-- 18x (leg 2) = -----
>       =20 <-- 18x (leg 2)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 18x (leg 3)=20 --------------
>        <-- = 18x (leg=20 3)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 18x (leg 4)=20 -----------------------
>       = <--=20 18x (leg 4)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 4xx (leg 2) = -----
>       =20 <-- 199 (leg 2)=20 --
>          &nb= sp;           &nbs= p;  =20 --- ACK (leg 2)=20 ---->
>         &nb= sp;           &nbs= p;   =20 <-- 199 (leg 3)=20 --------------
>        <-- = 199 (leg=20 3)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 4xx (leg 3)=20 --------------
>        &nb= sp;           &nbs= p;    =20 --- ACK (leg 3)=20 ------------->
>        =             &= nbsp;    =20 <-- 200 (leg 4)=20 -----------------------
>       = <--=20 200 (leg 4) --
>        --- ACK = (leg 4)=20 ->
>          =             &= nbsp;  =20 --- ACK (leg 4) ---------------------->
>
> Dale
>=20 _______________________________________________
> Sip mailing = list =20 https://www.ietf.org/m= ailman/listinfo/sip
>=20 This list is for NEW development of the core SIP Protocol
> Use=20 sip-implementors@cs.columbia.edu for questions on current sip
> = Use=20 sipping@ietf.org for new developments on the application of=20 sip
>
_______________________________________________
Sip = mailing=20 list  https://www.ietf.org/m= ailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip



.

------_=_NextPart_001_01C8CF83.070FF872-- --===============0688404396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0688404396==-- From sip-bounces@ietf.org Mon Jun 16 01:10:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAA63A67FD; Mon, 16 Jun 2008 01:10:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440913A698F for ; Mon, 16 Jun 2008 01:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.281 X-Spam-Level: X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 ixBzpLtXkLat for ; Mon, 16 Jun 2008 01:10:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BC6C73A6778 for ; Mon, 16 Jun 2008 01:10:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 13D7D204AD; Mon, 16 Jun 2008 10:11:24 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-64-4856202b4371 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D215B204E6; Mon, 16 Jun 2008 10:11:23 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:11:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 10:11:36 +0200 Message-ID: In-Reply-To: <01949ABCDD38EF4A95B8C347C399D1CE06F5C34C@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNXzah/o/xCGVESEOOeRMvhrFHbgA2G5uyAFJZJFAAAcDC8A== References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><48527F1A.90302@cisco.com><680808427CF931459462C3D78CB5EC601CCF2C@EXVS02.nasstar-t1.net> <01949ABCDD38EF4A95B8C347C399D1CE06F5C34C@BLR-EC-MBX02.wipro.com> From: "Christer Holmberg" To: , , X-OriginalArrivalTime: 16 Jun 2008 08:11:37.0376 (UTC) FILETIME=[99416200:01C8CF88] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2045265131==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2045265131== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CF88.98F3BD26" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CF88.98F3BD26 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 The way the "best" final response code is chosen is described in RFC = 3261, and the intention of 199 is not to change that. =20 Regarding whether a 199 will be sent for leg 4: if the proxy is now = going to send a "best" final response I guess it doesn't need to send = 199 for leg 4. =20 Regards, =20 Christer =20 =20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = ashish.hsaxena@wipro.com Sent: 16. kes=E4kuuta 2008 10:32 To: pkyzivat@cisco.com; Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Referring to introduction part in the draft. " At some point the proxy uses a specified mechanism to determine the = "best" final response code, and forwards that final response upstream = towards the sender of the associated request." =20 Considering a scenario where all the forks have failed in yielding a 2xx = response from different UASes (UAS2 , 3 & 4 in the diagram) with = different error codes, how will the proxy determine the "best" final = response and to which leg would it send the best final response. What = would happen after 199 to leg 4? =20 UAC P1 UAS_2 UAS_3 UAS_4 --- INVITE ------> --- INVITE (leg 2) -> --- INVITE (leg 3) ----------> --- INVITE (leg 4) -------------------> <-- 18x (leg 2) ----- <-- 18x (leg 2) -- <-- 18x (leg 3) -------------- <-- 18x (leg 3) -- <-- 18x (leg 4) ----------------------- <-- 18x (leg 4) -- <-- 4xx (leg 2) ----- <-- 199 (leg 2) -- <-- 5xx (leg 3) -------------- <-- 199 (leg 3) -- <-- 6xx (leg 4) ----------------------- <-- 199 (leg 4) -- Best Regards,=20 Ashish Saxena=20 877-5570=20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Attila Sipos Sent: Saturday, June 14, 2008 9:30 PM To: Paul Kyzivat; Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >>However I am still scratching my head about the UAS sending a 199. = While >>I see no reason to forbid it I'm trying to find a situation when it >>would be helpful. It may or may not be helpful but as you say, you can see no reason to forbid it. Why restrict it if the restriction isn't needed? As someone has pointed out, a B2BUA scenario might benefit from 199. In fact, any kind of SIP gateway might benefit. > This is one of those cases that could probably benefit from > simulation to judge the merits. My gut feel is that the costs > of the UAS sending the 199 outweigh the benefits. If the UAS wants to send it, that is a decision for them - not something that needs to be prevented. SIP forking, in the technical sense of sending a response with a different to-tag, is always legal. So, any UA which has used forking should also be able to use 199. I don't think we need to include any specific text about UAS except to say that a UAS can use it if the UAS has created the forking. Regards, Attila -----Original Message----- From: sip-bounces@ietf.org on behalf of Paul Kyzivat Sent: Fri 13/06/2008 15:07 To: Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 This all sounds like good stuff. However I am still scratching my head about the UAS sending a 199. While I see no reason to forbid it I'm trying to find a situation when it would be helpful. The only case I have been able to think of is: There is a forking proxy upstream of the UAS, but it doesn't support 199. Yet it may delay the final response while it tries other forks. So the UAS sending the 199 makes up for the inadequacy of the forking proxy. The trouble with this is that it is inefficient in many cases. If each proxy that forks also supports the sending of 199, and the UAS doesn't send one, then we avoid sending the message except in cases where it is helpful. If the UAS always sends it we have increased the message count by one for all failing calls. And the majority of failing calls get no benefit from a 199. This is one of those cases that could probably benefit from simulation to judge the merits. My gut feel is that the costs of the UAS sending the 199 outweigh the benefits. Barring some analysis to the contrary I think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, but without any guidance of when. Paul Dale.Worley@comcast.net wrote: > Here are some comments on this I-D. I don't think that any of them > modify our understanding of the proposal. I guess this is very terse; > please use these suggestions as you see fit. > > * Abstract > > Clarify: > > This specification defines a new SIP response code, 199 Early > Dialog Terminated, which a SIP entity can use to indicate upstream > that an early dialog has been terminated. The response code can be > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > an early dialog has been terminated. As the 199 response is a > provisional response, often the UAC will receive it before > receiving a final response to its request. > > * Section 1 > > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations = where > the forked request was forwarded. > > The text does not allow for serial forking, only parallel forking, > which might be confusing to people who are more aware of serial > forking. So amend the last sentence to: > > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. > > Also, Avoid using "..." except when indicating that the word is used > in a non-standard way or that one is discussing the word itself: > > Instead, the forking proxy "stores" it [...] > > should be: > > Instead, the forking proxy stores it [...] > > * Section 3. > > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. > > Oddly, though everyone thinks they understand this sentence, it > doesn't really say what we want. To really ensure that the UAC > understands the early dialog has been terminated before the UAS sends > a final response, the UAS would have to send 199 *and get the PRACK > saying that it was received* before sending a final response. This = may > well be worse than the present state of affairs. > > What we really mean is: > > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. > > * Section 4 > > When a client receives a 199 Early Dialog Terminated provisional > response it MAY release resources and procedures associated with = the > early dialog the 199 response is received on. > > Amend to clarify the meaning of 199 independently of the consequences > of that meaning: > > When a client receives a 199 Early Dialog Terminated provisional > response, it has positive knowledge that the UAS that created the > early dialog has terminated it, and so the client MAY release > resources and procedures associated with the early dialog for which > the 199 response is received. > > * Section 4 > > Add this paragraph before the last paragraph: > > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. > > This is copied from section 7 (Backward Compatibility), but since it > is a constraint on UACs, it should also be stated in this section. > > * Section 4 > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid = the > new session initiation request to be rejected. > > What is the meaning of the final clause? > > * Section 5 > > Add "early" as marked: > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. > > This clarifies that 199 cannot be used to terminate a confirmed > dialog. > > (The reason a UAS may want to send a 199 is to provide this > information even when the upstream proxy does not support 199.) > > There is a subtlty to the second sentence: > > Sending the 199 *before* the final response is not necessary due to > the semantics of 199 (as it will probably reach the UAC first anyway, > and it would not matter if it did not), but rather to prevent the > upstream proxy from generating a 199 based on the final response, and > then to transmit the UAS's 199 immediately after -- if the UAS sends > the 199 first, any upstream proxy will (most likely) see the 199 > before seeing the final response (which might induce the proxy to send > its own 199). > > * Section 6 > > When a forking proxy receives a non-2xx final response which > terminates one or more early dialogs and the proxy does not intend = to > forward the final response immediately (due to the rules for a > forking proxy) it MUST send a 199 provisional response, for each > associated early dialog that it can associate with the final > response, upstream towards the sender of the associated request. > > Clarify, and note that if the proxy has already passed a 199 for an > early dialog, it need not generate one itself. Also, I've reduced > MUST to SHOULD, because (as the following NOTE explains), the proxy > may not know of all early dialogs which are terminated by the final > response. > > [...] it SHOULD initiate a 199 provisional response upstream > towards the sender of the associated request, for each terminated > early dialog, excepting those for which it has already transmitted > a 199 response. > > Note that the "already transmitted 199 responses" may have come from > downstream proxies as well as downstream UASs, so this consideration > applies even if we do not allow UASs to send 199s. > > * Section 7 > > Since all SIP entities involved in a session setup do not = necessarily > support the specific meaning of the 199 Early Dialog Terminated > provisional response, the sender of the response MUST be prepared = to > receive SIP requests associated with the dialog for which the 199 > response was sent. > > This situation can also result due to race conditions. Amend to: > > Because of race conditions and because the client may not support = the > specific meaning of the 199 provisional response, the sender of the > response MUST be prepared to receive SIP requests associated with > the dialog for which the 199 response was sent. > > And add a qualifier to this sentence: > > If such request is received, and the receiver maintains state of > the dialogs, the receiver MUST reply to such requests with a 481 > final response (unless another error response is more appropriate). > > * Section 7 > > Remove "..." from this sentence and add "even" as marked: > > The 199 Early Dialog Terminated response code MUST NOT replace a > final response. A final response MUST always be sent, *even* after > one or many 199 Early Dialog Terminated provisional responses have > been sent. > > * Section 8 > > Clarify this sentence to: > > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. > > Add the following: > > The early dialog that has been terminated is identified by the = Call-Id > header and the to-tag value of the 199 response. > > Future standards may define optional additional information carried > in the headers and/or body of the response. > > * Section 9 > > A 199 Early Dialog Terminated provisional response MUST NOT contain = a > new SDP offer/answer message body, but the sender of the response = MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > > This rule seems excessively strict, as it seems OK to send a new SDP > answer in a 199, even if the dialog will be immediately terminated. > Certainly, the UAC cannot tell the difference, as there could have > been a previous but lost 1xx response carrying the same SDP. > > The interaction of 199 and SDP probably needs further study... > > * Section 11 > > Nit: Use "reject" here rather than "rejects": > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error = response. > > Here is a modification of the example, showing how a UAS can send a > 199, and how the proxy handles it. (You may or may not want to use > this.) I've also added the ACK's for the 4xx's, which were missing in > the original. > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > Terminated associated with UAS_2's dialog towards the UAC. P1 > transmits UAS_3's 199, and so does not initiate one itself for > UAS_3's dialog when it receives UAS_3's 4xx response. > > UAC P1 UAS_2 UAS_3 UAS_4 > > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > --- ACK (leg 2) ----> > <-- 199 (leg 3) -------------- > <-- 199 (leg 3) -- > <-- 4xx (leg 3) -------------- > --- ACK (leg 3) -------------> > <-- 200 (leg 4) ----------------------- > <-- 200 (leg 4) -- > --- ACK (leg 4) -> > --- ACK (leg 4) ----------------------> > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip . ------_=_NextPart_001_01C8CF88.98F3BD26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Draft submission: = draft-ietf-sip-199-00
 
Hi,
 
The=20 way the "best" final response code is chosen is described in RFC 3261, = and the=20 intention of 199 is not to change that.
 
Regarding whether a 199 will be sent for leg = 4: if the=20 proxy is now going to send a "best" final response I guess it doesn't = need to=20 send 199 for leg 4.
 
Regards,
 
Christer
 
 
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of=20 ashish.hsaxena@wipro.com
Sent: 16. kes=E4kuuta 2008=20 10:32
To: pkyzivat@cisco.com; = Dale.Worley@comcast.net
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Draft submission:=20 draft-ietf-sip-199-00

Referring to introduction part in the = draft.
   " At some point = the proxy=20 uses a specified mechanism to determine the "best" final response = code,=20 and forwards that final response upstream towards the sender of=20 the associated request."
 
Considering a scenario where all the forks have failed in = yielding a 2xx=20 response from different UASes (UAS2 , 3 & 4 in the diagram) with = different=20 error codes, how will the proxy determine the "best" final response and = to which=20 leg would it send the best final response. What would happen after 199 = to leg=20 4?
 
     =20 UAC           &nbs= p;  =20 P1            = ;     =20 UAS_2    UAS_3   =20 UAS_4

       --- INVITE=20 ------>
          = ;            =   =20 --- INVITE (leg 2)=20 ->
          &nbs= p;            = ; =20 --- INVITE (leg 3)=20 ---------->
         &= nbsp;           &n= bsp;  =20 --- INVITE (leg 4)=20 ------------------->
       &nbs= p;            = ;    =20 <-- 18x (leg 2) -----
       <-- = 18x (leg=20 2)=20 --
           &= nbsp;           &n= bsp;=20 <-- 18x (leg 3) = --------------
       <--=20 18x (leg 3)=20 --
           &= nbsp;           &n= bsp;=20 <-- 18x (leg 4)=20 -----------------------
       <-- = 18x (leg=20 4)=20 --
           &= nbsp;           &n= bsp;=20 <-- 4xx (leg 2)=20 -----
       <-- 199 (leg 2)=20 --
           &= nbsp;           &n= bsp;=20 <-- 5xx (leg 3)=20 --------------
       <-- 199 (leg = 3)=20 --
           &= nbsp;           &n= bsp;=20 <-- 6xx (leg 4)=20 -----------------------
       = <-- 199=20 (leg 4) --

Best = Regards,
Ashish Saxena
877-5570

 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Attila = Sipos
Sent:=20 Saturday, June 14, 2008 9:30 PM
To: Paul Kyzivat;=20 Dale.Worley@comcast.net
Cc: sip@ietf.org
Subject: = Re: [Sip]=20 Draft submission: draft-ietf-sip-199-00


>>However I am still scratching my head about = the UAS=20 sending a 199. While
>>I see no reason to forbid it I'm trying = to find=20 a situation when it
>>would be helpful.

It may or may = not be=20 helpful but as you say, you can
see no reason to forbid = it.

Why=20 restrict it if the restriction isn't needed?

As someone has = pointed out,=20 a B2BUA scenario might benefit
from 199.  In fact, any kind of = SIP=20 gateway might benefit.

> This is one of those cases that could = probably benefit from
> simulation to judge the merits. My gut = feel is=20 that the costs
> of the UAS sending the 199 outweigh the=20 benefits.

If the UAS wants to send it, that is a decision = for
them -=20 not something that needs to be prevented.

SIP forking, in the = technical=20 sense of sending a
response with a different to-tag, is always = legal.
So,=20 any UA which has used forking
should also be able to use = 199.

I don't=20 think we need to include any specific text about UAS
except to say = that a UAS=20 can use it if the UAS has created
the=20 forking.

Regards,

Attila



-----Original=20 Message-----
From: sip-bounces@ietf.org on behalf of Paul = Kyzivat
Sent:=20 Fri 13/06/2008 15:07
To: Dale.Worley@comcast.net
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Draft submission:=20 draft-ietf-sip-199-00

This all sounds like good = stuff.

However I=20 am still scratching my head about the UAS sending a 199. While
I see = no=20 reason to forbid it I'm trying to find a situation when it
would be = helpful.=20 The only case I have been able to think of is:

   There = is a=20 forking proxy upstream of the UAS, but it doesn't
   = support 199.=20 Yet it may delay the final response while it
   tries other = forks.=20 So the UAS sending the 199 makes up for
   the inadequacy = of the=20 forking proxy.

The trouble with this is that it is inefficient in = many=20 cases. If each
proxy that forks also supports the sending of 199, and = the UAS=20 doesn't
send one, then we avoid sending the message except in cases = where it=20 is
helpful. If the UAS always sends it we have increased the message=20 count
by one for all failing calls. And the majority of failing calls = get=20 no
benefit from a 199.

This is one of those cases that could = probably=20 benefit from simulation
to judge the merits. My gut feel is that the = costs of=20 the UAS sending
the 199 outweigh the benefits. Barring some analysis = to the=20 contrary I
think I would say that a UAS SHOULD NOT send a 199. Or = perhaps MAY=20 send,
but without any guidance of=20 when.

       =20 Paul

Dale.Worley@comcast.net wrote:
> Here are some = comments on=20 this I-D.  I don't think that any of them
> modify our = understanding=20 of the proposal.  I guess this is very terse;
> please use = these=20 suggestions as you see fit.
>
> * Abstract
>
>=20 Clarify:
>
>    This specification defines a = new SIP=20 response code, 199 Early
>    Dialog Terminated, = which a=20 SIP entity can use to indicate upstream
>    that = an early=20 dialog has been terminated.  The response code can=20 be
>    used by a SIP entity (a SIP proxy or UAS), = to=20 inform the UAC that
>    an early dialog has been=20 terminated.  As the 199 response is a
>    = provisional=20 response, often the UAC will receive it before
>    = receiving a final response to its request.
>
> * Section=20 1
>
>    When a forking proxy receives a = non-2xx=20 final response, it does not
>    always immediately = forward=20 the response upstream towards the sender
>    of = the=20 associated request.  Instead, the forking proxy "stores"=20 it
>    and waits for further final responses from = remote=20 destinations where
>    the forked request was=20 forwarded.
>
> The text does not allow for serial forking, = only=20 parallel forking,
> which might be confusing to people who are = more aware=20 of serial
> forking.  So amend the last sentence=20 to:
>
>    Instead, the forking proxy = "stores" it and=20 waits for further final
>    responses from remote=20 destinations where the forked request was
>    = forwarded,=20 and possibly forwards the request to = additional
>   =20 destinations.
>
> Also, Avoid using "..." except when = indicating=20 that the word is used
> in a non-standard way or that one is = discussing=20 the word itself:
>
>    Instead, the forking = proxy=20 "stores" it [...]
>
> should = be:
>
>   =20 Instead, the forking proxy stores it [...]
>
> * Section=20 3.
>
>    REQ 1: It must be possible to = indicate to=20 the UAC that an early
>    dialog has been = terminated=20 before a final response is sent.
>
> Oddly, though everyone = thinks=20 they understand this sentence, it
> doesn't really say what we = want. =20 To really ensure that the UAC
> understands the early dialog has = been=20 terminated before the UAS sends
> a final response, the UAS would = have to=20 send 199 *and get the PRACK
> saying that it was received* before = sending=20 a final response.  This may
> well be worse than the present = state of=20 affairs.
>
> What we really mean=20 is:
>
>    REQ 1: It must be possible for a = UAS or=20 proxy to send an indication
>    to the UAC that an = early=20 dialog has been terminated, which
>    indication = will not=20 be delayed waiting for a final response from
>    = any=20 UAS.
>
> * Section 4
>
>    When = a client=20 receives a 199 Early Dialog Terminated = provisional
>   =20 response it MAY release resources and procedures associated with=20 the
>    early dialog the 199 response is received=20 on.
>
> Amend to clarify the meaning of 199 independently of = the=20 consequences
> of that meaning:
>
>    = When a=20 client receives a 199 Early Dialog Terminated=20 provisional
>    response, it has positive = knowledge that=20 the UAS that created the
>    early dialog has = terminated=20 it, and so the client MAY release
>    resources = and=20 procedures associated with the early dialog for = which
>   =20 the 199 response is received.
>
> * Section = 4
>
> Add=20 this paragraph before the last = paragraph:
>
>    A=20 UAC that receives a 199 response for an early dialog MUST=20 NOT
>    send any further requests on that dialog, = except=20 for a PRACK if the
>    199 response was sent = reliably, and=20 PRACKs for other reliable
>    provisional = responses that=20 are to be acknowledged.
>
> This is copied from section 7 = (Backward=20 Compatibility), but since it
> is a constraint on UACs, it should = also be=20 stated in this section.
>
> * Section=20 4
>
>    The UAC MAY use additional = information (for=20 example the final
>    response which triggered the = 199=20 response) received in the 199
>    response when = initiating=20 new sessions, if it is possible to avoid the
>    = new=20 session initiation request to be rejected.
>
> What is the = meaning=20 of the final clause?
>
> * Section 5
>
> Add = "early" as=20 marked:
>
>    When a UAS wants to terminate = *an=20 early* dialog it sends a non-2xx
>    SIP final = response,=20 as specified in [RFC3261].  In addition, = prior
>    to=20 sending the non-2xx SIP final response, the UAS MAY send a=20 199
>    response to indicate that the dialog is = being=20 terminated.
>
> This clarifies that 199 cannot be used to = terminate=20 a confirmed
> dialog.
>
> (The reason a UAS may want = to send a=20 199 is to provide this
> information even when the upstream proxy = does not=20 support 199.)
>
> There is a subtlty to the second=20 sentence:
>
> Sending the 199 *before* the final response is = not=20 necessary due to
> the semantics of 199 (as it will probably reach = the UAC=20 first anyway,
> and it would not matter if it did not), but rather = to=20 prevent the
> upstream proxy from generating a 199 based on the = final=20 response, and
> then to transmit the UAS's 199 immediately after = -- if the=20 UAS sends
> the 199 first, any upstream proxy will (most likely) = see the=20 199
> before seeing the final response (which might induce the = proxy to=20 send
> its own 199).
>
> * Section=20 6
>
>    When a forking proxy receives a = non-2xx=20 final response which
>    terminates one or more = early=20 dialogs and the proxy does not intend to
>    = forward the=20 final response immediately (due to the rules for = a
>   =20 forking proxy) it MUST send a 199 provisional response, for=20 each
>    associated early dialog that it can = associate=20 with the final
>    response, upstream towards the = sender=20 of the associated request.
>
> Clarify, and note that if the = proxy=20 has already passed a 199 for an
> early dialog, it need not = generate one=20 itself.  Also, I've reduced
> MUST to SHOULD, because (as the = following NOTE explains), the proxy
> may not know of all early = dialogs=20 which are terminated by the final
>=20 response.
>
>    [...] it SHOULD initiate a = 199=20 provisional response upstream
>    towards the = sender of=20 the associated request, for each terminated
>    = early=20 dialog, excepting those for which it has already=20 transmitted
>    a 199 response.
>
> = Note that=20 the "already transmitted 199 responses" may have come from
> = downstream=20 proxies as well as downstream UASs, so this consideration
> = applies even=20 if we do not allow UASs to send 199s.
>
> * Section=20 7
>
>    Since all SIP entities involved in a = session=20 setup do not necessarily
>    support the specific = meaning=20 of the 199 Early Dialog Terminated
>    provisional = response, the sender of the response MUST be prepared=20 to
>    receive SIP requests associated with the = dialog for=20 which the 199
>    response was = sent.
>
> This=20 situation can also result due to race conditions.  Amend=20 to:
>
>    Because of race conditions and = because the=20 client may not support the
>    specific meaning of = the 199=20 provisional response, the sender of the
>    = response MUST=20 be prepared to receive SIP requests associated = with
>   =20 the dialog for which the 199 response was sent.
>
> And add = a=20 qualifier to this sentence:
>
>    If such = request is=20 received, and the receiver maintains state of
>    = the=20 dialogs, the receiver MUST reply to such requests with a=20 481
>    final response (unless another error = response is=20 more appropriate).
>
> * Section 7
>
> Remove = "..." from=20 this sentence and add "even" as = marked:
>
>    The=20 199 Early Dialog Terminated response code MUST NOT replace=20 a
>    final response.  A final response MUST = always=20 be sent, *even* after
>    one or many 199 Early = Dialog=20 Terminated provisional responses have
>    been=20 sent.
>
> * Section 8
>
> Clarify this sentence=20 to:
>
>    The 199 Early Dialog Terminated = response=20 code allows a SIP entity
>    to indicate to = upstream=20 entities that a specific early dialog has
>    been = terminated, before a final response reaches the=20 upstream
>    entities.
>
> Add the=20 following:
>
>    The early dialog that has = been=20 terminated is identified by the Call-Id
>    header = and the=20 to-tag value of the 199 response.
>
>    = Future=20 standards may define optional additional information=20 carried
>    in the headers and/or body of the=20 response.
>
> * Section 9
>
>    = A 199=20 Early Dialog Terminated provisional response MUST NOT contain=20 a
>    new SDP offer/answer message body, but the = sender of=20 the response MAY
>    insert a copy of a previously = sent=20 offer/answer message body as
>    otherwise allowed = by the=20 offer/answer rules for a provisional
>   =20 response.
>
> This rule seems excessively strict, as it = seems OK to=20 send a new SDP
> answer in a 199, even if the dialog will be = immediately=20 terminated.
> Certainly, the UAC cannot tell the difference, as = there=20 could have
> been a previous but lost 1xx response carrying the = same=20 SDP.
>
> The interaction of 199 and SDP probably needs = further=20 study...
>
> * Section 11
>
> Nit:  Use = "reject"=20 here rather than "rejects":
>
>    UAS_2 and = UAS_3=20 *reject* the INVITE by sending a 4xx error response.
>
> = Here is a=20 modification of the example, showing how a UAS can send a
> 199, = and how=20 the proxy handles it.  (You may or may not want to use
> = this.) =20 I've also added the ACK's for the 4xx's, which were missing in
> = the=20 original.
>
>    [...] UAS_2 and UAS_3 reject = the=20 INVITE by sending a 4xx error
>    response.  = UAS_3=20 sends a 199 with its 4xx.  When P1 receives = the
>   =20 4xx response from UAS_2 it immediately sends a 199 Early=20 Dialog
>    Terminated associated with UAS_2's = dialog=20 towards the UAC.  P1
>    transmits UAS_3's = 199, and=20 so does not initiate one itself for
>    UAS_3's = dialog=20 when it receives UAS_3's 4xx=20 response.
>
>      =20 UAC           &nbs= p;  =20 P1            = ;     =20 UAS_2    UAS_3   =20 UAS_4
>
>        --- = INVITE=20 ------>
>         &= nbsp;           &n= bsp;   =20 --- INVITE (leg 2)=20 ->
>          =             &= nbsp;  =20 --- INVITE (leg 3)=20 ---------->
>        &nb= sp;           &nbs= p;    =20 --- INVITE (leg 4)=20 ------------------->
>       =             &= nbsp;     =20 <-- 18x (leg 2) = -----
>       =20 <-- 18x (leg 2)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 18x (leg 3)=20 --------------
>        <-- = 18x (leg=20 3)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 18x (leg 4)=20 -----------------------
>       = <--=20 18x (leg 4)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 4xx (leg 2) = -----
>       =20 <-- 199 (leg 2)=20 --
>          &nb= sp;           &nbs= p;  =20 --- ACK (leg 2)=20 ---->
>         &nb= sp;           &nbs= p;   =20 <-- 199 (leg 3)=20 --------------
>        <-- = 199 (leg=20 3)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 4xx (leg 3)=20 --------------
>        &nb= sp;           &nbs= p;    =20 --- ACK (leg 3)=20 ------------->
>        =             &= nbsp;    =20 <-- 200 (leg 4)=20 -----------------------
>       = <--=20 200 (leg 4) --
>        --- ACK = (leg 4)=20 ->
>          =             &= nbsp;  =20 --- ACK (leg 4) ---------------------->
>
> Dale
>=20 _______________________________________________
> Sip mailing = list =20 https://www.ietf.org/m= ailman/listinfo/sip
>=20 This list is for NEW development of the core SIP Protocol
> Use=20 sip-implementors@cs.columbia.edu for questions on current sip
> = Use=20 sipping@ietf.org for new developments on the application of=20 sip
>
_______________________________________________
Sip = mailing=20 list  https://www.ietf.org/m= ailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip



.

------_=_NextPart_001_01C8CF88.98F3BD26-- --===============2045265131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2045265131==-- From sip-bounces@ietf.org Mon Jun 16 04:03:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7043A6A96; Mon, 16 Jun 2008 04:03:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497F33A6A96 for ; Mon, 16 Jun 2008 04:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue9iSwznK77R for ; Mon, 16 Jun 2008 04:03:32 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 179553A69C9 for ; Mon, 16 Jun 2008 04:03:31 -0700 (PDT) X-AuditID: cb5bdd57-a9eafbb0000065b1-33-485648a78885 Received: from blr-ec-aa03.wipro.com (unknown [10.201.18.42]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id A5D324E4002 for ; Mon, 16 Jun 2008 16:34:07 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 16:33:46 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 16:33:46 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 16:35:29 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNXzah/o/xCGVESEOOeRMvhrFHbgA2G5uyAFJZJFAAAcDC8AACkVeA From: To: , , , X-OriginalArrivalTime: 16 Jun 2008 11:03:46.0352 (UTC) FILETIME=[A5CE0B00:01C8CFA0] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1372059798==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1372059798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CFA0.A516A064" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CFA0.A516A064 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Christer, We have a query on our basic understanding of this draft. =20 I too had the same query as Ashish, I can rephrase it for all of us. What we mean to ask is that, considering the scenario shown by the SIP = msg flow below, at what point does the proxy decide to send 199 response = and on which call legs. =20 For e.g. in the scenario below, when proxy receives 403 on leg 2, and it = is yet to receive responses on leg 3 and 4. In this case, the proxy = cannot send a 199 to the UAC (is my understanding, please correct if = wrong). Also after having received 5xx and 6xx on the leg 3 and 4, there is no = use sending 199 now because the best final response sent to UAC is = sufficient to indicate that the leg 3 and 4 are terminated. =20 =20 Please correct us if we are missing some hidden lines in the draft w.r.t = our understanding. =20 Thanks, Best Regards, Rekha (ESN : 6-877-5834) (PSTN : 81168) =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Christer Holmberg Sent: Monday, June 16, 2008 1:42 PM To: Ashish Saxena (WT01 - Telecom Equipment); pkyzivat@cisco.com; = Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 =20 Hi, =20 The way the "best" final response code is chosen is described in RFC = 3261, and the intention of 199 is not to change that. =20 Regarding whether a 199 will be sent for leg 4: if the proxy is now = going to send a "best" final response I guess it doesn't need to send = 199 for leg 4. =20 Regards, =20 Christer =20 =20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = ashish.hsaxena@wipro.com Sent: 16. kes=E4kuuta 2008 10:32 To: pkyzivat@cisco.com; Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Referring to introduction part in the draft. " At some point the proxy uses a specified mechanism to determine the = "best" final response code, and forwards that final response upstream = towards the sender of the associated request." =20 Considering a scenario where all the forks have failed in yielding a 2xx = response from different UASes (UAS2 , 3 & 4 in the diagram) with = different error codes, how will the proxy determine the "best" final = response and to which leg would it send the best final response. What = would happen after 199 to leg 4? =20 UAC P1 UAS_2 UAS_3 UAS_4 --- INVITE ------> --- INVITE (leg 2) -> --- INVITE (leg 3) ----------> --- INVITE (leg 4) -------------------> <-- 18x (leg 2) ----- <-- 18x (leg 2) -- <-- 18x (leg 3) -------------- <-- 18x (leg 3) -- <-- 18x (leg 4) ----------------------- <-- 18x (leg 4) -- <-- 4xx (leg 2) ----- <-- 199 (leg 2) -- <-- 5xx (leg 3) -------------- <-- 199 (leg 3) -- <-- 6xx (leg 4) ----------------------- <-- 199 (leg 4) -- Best Regards,=20 Ashish Saxena=20 877-5570=20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Attila Sipos Sent: Saturday, June 14, 2008 9:30 PM To: Paul Kyzivat; Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >>However I am still scratching my head about the UAS sending a 199. = While >>I see no reason to forbid it I'm trying to find a situation when it >>would be helpful. It may or may not be helpful but as you say, you can see no reason to forbid it. Why restrict it if the restriction isn't needed? As someone has pointed out, a B2BUA scenario might benefit from 199. In fact, any kind of SIP gateway might benefit. > This is one of those cases that could probably benefit from > simulation to judge the merits. My gut feel is that the costs > of the UAS sending the 199 outweigh the benefits. If the UAS wants to send it, that is a decision for them - not something that needs to be prevented. SIP forking, in the technical sense of sending a response with a different to-tag, is always legal. So, any UA which has used forking should also be able to use 199. I don't think we need to include any specific text about UAS except to say that a UAS can use it if the UAS has created the forking. Regards, Attila -----Original Message----- From: sip-bounces@ietf.org on behalf of Paul Kyzivat Sent: Fri 13/06/2008 15:07 To: Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 This all sounds like good stuff. However I am still scratching my head about the UAS sending a 199. While I see no reason to forbid it I'm trying to find a situation when it would be helpful. The only case I have been able to think of is: There is a forking proxy upstream of the UAS, but it doesn't support 199. Yet it may delay the final response while it tries other forks. So the UAS sending the 199 makes up for the inadequacy of the forking proxy. The trouble with this is that it is inefficient in many cases. If each proxy that forks also supports the sending of 199, and the UAS doesn't send one, then we avoid sending the message except in cases where it is helpful. If the UAS always sends it we have increased the message count by one for all failing calls. And the majority of failing calls get no benefit from a 199. This is one of those cases that could probably benefit from simulation to judge the merits. My gut feel is that the costs of the UAS sending the 199 outweigh the benefits. Barring some analysis to the contrary I think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, but without any guidance of when. Paul Dale.Worley@comcast.net wrote: > Here are some comments on this I-D. I don't think that any of them > modify our understanding of the proposal. I guess this is very terse; > please use these suggestions as you see fit. > > * Abstract > > Clarify: > > This specification defines a new SIP response code, 199 Early > Dialog Terminated, which a SIP entity can use to indicate upstream > that an early dialog has been terminated. The response code can be > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > an early dialog has been terminated. As the 199 response is a > provisional response, often the UAC will receive it before > receiving a final response to its request. > > * Section 1 > > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations = where > the forked request was forwarded. > > The text does not allow for serial forking, only parallel forking, > which might be confusing to people who are more aware of serial > forking. So amend the last sentence to: > > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. > > Also, Avoid using "..." except when indicating that the word is used > in a non-standard way or that one is discussing the word itself: > > Instead, the forking proxy "stores" it [...] > > should be: > > Instead, the forking proxy stores it [...] > > * Section 3. > > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. > > Oddly, though everyone thinks they understand this sentence, it > doesn't really say what we want. To really ensure that the UAC > understands the early dialog has been terminated before the UAS sends > a final response, the UAS would have to send 199 *and get the PRACK > saying that it was received* before sending a final response. This = may > well be worse than the present state of affairs. > > What we really mean is: > > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. > > * Section 4 > > When a client receives a 199 Early Dialog Terminated provisional > response it MAY release resources and procedures associated with = the > early dialog the 199 response is received on. > > Amend to clarify the meaning of 199 independently of the consequences > of that meaning: > > When a client receives a 199 Early Dialog Terminated provisional > response, it has positive knowledge that the UAS that created the > early dialog has terminated it, and so the client MAY release > resources and procedures associated with the early dialog for which > the 199 response is received. > > * Section 4 > > Add this paragraph before the last paragraph: > > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. > > This is copied from section 7 (Backward Compatibility), but since it > is a constraint on UACs, it should also be stated in this section. > > * Section 4 > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid = the > new session initiation request to be rejected. > > What is the meaning of the final clause? > > * Section 5 > > Add "early" as marked: > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. > > This clarifies that 199 cannot be used to terminate a confirmed > dialog. > > (The reason a UAS may want to send a 199 is to provide this > information even when the upstream proxy does not support 199.) > > There is a subtlty to the second sentence: > > Sending the 199 *before* the final response is not necessary due to > the semantics of 199 (as it will probably reach the UAC first anyway, > and it would not matter if it did not), but rather to prevent the > upstream proxy from generating a 199 based on the final response, and > then to transmit the UAS's 199 immediately after -- if the UAS sends > the 199 first, any upstream proxy will (most likely) see the 199 > before seeing the final response (which might induce the proxy to send > its own 199). > > * Section 6 > > When a forking proxy receives a non-2xx final response which > terminates one or more early dialogs and the proxy does not intend = to > forward the final response immediately (due to the rules for a > forking proxy) it MUST send a 199 provisional response, for each > associated early dialog that it can associate with the final > response, upstream towards the sender of the associated request. > > Clarify, and note that if the proxy has already passed a 199 for an > early dialog, it need not generate one itself. Also, I've reduced > MUST to SHOULD, because (as the following NOTE explains), the proxy > may not know of all early dialogs which are terminated by the final > response. > > [...] it SHOULD initiate a 199 provisional response upstream > towards the sender of the associated request, for each terminated > early dialog, excepting those for which it has already transmitted > a 199 response. > > Note that the "already transmitted 199 responses" may have come from > downstream proxies as well as downstream UASs, so this consideration > applies even if we do not allow UASs to send 199s. > > * Section 7 > > Since all SIP entities involved in a session setup do not = necessarily > support the specific meaning of the 199 Early Dialog Terminated > provisional response, the sender of the response MUST be prepared = to > receive SIP requests associated with the dialog for which the 199 > response was sent. > > This situation can also result due to race conditions. Amend to: > > Because of race conditions and because the client may not support = the > specific meaning of the 199 provisional response, the sender of the > response MUST be prepared to receive SIP requests associated with > the dialog for which the 199 response was sent. > > And add a qualifier to this sentence: > > If such request is received, and the receiver maintains state of > the dialogs, the receiver MUST reply to such requests with a 481 > final response (unless another error response is more appropriate). > > * Section 7 > > Remove "..." from this sentence and add "even" as marked: > > The 199 Early Dialog Terminated response code MUST NOT replace a > final response. A final response MUST always be sent, *even* after > one or many 199 Early Dialog Terminated provisional responses have > been sent. > > * Section 8 > > Clarify this sentence to: > > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. > > Add the following: > > The early dialog that has been terminated is identified by the = Call-Id > header and the to-tag value of the 199 response. > > Future standards may define optional additional information carried > in the headers and/or body of the response. > > * Section 9 > > A 199 Early Dialog Terminated provisional response MUST NOT contain = a > new SDP offer/answer message body, but the sender of the response = MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > > This rule seems excessively strict, as it seems OK to send a new SDP > answer in a 199, even if the dialog will be immediately terminated. > Certainly, the UAC cannot tell the difference, as there could have > been a previous but lost 1xx response carrying the same SDP. > > The interaction of 199 and SDP probably needs further study... > > * Section 11 > > Nit: Use "reject" here rather than "rejects": > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error = response. > > Here is a modification of the example, showing how a UAS can send a > 199, and how the proxy handles it. (You may or may not want to use > this.) I've also added the ACK's for the 4xx's, which were missing in > the original. > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > Terminated associated with UAS_2's dialog towards the UAC. P1 > transmits UAS_3's 199, and so does not initiate one itself for > UAS_3's dialog when it receives UAS_3's 4xx response. > > UAC P1 UAS_2 UAS_3 UAS_4 > > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > --- ACK (leg 2) ----> > <-- 199 (leg 3) -------------- > <-- 199 (leg 3) -- > <-- 4xx (leg 3) -------------- > --- ACK (leg 3) -------------> > <-- 200 (leg 4) ----------------------- > <-- 200 (leg 4) -- > --- ACK (leg 4) -> > --- ACK (leg 4) ----------------------> > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip . ------_=_NextPart_001_01C8CFA0.A516A064 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Draft submission: = draft-ietf-sip-199-00
Thanks Christer,
We have a query on our basic understanding of = this=20 draft.
 
I too had the same query as Ashish, I can = rephrase it for=20 all of us.
What we mean to ask is that, considering the = scenario shown=20 by the SIP msg flow below, at what point does the proxy = decide=20 to send 199 response and on which call=20 legs.
 
Also after having received 5xx = and 6xx on=20 the leg 3 and 4, there is no use sending 199 now because the best final = response=20 sent to UAC is sufficient to indicate that the leg 3 and 4 are=20 terminated.
 
 
Please correct us if we are = missing some=20 hidden lines in the draft w.r.t our=20 understanding.
 
Thanks,
Best=20 Regards,
Rekha
(ESN :=20 6-877-5834)
(PSTN :=20 81168)
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: Monday, June 16, 2008 1:42 PM
To: = Ashish=20 Saxena (WT01 - Telecom Equipment); pkyzivat@cisco.com;=20 Dale.Worley@comcast.net
Cc: sip@ietf.org
Subject: = Re: [Sip]=20 Draft submission: draft-ietf-sip-199-00

 
Hi,
 
The=20 way the "best" final response code is chosen is described in RFC 3261, = and the=20 intention of 199 is not to change that.
 
Regarding whether a 199 will be sent for leg = 4: if the=20 proxy is now going to send a "best" final response I guess it doesn't = need to=20 send 199 for leg 4.
 
Regards,
 
Christer
 
 
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of=20 ashish.hsaxena@wipro.com
Sent: 16. kes=E4kuuta 2008=20 10:32
To: pkyzivat@cisco.com; = Dale.Worley@comcast.net
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Draft submission:=20 draft-ietf-sip-199-00

Referring to introduction part in the = draft.
   " At some point = the proxy=20 uses a specified mechanism to determine the "best" final response = code,=20 and forwards that final response upstream towards the sender of=20 the associated request."
 
Considering a scenario where all the forks have failed in = yielding a 2xx=20 response from different UASes (UAS2 , 3 & 4 in the diagram) with = different=20 error codes, how will the proxy determine the "best" final response and = to which=20 leg would it send the best final response. What would happen after 199 = to leg=20 4?
 
     =20 UAC           &nbs= p;  =20 P1            = ;     =20 UAS_2    UAS_3   =20 UAS_4

       --- INVITE=20 ------>
          = ;            =   =20 --- INVITE (leg 2)=20 ->
          &nbs= p;            = ; =20 --- INVITE (leg 3)=20 ---------->
         &= nbsp;           &n= bsp;  =20 --- INVITE (leg 4)=20 ------------------->
       &nbs= p;            = ;    =20 <-- 18x (leg 2) -----
       <-- = 18x (leg=20 2)=20 --
           &= nbsp;           &n= bsp;=20 <-- 18x (leg 3) = --------------
       <--=20 18x (leg 3)=20 --
           &= nbsp;           &n= bsp;=20 <-- 18x (leg 4)=20 -----------------------
       <-- = 18x (leg=20 4)=20 --
           &= nbsp;           &n= bsp;=20 <-- 4xx (leg 2)=20 -----
       <-- 199 (leg 2)=20 --
           &= nbsp;           &n= bsp;=20 <-- 5xx (leg 3)=20 --------------
       <-- 199 (leg = 3)=20 --
           &= nbsp;           &n= bsp;=20 <-- 6xx (leg 4)=20 -----------------------
       = <-- 199=20 (leg 4) --

Best = Regards,
Ashish Saxena
877-5570

 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Attila = Sipos
Sent:=20 Saturday, June 14, 2008 9:30 PM
To: Paul Kyzivat;=20 Dale.Worley@comcast.net
Cc: sip@ietf.org
Subject: = Re: [Sip]=20 Draft submission: draft-ietf-sip-199-00


>>However I am still scratching my head about = the UAS=20 sending a 199. While
>>I see no reason to forbid it I'm trying = to find=20 a situation when it
>>would be helpful.

It may or may = not be=20 helpful but as you say, you can
see no reason to forbid = it.

Why=20 restrict it if the restriction isn't needed?

As someone has = pointed out,=20 a B2BUA scenario might benefit
from 199.  In fact, any kind of = SIP=20 gateway might benefit.

> This is one of those cases that could = probably benefit from
> simulation to judge the merits. My gut = feel is=20 that the costs
> of the UAS sending the 199 outweigh the=20 benefits.

If the UAS wants to send it, that is a decision = for
them -=20 not something that needs to be prevented.

SIP forking, in the = technical=20 sense of sending a
response with a different to-tag, is always = legal.
So,=20 any UA which has used forking
should also be able to use = 199.

I don't=20 think we need to include any specific text about UAS
except to say = that a UAS=20 can use it if the UAS has created
the=20 forking.

Regards,

Attila



-----Original=20 Message-----
From: sip-bounces@ietf.org on behalf of Paul = Kyzivat
Sent:=20 Fri 13/06/2008 15:07
To: Dale.Worley@comcast.net
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Draft submission:=20 draft-ietf-sip-199-00

This all sounds like good = stuff.

However I=20 am still scratching my head about the UAS sending a 199. While
I see = no=20 reason to forbid it I'm trying to find a situation when it
would be = helpful.=20 The only case I have been able to think of is:

   There = is a=20 forking proxy upstream of the UAS, but it doesn't
   = support 199.=20 Yet it may delay the final response while it
   tries other = forks.=20 So the UAS sending the 199 makes up for
   the inadequacy = of the=20 forking proxy.

The trouble with this is that it is inefficient in = many=20 cases. If each
proxy that forks also supports the sending of 199, and = the UAS=20 doesn't
send one, then we avoid sending the message except in cases = where it=20 is
helpful. If the UAS always sends it we have increased the message=20 count
by one for all failing calls. And the majority of failing calls = get=20 no
benefit from a 199.

This is one of those cases that could = probably=20 benefit from simulation
to judge the merits. My gut feel is that the = costs of=20 the UAS sending
the 199 outweigh the benefits. Barring some analysis = to the=20 contrary I
think I would say that a UAS SHOULD NOT send a 199. Or = perhaps MAY=20 send,
but without any guidance of=20 when.

       =20 Paul

Dale.Worley@comcast.net wrote:
> Here are some = comments on=20 this I-D.  I don't think that any of them
> modify our = understanding=20 of the proposal.  I guess this is very terse;
> please use = these=20 suggestions as you see fit.
>
> * Abstract
>
>=20 Clarify:
>
>    This specification defines a = new SIP=20 response code, 199 Early
>    Dialog Terminated, = which a=20 SIP entity can use to indicate upstream
>    that = an early=20 dialog has been terminated.  The response code can=20 be
>    used by a SIP entity (a SIP proxy or UAS), = to=20 inform the UAC that
>    an early dialog has been=20 terminated.  As the 199 response is a
>    = provisional=20 response, often the UAC will receive it before
>    = receiving a final response to its request.
>
> * Section=20 1
>
>    When a forking proxy receives a = non-2xx=20 final response, it does not
>    always immediately = forward=20 the response upstream towards the sender
>    of = the=20 associated request.  Instead, the forking proxy "stores"=20 it
>    and waits for further final responses from = remote=20 destinations where
>    the forked request was=20 forwarded.
>
> The text does not allow for serial forking, = only=20 parallel forking,
> which might be confusing to people who are = more aware=20 of serial
> forking.  So amend the last sentence=20 to:
>
>    Instead, the forking proxy = "stores" it and=20 waits for further final
>    responses from remote=20 destinations where the forked request was
>    = forwarded,=20 and possibly forwards the request to = additional
>   =20 destinations.
>
> Also, Avoid using "..." except when = indicating=20 that the word is used
> in a non-standard way or that one is = discussing=20 the word itself:
>
>    Instead, the forking = proxy=20 "stores" it [...]
>
> should = be:
>
>   =20 Instead, the forking proxy stores it [...]
>
> * Section=20 3.
>
>    REQ 1: It must be possible to = indicate to=20 the UAC that an early
>    dialog has been = terminated=20 before a final response is sent.
>
> Oddly, though everyone = thinks=20 they understand this sentence, it
> doesn't really say what we = want. =20 To really ensure that the UAC
> understands the early dialog has = been=20 terminated before the UAS sends
> a final response, the UAS would = have to=20 send 199 *and get the PRACK
> saying that it was received* before = sending=20 a final response.  This may
> well be worse than the present = state of=20 affairs.
>
> What we really mean=20 is:
>
>    REQ 1: It must be possible for a = UAS or=20 proxy to send an indication
>    to the UAC that an = early=20 dialog has been terminated, which
>    indication = will not=20 be delayed waiting for a final response from
>    = any=20 UAS.
>
> * Section 4
>
>    When = a client=20 receives a 199 Early Dialog Terminated = provisional
>   =20 response it MAY release resources and procedures associated with=20 the
>    early dialog the 199 response is received=20 on.
>
> Amend to clarify the meaning of 199 independently of = the=20 consequences
> of that meaning:
>
>    = When a=20 client receives a 199 Early Dialog Terminated=20 provisional
>    response, it has positive = knowledge that=20 the UAS that created the
>    early dialog has = terminated=20 it, and so the client MAY release
>    resources = and=20 procedures associated with the early dialog for = which
>   =20 the 199 response is received.
>
> * Section = 4
>
> Add=20 this paragraph before the last = paragraph:
>
>    A=20 UAC that receives a 199 response for an early dialog MUST=20 NOT
>    send any further requests on that dialog, = except=20 for a PRACK if the
>    199 response was sent = reliably, and=20 PRACKs for other reliable
>    provisional = responses that=20 are to be acknowledged.
>
> This is copied from section 7 = (Backward=20 Compatibility), but since it
> is a constraint on UACs, it should = also be=20 stated in this section.
>
> * Section=20 4
>
>    The UAC MAY use additional = information (for=20 example the final
>    response which triggered the = 199=20 response) received in the 199
>    response when = initiating=20 new sessions, if it is possible to avoid the
>    = new=20 session initiation request to be rejected.
>
> What is the = meaning=20 of the final clause?
>
> * Section 5
>
> Add = "early" as=20 marked:
>
>    When a UAS wants to terminate = *an=20 early* dialog it sends a non-2xx
>    SIP final = response,=20 as specified in [RFC3261].  In addition, = prior
>    to=20 sending the non-2xx SIP final response, the UAS MAY send a=20 199
>    response to indicate that the dialog is = being=20 terminated.
>
> This clarifies that 199 cannot be used to = terminate=20 a confirmed
> dialog.
>
> (The reason a UAS may want = to send a=20 199 is to provide this
> information even when the upstream proxy = does not=20 support 199.)
>
> There is a subtlty to the second=20 sentence:
>
> Sending the 199 *before* the final response is = not=20 necessary due to
> the semantics of 199 (as it will probably reach = the UAC=20 first anyway,
> and it would not matter if it did not), but rather = to=20 prevent the
> upstream proxy from generating a 199 based on the = final=20 response, and
> then to transmit the UAS's 199 immediately after = -- if the=20 UAS sends
> the 199 first, any upstream proxy will (most likely) = see the=20 199
> before seeing the final response (which might induce the = proxy to=20 send
> its own 199).
>
> * Section=20 6
>
>    When a forking proxy receives a = non-2xx=20 final response which
>    terminates one or more = early=20 dialogs and the proxy does not intend to
>    = forward the=20 final response immediately (due to the rules for = a
>   =20 forking proxy) it MUST send a 199 provisional response, for=20 each
>    associated early dialog that it can = associate=20 with the final
>    response, upstream towards the = sender=20 of the associated request.
>
> Clarify, and note that if the = proxy=20 has already passed a 199 for an
> early dialog, it need not = generate one=20 itself.  Also, I've reduced
> MUST to SHOULD, because (as the = following NOTE explains), the proxy
> may not know of all early = dialogs=20 which are terminated by the final
>=20 response.
>
>    [...] it SHOULD initiate a = 199=20 provisional response upstream
>    towards the = sender of=20 the associated request, for each terminated
>    = early=20 dialog, excepting those for which it has already=20 transmitted
>    a 199 response.
>
> = Note that=20 the "already transmitted 199 responses" may have come from
> = downstream=20 proxies as well as downstream UASs, so this consideration
> = applies even=20 if we do not allow UASs to send 199s.
>
> * Section=20 7
>
>    Since all SIP entities involved in a = session=20 setup do not necessarily
>    support the specific = meaning=20 of the 199 Early Dialog Terminated
>    provisional = response, the sender of the response MUST be prepared=20 to
>    receive SIP requests associated with the = dialog for=20 which the 199
>    response was = sent.
>
> This=20 situation can also result due to race conditions.  Amend=20 to:
>
>    Because of race conditions and = because the=20 client may not support the
>    specific meaning of = the 199=20 provisional response, the sender of the
>    = response MUST=20 be prepared to receive SIP requests associated = with
>   =20 the dialog for which the 199 response was sent.
>
> And add = a=20 qualifier to this sentence:
>
>    If such = request is=20 received, and the receiver maintains state of
>    = the=20 dialogs, the receiver MUST reply to such requests with a=20 481
>    final response (unless another error = response is=20 more appropriate).
>
> * Section 7
>
> Remove = "..." from=20 this sentence and add "even" as = marked:
>
>    The=20 199 Early Dialog Terminated response code MUST NOT replace=20 a
>    final response.  A final response MUST = always=20 be sent, *even* after
>    one or many 199 Early = Dialog=20 Terminated provisional responses have
>    been=20 sent.
>
> * Section 8
>
> Clarify this sentence=20 to:
>
>    The 199 Early Dialog Terminated = response=20 code allows a SIP entity
>    to indicate to = upstream=20 entities that a specific early dialog has
>    been = terminated, before a final response reaches the=20 upstream
>    entities.
>
> Add the=20 following:
>
>    The early dialog that has = been=20 terminated is identified by the Call-Id
>    header = and the=20 to-tag value of the 199 response.
>
>    = Future=20 standards may define optional additional information=20 carried
>    in the headers and/or body of the=20 response.
>
> * Section 9
>
>    = A 199=20 Early Dialog Terminated provisional response MUST NOT contain=20 a
>    new SDP offer/answer message body, but the = sender of=20 the response MAY
>    insert a copy of a previously = sent=20 offer/answer message body as
>    otherwise allowed = by the=20 offer/answer rules for a provisional
>   =20 response.
>
> This rule seems excessively strict, as it = seems OK to=20 send a new SDP
> answer in a 199, even if the dialog will be = immediately=20 terminated.
> Certainly, the UAC cannot tell the difference, as = there=20 could have
> been a previous but lost 1xx response carrying the = same=20 SDP.
>
> The interaction of 199 and SDP probably needs = further=20 study...
>
> * Section 11
>
> Nit:  Use = "reject"=20 here rather than "rejects":
>
>    UAS_2 and = UAS_3=20 *reject* the INVITE by sending a 4xx error response.
>
> = Here is a=20 modification of the example, showing how a UAS can send a
> 199, = and how=20 the proxy handles it.  (You may or may not want to use
> = this.) =20 I've also added the ACK's for the 4xx's, which were missing in
> = the=20 original.
>
>    [...] UAS_2 and UAS_3 reject = the=20 INVITE by sending a 4xx error
>    response.  = UAS_3=20 sends a 199 with its 4xx.  When P1 receives = the
>   =20 4xx response from UAS_2 it immediately sends a 199 Early=20 Dialog
>    Terminated associated with UAS_2's = dialog=20 towards the UAC.  P1
>    transmits UAS_3's = 199, and=20 so does not initiate one itself for
>    UAS_3's = dialog=20 when it receives UAS_3's 4xx=20 response.
>
>      =20 UAC           &nbs= p;  =20 P1            = ;     =20 UAS_2    UAS_3   =20 UAS_4
>
>        --- = INVITE=20 ------>
>         &= nbsp;           &n= bsp;   =20 --- INVITE (leg 2)=20 ->
>          =             &= nbsp;  =20 --- INVITE (leg 3)=20 ---------->
>        &nb= sp;           &nbs= p;    =20 --- INVITE (leg 4)=20 ------------------->
>       =             &= nbsp;     =20 <-- 18x (leg 2) = -----
>       =20 <-- 18x (leg 2)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 18x (leg 3)=20 --------------
>        <-- = 18x (leg=20 3)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 18x (leg 4)=20 -----------------------
>       = <--=20 18x (leg 4)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 4xx (leg 2) = -----
>       =20 <-- 199 (leg 2)=20 --
>          &nb= sp;           &nbs= p;  =20 --- ACK (leg 2)=20 ---->
>         &nb= sp;           &nbs= p;   =20 <-- 199 (leg 3)=20 --------------
>        <-- = 199 (leg=20 3)=20 --
>          &nb= sp;           &nbs= p;  =20 <-- 4xx (leg 3)=20 --------------
>        &nb= sp;           &nbs= p;    =20 --- ACK (leg 3)=20 ------------->
>        =             &= nbsp;    =20 <-- 200 (leg 4)=20 -----------------------
>       = <--=20 200 (leg 4) --
>        --- ACK = (leg 4)=20 ->
>          =             &= nbsp;  =20 --- ACK (leg 4) ---------------------->
>
> Dale
>=20 _______________________________________________
> Sip mailing = list =20 https://www.ietf.org/m= ailman/listinfo/sip
>=20 This list is for NEW development of the core SIP Protocol
> Use=20 sip-implementors@cs.columbia.edu for questions on current sip
> = Use=20 sipping@ietf.org for new developments on the application of=20 sip
>
_______________________________________________
Sip = mailing=20 list  https://www.ietf.org/m= ailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip



.

------_=_NextPart_001_01C8CFA0.A516A064-- --===============1372059798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1372059798==-- From sip-bounces@ietf.org Mon Jun 16 04:34:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43D43A696B; Mon, 16 Jun 2008 04:34:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F4D3A6AC3 for ; Mon, 16 Jun 2008 04:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 rnzeYpJ8nWcH for ; Mon, 16 Jun 2008 04:34:55 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F079E3A684B for ; Mon, 16 Jun 2008 04:34:51 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 50FE220608; Mon, 16 Jun 2008 13:35:31 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-7d-48565003105d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1DD7A207BA; Mon, 16 Jun 2008 13:35:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 13:35:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 13:35:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjNXzah/o/xCGVESEOOeRMvhrFHbgA2G5uyAFJZJFAAAcDC8AACkVeAAASYg4A= References: From: "Christer Holmberg" To: , , , X-OriginalArrivalTime: 16 Jun 2008 11:35:44.0898 (UTC) FILETIME=[1D58EE20:01C8CFA5] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, = >We have a query on our basic understanding of this draft. > = >I too had the same query as Ashish, I can rephrase it for all of us. >What we mean to ask is that, considering the scenario shown by the SIP msg= flow below, at what point does the proxy decide to send 199 response and o= n which call legs. A proxy would send a 199 as soon as it receives a final non-2xx response fo= r a leg. >For e.g. in the scenario below, when proxy receives 403 on leg 2, and it i= s yet to receive responses on leg 3 and 4. In this case, the proxy cannot s= end a 199 to the UAC (is my understanding, = >please correct if wrong). Yes, it can send 199 for leg 2. In SIP you can send as many provisional res= ponses as you want. >Also after having received 5xx and 6xx on the leg 3 and 4, there is no use= sending 199 now because the best final response sent to UAC is sufficient = to indicate that the leg 3 and 4 are = >terminated. If the proxy is going to send a best final response immediately there is no= need to send 199. But, if the proxy is still waiting for final responses, = it would send 199. Regards, Christer = ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris= ter Holmberg Sent: Monday, June 16, 2008 1:42 PM To: Ashish Saxena (WT01 - Telecom Equipment); pkyzivat@cisco.com; Dale.Worl= ey@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 = Hi, = The way the "best" final response code is chosen is described in RFC 3261, = and the intention of 199 is not to change that. = Regarding whether a 199 will be sent for leg 4: if the proxy is now going t= o send a "best" final response I guess it doesn't need to send 199 for leg = 4. = Regards, = Christer = = = ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of ashis= h.hsaxena@wipro.com Sent: 16. kes=E4kuuta 2008 10:32 To: pkyzivat@cisco.com; Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Referring to introduction part in the draft. " At some point the proxy uses a specified mechanism to determine the "b= est" final response code, and forwards that final response upstream towards= the sender of the associated request." = Considering a scenario where all the forks have failed in yielding a 2xx re= sponse from different UASes (UAS2 , 3 & 4 in the diagram) with different er= ror codes, how will the proxy determine the "best" final response and to wh= ich leg would it send the best final response. What would happen after 199 = to leg 4? = UAC P1 UAS_2 UAS_3 UAS_4 --- INVITE ------> --- INVITE (leg 2) -> --- INVITE (leg 3) ----------> --- INVITE (leg 4) -------------------> <-- 18x (leg 2) ----- <-- 18x (leg 2) -- <-- 18x (leg 3) -------------- <-- 18x (leg 3) -- <-- 18x (leg 4) ----------------------- <-- 18x (leg 4) -- <-- 4xx (leg 2) ----- <-- 199 (leg 2) -- <-- 5xx (leg 3) -------------- <-- 199 (leg 3) -- <-- 6xx (leg 4) ----------------------- <-- 199 (leg 4) -- Best Regards, = Ashish Saxena = 877-5570 = = ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Attil= a Sipos Sent: Saturday, June 14, 2008 9:30 PM To: Paul Kyzivat; Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >>However I am still scratching my head about the UAS sending a 199. While >>I see no reason to forbid it I'm trying to find a situation when it >>would be helpful. It may or may not be helpful but as you say, you can see no reason to forbid it. Why restrict it if the restriction isn't needed? As someone has pointed out, a B2BUA scenario might benefit from 199. In fact, any kind of SIP gateway might benefit. > This is one of those cases that could probably benefit from > simulation to judge the merits. My gut feel is that the costs > of the UAS sending the 199 outweigh the benefits. If the UAS wants to send it, that is a decision for them - not something that needs to be prevented. SIP forking, in the technical sense of sending a response with a different to-tag, is always legal. So, any UA which has used forking should also be able to use 199. I don't think we need to include any specific text about UAS except to say that a UAS can use it if the UAS has created the forking. Regards, Attila -----Original Message----- From: sip-bounces@ietf.org on behalf of Paul Kyzivat Sent: Fri 13/06/2008 15:07 To: Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 This all sounds like good stuff. However I am still scratching my head about the UAS sending a 199. While I see no reason to forbid it I'm trying to find a situation when it would be helpful. The only case I have been able to think of is: There is a forking proxy upstream of the UAS, but it doesn't support 199. Yet it may delay the final response while it tries other forks. So the UAS sending the 199 makes up for the inadequacy of the forking proxy. The trouble with this is that it is inefficient in many cases. If each proxy that forks also supports the sending of 199, and the UAS doesn't send one, then we avoid sending the message except in cases where it is helpful. If the UAS always sends it we have increased the message count by one for all failing calls. And the majority of failing calls get no benefit from a 199. This is one of those cases that could probably benefit from simulation to judge the merits. My gut feel is that the costs of the UAS sending the 199 outweigh the benefits. Barring some analysis to the contrary I think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, but without any guidance of when. Paul Dale.Worley@comcast.net wrote: > Here are some comments on this I-D. I don't think that any of them > modify our understanding of the proposal. I guess this is very terse; > please use these suggestions as you see fit. > > * Abstract > > Clarify: > > This specification defines a new SIP response code, 199 Early > Dialog Terminated, which a SIP entity can use to indicate upstream > that an early dialog has been terminated. The response code can be > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > an early dialog has been terminated. As the 199 response is a > provisional response, often the UAC will receive it before > receiving a final response to its request. > > * Section 1 > > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations where > the forked request was forwarded. > > The text does not allow for serial forking, only parallel forking, > which might be confusing to people who are more aware of serial > forking. So amend the last sentence to: > > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. > > Also, Avoid using "..." except when indicating that the word is used > in a non-standard way or that one is discussing the word itself: > > Instead, the forking proxy "stores" it [...] > > should be: > > Instead, the forking proxy stores it [...] > > * Section 3. > > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. > > Oddly, though everyone thinks they understand this sentence, it > doesn't really say what we want. To really ensure that the UAC > understands the early dialog has been terminated before the UAS sends > a final response, the UAS would have to send 199 *and get the PRACK > saying that it was received* before sending a final response. This may > well be worse than the present state of affairs. > > What we really mean is: > > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. > > * Section 4 > > When a client receives a 199 Early Dialog Terminated provisional > response it MAY release resources and procedures associated with the > early dialog the 199 response is received on. > > Amend to clarify the meaning of 199 independently of the consequences > of that meaning: > > When a client receives a 199 Early Dialog Terminated provisional > response, it has positive knowledge that the UAS that created the > early dialog has terminated it, and so the client MAY release > resources and procedures associated with the early dialog for which > the 199 response is received. > > * Section 4 > > Add this paragraph before the last paragraph: > > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. > > This is copied from section 7 (Backward Compatibility), but since it > is a constraint on UACs, it should also be stated in this section. > > * Section 4 > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initiation request to be rejected. > > What is the meaning of the final clause? > > * Section 5 > > Add "early" as marked: > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. > > This clarifies that 199 cannot be used to terminate a confirmed > dialog. > > (The reason a UAS may want to send a 199 is to provide this > information even when the upstream proxy does not support 199.) > > There is a subtlty to the second sentence: > > Sending the 199 *before* the final response is not necessary due to > the semantics of 199 (as it will probably reach the UAC first anyway, > and it would not matter if it did not), but rather to prevent the > upstream proxy from generating a 199 based on the final response, and > then to transmit the UAS's 199 immediately after -- if the UAS sends > the 199 first, any upstream proxy will (most likely) see the 199 > before seeing the final response (which might induce the proxy to send > its own 199). > > * Section 6 > > When a forking proxy receives a non-2xx final response which > terminates one or more early dialogs and the proxy does not intend to > forward the final response immediately (due to the rules for a > forking proxy) it MUST send a 199 provisional response, for each > associated early dialog that it can associate with the final > response, upstream towards the sender of the associated request. > > Clarify, and note that if the proxy has already passed a 199 for an > early dialog, it need not generate one itself. Also, I've reduced > MUST to SHOULD, because (as the following NOTE explains), the proxy > may not know of all early dialogs which are terminated by the final > response. > > [...] it SHOULD initiate a 199 provisional response upstream > towards the sender of the associated request, for each terminated > early dialog, excepting those for which it has already transmitted > a 199 response. > > Note that the "already transmitted 199 responses" may have come from > downstream proxies as well as downstream UASs, so this consideration > applies even if we do not allow UASs to send 199s. > > * Section 7 > > Since all SIP entities involved in a session setup do not necessarily > support the specific meaning of the 199 Early Dialog Terminated > provisional response, the sender of the response MUST be prepared to > receive SIP requests associated with the dialog for which the 199 > response was sent. > > This situation can also result due to race conditions. Amend to: > > Because of race conditions and because the client may not support the > specific meaning of the 199 provisional response, the sender of the > response MUST be prepared to receive SIP requests associated with > the dialog for which the 199 response was sent. > > And add a qualifier to this sentence: > > If such request is received, and the receiver maintains state of > the dialogs, the receiver MUST reply to such requests with a 481 > final response (unless another error response is more appropriate). > > * Section 7 > > Remove "..." from this sentence and add "even" as marked: > > The 199 Early Dialog Terminated response code MUST NOT replace a > final response. A final response MUST always be sent, *even* after > one or many 199 Early Dialog Terminated provisional responses have > been sent. > > * Section 8 > > Clarify this sentence to: > > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. > > Add the following: > > The early dialog that has been terminated is identified by the Call-Id > header and the to-tag value of the 199 response. > > Future standards may define optional additional information carried > in the headers and/or body of the response. > > * Section 9 > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > > This rule seems excessively strict, as it seems OK to send a new SDP > answer in a 199, even if the dialog will be immediately terminated. > Certainly, the UAC cannot tell the difference, as there could have > been a previous but lost 1xx response carrying the same SDP. > > The interaction of 199 and SDP probably needs further study... > > * Section 11 > > Nit: Use "reject" here rather than "rejects": > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. > > Here is a modification of the example, showing how a UAS can send a > 199, and how the proxy handles it. (You may or may not want to use > this.) I've also added the ACK's for the 4xx's, which were missing in > the original. > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > Terminated associated with UAS_2's dialog towards the UAC. P1 > transmits UAS_3's 199, and so does not initiate one itself for > UAS_3's dialog when it receives UAS_3's 4xx response. > > UAC P1 UAS_2 UAS_3 UAS_4 > > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- 4xx (leg 2) ----- > <-- 199 (leg 2) -- > --- ACK (leg 2) ----> > <-- 199 (leg 3) -------------- > <-- 199 (leg 3) -- > <-- 4xx (leg 3) -------------- > --- ACK (leg 3) -------------> > <-- 200 (leg 4) ----------------------- > <-- 200 (leg 4) -- > --- ACK (leg 4) -> > --- ACK (leg 4) ----------------------> > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip . Please do not print this email unless it is absolutely necessary. = The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and ma= y contain proprietary, confidential or privileged information. If you are n= ot the intended recipient, you should not disseminate, distribute or copy t= his e-mail. Please notify the sender immediately and destroy all copies of = this message and any attachments. = WARNING: Computer viruses can be transmitted via email. The recipient shoul= d check this email and any attachments for the presence of viruses. The com= pany accepts no liability for any damage caused by any virus transmitted by= this email. = www.wipro.com = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 04:40:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A31D28C0F0; Mon, 16 Jun 2008 04:40:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0245B3A691F for ; Mon, 16 Jun 2008 04:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 n-8Vr1zr-dSa for ; Mon, 16 Jun 2008 04:40:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3BBCC3A690A for ; Mon, 16 Jun 2008 04:40:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1B6382053D; Mon, 16 Jun 2008 13:41:04 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-9c-4856514f8b05 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7B6420009; Mon, 16 Jun 2008 13:41:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 13:41:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 13:41:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjPU3bZz9N3bh92QbWe1LDuksy1rwAUbPQQ References: From: "Christer Holmberg" To: "Rockson Li (zhengyli)" , X-OriginalArrivalTime: 16 Jun 2008 11:41:17.0720 (UTC) FILETIME=[E3B98980:01C8CFA5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1902689056==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1902689056== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CFA5.E35ACD1A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CFA5.E35ACD1A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rockson, =20 Ok, now I understand. You are talking about the case where the UAC = doesn't receive the 18x, and then gets confused when it receives the = 199. That can happen no matter whether it's a proxy or UAS that sends = the 199. =20 I guess that is something which could happen, yes, and a UAC could think = a new early dialog has been created. As you say, a way to avoid it would = be to send at least one of the 18x reliable before a 199 is sent.=20 =20 But, I am not sure we want to mandate that, because I don't think = anything will break if this happens. =20 Regards, =20 Chrsiter =20 =20 ________________________________ From: Rockson Li (zhengyli) [mailto:zhengyli@cisco.com]=20 Sent: 16. kes=E4kuuta 2008 4:51 To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Hi Christer, =20 It would be easier for UAS to tell if it sends non-100 1xx response = creating early-dialog before sending 199. However, it's a little bit difficult from UAC's perspective, since the = non-100 1xx response might not be reliable. =20 If UAC does not get , say 180, but get 199 first, it looks like it does = not make any sense. =20 One option is to mandate usage of 100rel, which might be too strict for = this draft. =20 Regards, -Rockson -------------------------------------------------------------------------= ------------------ Date: Sun, 15 Jun 2008 13:52:24 +0200 From: "Christer Holmberg" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt To: "Rockson Zhengyu Li" , Message-ID: =20 Content-Type: text/plain; charset=3D"iso-8859-1" =20 Hi, =20 You wouldn't send a 199 unless you have already sent a non-100 1xx = response, so the early dialog has already been created. =20 Regards, =20 Christer =20 ________________________________ =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Rockson Zhengyu Li Sent: 15. kes?kuuta 2008 14:43 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt =20 Hi, =20 one questions on this draft. =20 Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog = creation. does this draft will normativly change the criteria, excluding 199? =20 If, the answer is Yes, I think it need be stated explicitly in the = draft. =20 =20 =20 thanks =20 Regards, -Rockson =20 =20 =20 ------_=_NextPart_001_01C8CFA5.E35ACD1A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Rockson,
 
Ok,=20 now I understand. You are talking about the case where the UAC doesn't = receive=20 the 18x, and then gets confused when it receives the 199. That can = happen no=20 matter whether it's a proxy or UAS that sends the = 199.
 
I=20 guess that is something which could happen, yes, and a UAC could think a = new=20 early dialog has been created. As you say, a way to = avoid it=20 would be to send at least one of the 18x reliable before a 199 is sent.=20
 
But, I=20 am not sure we want to mandate that, because I don't think anything will = break=20 if this happens.
 
Regards,
 
Chrsiter
 
 

From: Rockson Li (zhengyli)=20 [mailto:zhengyli@cisco.com]
Sent: 16. kes=E4kuuta 2008=20 4:51
To: Christer Holmberg; sip@ietf.org
Subject: = Re: [Sip]=20 I-D ACTION:draft-ietf-sip-199-00.txt

Hi=20 Christer,
 
It = would be easier=20 for UAS to tell if it sends non-100 1xx response creating early-dialog = before=20 sending 199.
However, it's=20 a little bit difficult from UAC's perspective, since the non-100 = 1xx response=20 might not be reliable.
 
If UAC = does not get=20 , say 180, but get 199 first, it looks like it does not make any=20 sense.
 
One = option is to=20 mandate usage of 100rel, which might be too strict for this=20 draft.
 
Regards,
-Rockson
----------------------------------------------= ---------------------------------------------
Date: Sun, 15 Jun 2008 13:52:24 = +0200
From:=20 "Christer Holmberg" <christer.holmberg@ericsson= .com>
Subject:=20 Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt
To: "Rockson Zhengyu = Li"=20 <lzyiii@laszlomail.com>, = ;<sip@ietf.org>
Message-ID:
 = ;<CA9998CD4A020D418654FCDEF4E707DF06B19A2E@esealmw113.eemea.er= icsson.se>
 
Content-Type:=20 text/plain; charset=3D"iso-8859-1"
 
Hi,
 
You wouldn't send a = 199 unless you=20 have already sent a non-100 1xx response, so the early dialog has = already been=20 created.
 
Regards,
 
Christer
 
________________________________
 
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Zhengyu Li
Sent: = 15.=20 kes?kuuta 2008 14:43
To: sip@ietf.org
Subject: Re: [Sip] I-D=20 ACTION:draft-ietf-sip-199-00.txt
 

Hi,
 

one questions on this draft.
 

Since RFC3261 says, non-100 1xx response for INVITE cause = early-dialog=20 creation.
does this draft will normativly change the criteria, = excluding=20 199?
 

If, the answer is Yes, I think it need be stated explicitly in = the=20 draft.
 
 
 
thanks
 

Regards,
-Rockson 
 
 
------_=_NextPart_001_01C8CFA5.E35ACD1A-- --===============1902689056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1902689056==-- From sip-bounces@ietf.org Mon Jun 16 04:42:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9A13A6AA4; Mon, 16 Jun 2008 04:42:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5C73A6AA4 for ; Mon, 16 Jun 2008 04:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 8jgV+-UdAk+B for ; Mon, 16 Jun 2008 04:42:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9A7393A6A55 for ; Mon, 16 Jun 2008 04:42:22 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A76902075A; Mon, 16 Jun 2008 13:43:02 +0200 (CEST) X-AuditID: c1b4fb3c-ac898bb00000193b-b9-485651c6b915 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7FE94204CF; Mon, 16 Jun 2008 13:43:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 13:43:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 13:43:15 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE291800202187E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-03 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgAWxgY1AAU+QSkADEwpDw References: <5D1A7985295922448D5550C94DE2918001FD9C27@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE291800202187E@DEEXC1U01.de.lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 16 Jun 2008 11:43:16.0041 (UTC) FILETIME=[2A3FE390:01C8CFA6] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, My position of the draft is supportive. Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of DRAGE= , Keith (Keith) Sent: 12. kes=E4kuuta 2008 16:50 To: sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 (As SIP WG cochair) The document has now been updated based on comments received. http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-03.txt I will give a few more days for responses to the question of support / no s= upport. Please read the draft and indicate your postion. Regards Keith = > -----Original Message----- > From: Stuart Hoggan [mailto:s.hoggan@CableLabs.com] > Sent: Tuesday, June 10, 2008 11:01 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > = > All, > = > We have updated the document to incorporate feedback received so far. > It now contains a section that helps clarify the motivation. = > Let us know if you have further comments. = > = > -Stuart > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 04, 2008 3:48 AM > > To: sip@ietf.org > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > (As SIP WG cochair) > > = > > This has been raised in the SIP group a couple of times, and we have > not > > yet gained an idea of whether to proceed with it in the SIP > WG or not. > > = > > There have been a couple of technical comments raised in > the past from > > the security experts; my understanding is that these have now been = > > clarified. > > = > > I believe in the past there has been an interested > community that says > > this is useful. It has also been clarified that 3GPP would > like to use > > it in their specifications. > > = > > So could I ask the WG to look at this document, and formally to > indicate > > whether they believe some work with this scope should be > progressed as > a > > SIP WG item. > > = > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > th-02.txt > > = > > So if you support it please indicate to the SIP WG chairs. > > = > > If you have technical concerns (i.e. it should not proceed > because it > is > > technically flawed beyond fixing) then please ideally mail > the list, > > although the SIP WG chairs will also accept input. > > = > > Responses please in 1 calendar week from this date. > > = > > Regards > > = > > Keith > > = > > = > > ________________________________ > > = > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of > > Stuart Hoggan > > Sent: Friday, May 02, 2008 5:15 PM > > To: sip@ietf.org > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > = > > = > > Folks, > > = > > = > > = > > Based on the feedback received in Philadelphia, we have updated = > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the = > > Proxy-Authentication-Info header, including support for multiple > values. > > = > > = > > = > > = > > Any further comments or suggestions will be > appreciated. It would > > also be nice to obtain WG feedback on pursuing this I-D as a WG = > > document. > > = > > = > > = > > Regards, > > = > > Stuart > > = > > = > > = > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use = > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 05:17:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9C63A696B; Mon, 16 Jun 2008 05:17:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C0B3A6881 for ; Mon, 16 Jun 2008 05:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.114 X-Spam-Level: X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_35=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 x8ouPrcbg9pI for ; Mon, 16 Jun 2008 05:17:13 -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 BFAE73A6A8E for ; Mon, 16 Jun 2008 05:17:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,652,1204520400"; d="scan'208";a="11114809" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2008 08:17:53 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5GCHrq5008664; Mon, 16 Jun 2008 08:17:53 -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.13.8) with ESMTP id m5GCHrOD022539; Mon, 16 Jun 2008 12:17:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 08:17:53 -0400 Received: from [10.86.240.88] ([10.86.240.88]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 08:17:52 -0400 Message-ID: <48565A15.6040701@cisco.com> Date: Mon, 16 Jun 2008 08:18:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: X-OriginalArrivalTime: 16 Jun 2008 12:17:52.0817 (UTC) FILETIME=[001AC210:01C8CFAB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3830; t=1213618673; x=1214482673; 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[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-1 99-00.txt |Sender:=20 |To:=20Christer=20Holmberg=20; bh=fYbRJW3Yhmom1fVru1LTm1G2T+KEkp7hV3LfjGfB0AA=; b=AES2/YCYkKe6tmygxyn82ZtKtI181Z4fLqZ+fp3MoDBBXhHBt+aBohnAAf GfprXLK5Vie3TLB5+yYisUP2YhGP3jlVhCY/TWhND4GjDRincZYMlkimAaN5 eAzxFGuTrx; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, "Rockson Li \(zhengyli\)" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't understand the problem here. If the UAC receives the 199 as the first provisional response in a new = dialog, then it will in effect create a new dialog and then immediately = terminate it based on the 199. If the UAC doesn't understand the new semantics of 199 then it will = treat it as an arbitrary 1xx response, and create a new dialog that then = will have to time out. But that is no different than if the 18x response = had not been lost. Paul Christer Holmberg wrote: > Hi Rockson, > = > Ok, now I understand. You are talking about the case where the UAC = > doesn't receive the 18x, and then gets confused when it receives the = > 199. That can happen no matter whether it's a proxy or UAS that sends = > the 199. > = > I guess that is something which could happen, yes, and a UAC could think = > a new early dialog has been created. As you say, a way to avoid it would = > be to send at least one of the 18x reliable before a 199 is sent. > = > But, I am not sure we want to mandate that, because I don't think = > anything will break if this happens. > = > Regards, > = > Chrsiter > = > = > = > ------------------------------------------------------------------------ > *From:* Rockson Li (zhengyli) [mailto:zhengyli@cisco.com] > *Sent:* 16. kes=E4kuuta 2008 4:51 > *To:* Christer Holmberg; sip@ietf.org > *Subject:* Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > = > Hi Christer, > = > It would be easier for UAS to tell if it sends non-100 1xx response = > creating early-dialog before sending 199. > However, it's a little bit difficult from UAC's perspective, since the = > non-100 1xx response might not be reliable. > = > If UAC does not get , say 180, but get 199 first, it looks like it does = > not make any sense. > = > One option is to mandate usage of 100rel, which might be too strict for = > this draft. > = > Regards, > -Rockson > -------------------------------------------------------------------------= ------------------ > Date: Sun, 15 Jun 2008 13:52:24 +0200 > From: "Christer Holmberg" > > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > To: "Rockson Zhengyu Li" >, > > Message-ID: > > > = > Content-Type: text/plain; charset=3D"iso-8859-1" > = > Hi, > = > You wouldn't send a 199 unless you have already sent a non-100 1xx = > response, so the early dialog has already been created. > = > Regards, > = > Christer > = > ________________________________ > = > From: sip-bounces@ietf.org = > [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Zhengyu Li > Sent: 15. kes?kuuta 2008 14:43 > To: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > = > = > Hi, > = > = > one questions on this draft. > = > = > Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog = > creation. > does this draft will normativly change the criteria, excluding 199? > = > = > If, the answer is Yes, I think it need be stated explicitly in the draft. > = > = > = > thanks > = > = > Regards, > -Rockson = > = > = > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 05:21:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FF83A6ABD; Mon, 16 Jun 2008 05:21:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6853A6AC3 for ; Mon, 16 Jun 2008 05:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7uLrP4n-t4G for ; Mon, 16 Jun 2008 05:21:44 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 042D33A6ABD for ; Mon, 16 Jun 2008 05:21:44 -0700 (PDT) X-AuditID: cb5bdd57-a76aabb0000065b1-87-48565afada8a Received: from blr-ec-aa01.wipro.com (unknown [10.201.18.41]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id 1E26A4E4005 for ; Mon, 16 Jun 2008 17:52:18 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 17:51:57 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 17:51:56 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 17:51:55 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE06F5C697@BLR-EC-MBX02.wipro.com> In-Reply-To: <48565A15.6040701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjPqxhAcTjN3MkGTLW/04esSekLpgAACxPQ References: <48565A15.6040701@cisco.com> From: To: , X-OriginalArrivalTime: 16 Jun 2008 12:21:56.0826 (UTC) FILETIME=[918B93A0:01C8CFAB] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, zhengyli@cisco.com Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ya, I agree with Paul. I was about to write the similar thing that 199 will= be treated as per non 100 1xx response as 3261 says (in case UAC does not = understand 199 message). = Best Regards, Ashish Saxena -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul = Kyzivat Sent: Monday, June 16, 2008 5:48 PM To: Christer Holmberg Cc: sip@ietf.org; Rockson Li (zhengyli) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt I don't understand the problem here. If the UAC receives the 199 as the first provisional response in a new dial= og, then it will in effect create a new dialog and then immediately termina= te it based on the 199. If the UAC doesn't understand the new semantics of 199 then it will treat i= t as an arbitrary 1xx response, and create a new dialog that then will have= to time out. But that is no different than if the 18x response had not bee= n lost. Paul Christer Holmberg wrote: > Hi Rockson, > = > Ok, now I understand. You are talking about the case where the UAC = > doesn't receive the 18x, and then gets confused when it receives the = > 199. That can happen no matter whether it's a proxy or UAS that sends = > the 199. > = > I guess that is something which could happen, yes, and a UAC could = > think a new early dialog has been created. As you say, a way to avoid = > it would be to send at least one of the 18x reliable before a 199 is sent. > = > But, I am not sure we want to mandate that, because I don't think = > anything will break if this happens. > = > Regards, > = > Chrsiter > = > = > = > ---------------------------------------------------------------------- > -- > *From:* Rockson Li (zhengyli) [mailto:zhengyli@cisco.com] > *Sent:* 16. kes=E4kuuta 2008 4:51 > *To:* Christer Holmberg; sip@ietf.org > *Subject:* Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > = > Hi Christer, > = > It would be easier for UAS to tell if it sends non-100 1xx response = > creating early-dialog before sending 199. > However, it's a little bit difficult from UAC's perspective, since the = > non-100 1xx response might not be reliable. > = > If UAC does not get , say 180, but get 199 first, it looks like it = > does not make any sense. > = > One option is to mandate usage of 100rel, which might be too strict = > for this draft. > = > Regards, > -Rockson > ---------------------------------------------------------------------- > --------------------- > Date: Sun, 15 Jun 2008 13:52:24 +0200 > From: "Christer Holmberg" > > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > To: "Rockson Zhengyu Li" >, > > Message-ID: > = > sson.se>> > = > Content-Type: text/plain; charset=3D"iso-8859-1" > = > Hi, > = > You wouldn't send a 199 unless you have already sent a non-100 1xx = > response, so the early dialog has already been created. > = > Regards, > = > Christer > = > ________________________________ > = > From: sip-bounces@ietf.org = > [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Zhengyu Li > Sent: 15. kes?kuuta 2008 14:43 > To: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > = > = > Hi, > = > = > one questions on this draft. > = > = > Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog = > creation. > does this draft will normativly change the criteria, excluding 199? > = > = > If, the answer is Yes, I think it need be stated explicitly in the draft. > = > = > = > thanks > = > = > Regards, > -Rockson > = > = > = > = > ---------------------------------------------------------------------- > -- > = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 05:38:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209523A6AD5; Mon, 16 Jun 2008 05:38:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FEC3A6A8E for ; Mon, 16 Jun 2008 05:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 AAn7eiSQpvYY for ; Mon, 16 Jun 2008 05:38:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 892943A6AD5 for ; Mon, 16 Jun 2008 05:38:28 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m5GCcwOJ029388; Mon, 16 Jun 2008 07:38:59 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 07:38:35 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 14:38:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 14:38:32 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918002021E08@DEEXC1U01.de.lucent.com> In-Reply-To: <18515.50598.566583.38032@taimen.test.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjOIrKbnHpObo7FTs29e6gxRHtBJgBiusnA References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><48527F1A.90302@cisco.com><1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com><4852C62F.4030007@cisco.com><1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com><4852E0B2.3000306@cisco.com><18515.27718.204853.637776@taimen.test.fi> <18515.50598.566583.38032@taimen.test.fi> From: "DRAGE, Keith \(Keith\)" To: "Juha Heinanen" , "Christer Holmberg" X-OriginalArrivalTime: 16 Jun 2008 12:38:33.0305 (UTC) FILETIME=[E37E3490:01C8CFAD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: sip@ietf.org, Paul Kyzivat , Francois Audet Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org As you can never tell whether a UA is a UA by itself, or part of a B2BUA, this must remain general UA behaviour. The most you can do is add some informative material that essentially says this is useful for B2BUAs only. Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Juha Heinanen > Sent: Saturday, June 14, 2008 2:21 PM > To: Christer Holmberg > Cc: sip@ietf.org; Paul Kyzivat; Francois Audet > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > Christer Holmberg writes: > > > Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a > > logical entity that receives a request and > processes it as a > > user agent server (UAS). In order to determine > how the request > > should be answered, it acts as a user agent > client (UAC) and > > generates requests. Unlike a proxy server, it > maintains dialog > > state and must participate in all requests sent > on the dialogs > > it has established. > > > > We could of course say something like: > > > > "UAS, when part of a B2BUA" > > according to the B2BUA definition: > > Since it is a concatenation of a UAC and > UAS, no explicit definitions are needed for its behavior. > > this means that there is no need to say anything special > about 199 either. b2bus in terms of protocol specification, > is just an uas like any other. > > -- juha > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 06:11:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E903A6AC3; Mon, 16 Jun 2008 06:11:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C414F3A6AA4 for ; Mon, 16 Jun 2008 06:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 wJNF6jifE4vw for ; Mon, 16 Jun 2008 06:11:25 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 955573A6A23 for ; Mon, 16 Jun 2008 06:11:25 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B5309204DE; Mon, 16 Jun 2008 15:12:05 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-8e-485666a5d60c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 927CB207B7; Mon, 16 Jun 2008 15:12:05 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 15:12:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 15:12:18 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE2918002021E08@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjOIrKbnHpObo7FTs29e6gxRHtBJgBiusnAAAE2Q8A= References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><48527F1A.90302@cisco.com><1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com><4852C62F.4030007@cisco.com><1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com><4852E0B2.3000306@cisco.com><18515.27718.204853.637776@taimen.test.fi> <18515.50598.566583.38032@taimen.test.fi> <5D1A7985295922448D5550C94DE2918002021E08@DEEXC1U01.de.lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Juha Heinanen" X-OriginalArrivalTime: 16 Jun 2008 13:12:19.0302 (UTC) FILETIME=[9B14D060:01C8CFB2] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Paul Kyzivat , Francois Audet Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >As you can never tell whether a UA is a UA by itself, or part of a B2BUA, this must remain general UA behaviour. > >The most you can do is add some informative material that essentially says this is useful for B2BUAs only. My proposal was to simply talk about a UA which creates multiple To tags. Regards, Christer > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Juha Heinanen > Sent: Saturday, June 14, 2008 2:21 PM > To: Christer Holmberg > Cc: sip@ietf.org; Paul Kyzivat; Francois Audet > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > Christer Holmberg writes: > > > Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a > > logical entity that receives a request and > processes it as a > > user agent server (UAS). In order to determine > how the request > > should be answered, it acts as a user agent > client (UAC) and > > generates requests. Unlike a proxy server, it > maintains dialog > > state and must participate in all requests sent > on the dialogs > > it has established. > > > > We could of course say something like: > > > > "UAS, when part of a B2BUA" > > according to the B2BUA definition: > > Since it is a concatenation of a UAC and > UAS, no explicit definitions are needed for its behavior. > > this means that there is no need to say anything special about 199 > either. b2bus in terms of protocol specification, is just an uas like > any other. > > -- juha > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 06:42:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B2C3A6ADC; Mon, 16 Jun 2008 06:42:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5DC3A6AC3 for ; Mon, 16 Jun 2008 06:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_35=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 Hyf4d3UeB9eA for ; Mon, 16 Jun 2008 06:42:26 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id ACC403A6AEB for ; Mon, 16 Jun 2008 06:42:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,652,1204482600"; d="scan'208";a="110093412" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 16 Jun 2008 19:13:04 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5GDh2DY016426; Mon, 16 Jun 2008 21:43:02 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5GDe5FJ006491; Mon, 16 Jun 2008 13:43:02 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 21:40:50 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 21:40:52 +0800 Message-ID: In-Reply-To: <48565A15.6040701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjPqwIPCXUUELIOTyOBb8KK0BO1RgACo1Ig References: <48565A15.6040701@cisco.com> From: "Rockson Li (zhengyli)" To: "Paul Kyzivat (pkyzivat)" , "Christer Holmberg" X-OriginalArrivalTime: 16 Jun 2008 13:40:50.0938 (UTC) FILETIME=[974BBDA0:01C8CFB6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4493; t=1213623783; x=1214487783; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20RE=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-1 99-00.txt |Sender:=20; bh=6Xrddh7T1mXN9xeDC62r1Y8ZJtYYFvBjE60/IdJkxVI=; b=eo1lVHfoDD59+og6dTOLpTL36MH9mhxtmHwBG5P0QZRp6doWgH1Tcqc8cA oYV0d6OTohp0uhx97DGnPONiglV5zGOLozBgf2DKPnlImxG7Qzq2MZ94PbQZ 2wUx0+3NbIJAc90rrvbueGwjorIpCQlnpgO67uwveLYYboiGAhfeg=; Authentication-Results: hkg-dkim-2; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The issue here is UAS may send 199 to terminate early-dialog with the inten= tion to help UAC claiming resource May bring unexpected overhead (case 1 && 2 as in Paul's mail) or confusion = (case 1 in Paul's mail, ordered to terminate non-existed early-dialog) Thanks Rockson -----Original Message----- From: Paul Kyzivat (pkyzivat) = Sent: Monday, June 16, 2008 8:18 PM To: Christer Holmberg Cc: Rockson Li (zhengyli); sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt I don't understand the problem here. If the UAC receives the 199 as the first provisional response in a new dial= og, then it will in effect create a new dialog and then immediately termina= te it based on the 199. If the UAC doesn't understand the new semantics of 199 then it will treat i= t as an arbitrary 1xx response, and create a new dialog that then will have= to time out. But that is no different than if the 18x response had not bee= n lost. Paul Christer Holmberg wrote: > Hi Rockson, > = > Ok, now I understand. You are talking about the case where the UAC = > doesn't receive the 18x, and then gets confused when it receives the = > 199. That can happen no matter whether it's a proxy or UAS that sends = > the 199. > = > I guess that is something which could happen, yes, and a UAC could = > think a new early dialog has been created. As you say, a way to avoid = > it would be to send at least one of the 18x reliable before a 199 is sent. > = > But, I am not sure we want to mandate that, because I don't think = > anything will break if this happens. > = > Regards, > = > Chrsiter > = > = > = > ---------------------------------------------------------------------- > -- > *From:* Rockson Li (zhengyli) [mailto:zhengyli@cisco.com] > *Sent:* 16. kes=E4kuuta 2008 4:51 > *To:* Christer Holmberg; sip@ietf.org > *Subject:* Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > = > Hi Christer, > = > It would be easier for UAS to tell if it sends non-100 1xx response = > creating early-dialog before sending 199. > However, it's a little bit difficult from UAC's perspective, since the = > non-100 1xx response might not be reliable. > = > If UAC does not get , say 180, but get 199 first, it looks like it = > does not make any sense. > = > One option is to mandate usage of 100rel, which might be too strict = > for this draft. > = > Regards, > -Rockson > ---------------------------------------------------------------------- > --------------------- > Date: Sun, 15 Jun 2008 13:52:24 +0200 > From: "Christer Holmberg" > > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > To: "Rockson Zhengyu Li" >, > > Message-ID: > = > sson.se>> > = > Content-Type: text/plain; charset=3D"iso-8859-1" > = > Hi, > = > You wouldn't send a 199 unless you have already sent a non-100 1xx = > response, so the early dialog has already been created. > = > Regards, > = > Christer > = > ________________________________ > = > From: sip-bounces@ietf.org = > [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Zhengyu Li > Sent: 15. kes?kuuta 2008 14:43 > To: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > = > = > Hi, > = > = > one questions on this draft. > = > = > Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog = > creation. > does this draft will normativly change the criteria, excluding 199? > = > = > If, the answer is Yes, I think it need be stated explicitly in the draft. > = > = > = > thanks > = > = > Regards, > -Rockson > = > = > = > = > ---------------------------------------------------------------------- > -- > = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 07:15:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76043A6879; Mon, 16 Jun 2008 07:15:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746EC3A682A for ; Mon, 16 Jun 2008 07:15:48 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgrAq5OjLdvU for ; Mon, 16 Jun 2008 07:15:47 -0700 (PDT) Received: from dlxapp2.laszlomail.com (dlxapp2.laszlomail.com [168.75.100.14]) by core3.amsl.com (Postfix) with ESMTP id B7D4B3A6879 for ; Mon, 16 Jun 2008 07:15:47 -0700 (PDT) Received: from dlxapp2 (localhost [127.0.0.1]) by dlxapp2.laszlomail.com (8.14.0/8.14.0) with ESMTP id m5GEGfgn001313 for ; Mon, 16 Jun 2008 07:16:41 -0700 Received: from [116.233.144.173] by gowebtop.com with HTTP; Mon, 16 Jun 2008 07:16:38 -0700 Date: Mon, 16 Jun 2008 07:16:38 -0700 (PDT) From: Rockson Zhengyu Li To: sip@ietf.org Message-ID: <1048079783.296891213625801939.JavaMail.lzyiii@localhost> MIME-Version: 1.0 User-Agent: Laszlo Mail 2 X-Originating-IP: [116.233.144.173] Content-Disposition: inline Subject: [Sip] question on draft-ietf-sipping-nat-scenarios-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, having reading draft-ietf-sipping-nat-scenarios-08, I got one question on sec 3.2.1. Symmetric RTP/RTCP. In this section, it says Symmetric RTP/RTCP is used to handle media tranversal issue in sec2, but how does this be achieved? I think Symmetric RTP/RTCP has nothing to do with addr/port advertisement in SDP, addr/port will still be the private addr/port behind NAT even with Symmetric RTP/RTCP. And why it should be used ONLY when one participant is in public network, I think if NAT is of type Endpoint-Independent Mapping as per RFC4787, it should look fine. Thanks Regards, -Rockson _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 09:08:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CE53A697C; Mon, 16 Jun 2008 09:08:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D1E3A696C for ; Mon, 16 Jun 2008 09:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 vtz0JOIFO7p6 for ; Mon, 16 Jun 2008 09:08:46 -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 03F143A691E for ; Mon, 16 Jun 2008 09:08:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,653,1204520400"; d="scan'208";a="11141676" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2008 12:09:24 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5GG9OUY001233; Mon, 16 Jun 2008 12:09:24 -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.13.8) with ESMTP id m5GG9OOb029758; Mon, 16 Jun 2008 16:09:24 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.1830); Mon, 16 Jun 2008 12:09:24 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 12:09:24 -0400 Message-ID: <48569060.3060305@cisco.com> Date: Mon, 16 Jun 2008 12:10:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: sreerekha.shenoy@wipro.com References: In-Reply-To: X-OriginalArrivalTime: 16 Jun 2008 16:09:24.0047 (UTC) FILETIME=[57EC3DF0:01C8CFCB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20552; t=1213632564; x=1214496564; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20sreerekha.shenoy@wipro.com; bh=KOHN2mByoJ7UhtCoObeOB8gpjqeJ/r+rJVKHDbnavxU=; b=pzMKXmpcsqc/Di89N93gqM8jxkbKBXF8FSa7/0ChUrxOSO1T6gaWYuM2tz l+U09sdZP7dt/uX60joBhKc4Afzmao1KhIJ9TlL2wrrKSBcc41s54D8iA/+6 sP1+6bsmMo; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, christer.holmberg@ericsson.com Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org sreerekha.shenoy@wipro.com wrote: > Thanks Christer, > We have a query on our basic understanding of this draft. > = > I too had the same query as Ashish, I can rephrase it for all of us. > What we mean to ask is that, considering the scenario shown by the SIP = > msg flow below, *at what point *does the proxy decide to send 199 = > response *and on which *call legs. I believe the time to send a 199 is when the proxy has received a final = error response and has elected *not* to forward it on at that time - in = hopes of getting a better response. The 199 should be sent upstream using the to-tag from the final response = that is not being forwarded. > For e.g. in the scenario below, when proxy receives 403 on leg 2, and it = > is yet to receive responses on leg 3 and 4. In this case, the proxy = > cannot send a 199 to the UAC (is my understanding, please correct if wron= g). IMO you are wrong. What makes you think this isn't ok? > Also after having received 5xx and 6xx on the leg 3 and 4, there is no = > use sending 199 now because the best final response sent to UAC is = > sufficient to indicate that the leg 3 and 4 are terminated. At the time the 5xx is received there is still another possibility, so = the 199 is appropriate. When the 6xx is received, there are no more legs, and presumably the 6xx = prevents the proxy from generating any more legs. It should be sending a = final response immediately at that time, so I see no value in a 199 there. BUT if the proxy takes a lenient view of how to handle 6xx (treating it = as advisory rather than definitive regarding *global* failure) then it = might decide that it now will be trying another destination. If so, the = 199 response might be appropriate. But the call flow is then incomplete. Thanks, Paul > Please correct us if we are missing some hidden lines in the draft w.r.t = > our understanding. > = > Thanks, > Best Regards, > Rekha > (ESN : 6-877-5834) > (PSTN : 81168) > = > = > ------------------------------------------------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of = > *Christer Holmberg > *Sent:* Monday, June 16, 2008 1:42 PM > *To:* Ashish Saxena (WT01 - Telecom Equipment); pkyzivat@cisco.com; = > Dale.Worley@comcast.net > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Draft submission: draft-ietf-sip-199-00 > = > = > Hi, > = > The way the "best" final response code is chosen is described in RFC = > 3261, and the intention of 199 is not to change that. > = > Regarding whether a 199 will be sent for leg 4: if the proxy is now = > going to send a "best" final response I guess it doesn't need to send = > 199 for leg 4. > = > Regards, > = > Christer > = > = > = > = > ------------------------------------------------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of = > *ashish.hsaxena@wipro.com > *Sent:* 16. kes=E4kuuta 2008 10:32 > *To:* pkyzivat@cisco.com; Dale.Worley@comcast.net > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Draft submission: draft-ietf-sip-199-00 > = > Referring to introduction part in the draft. > " At some point the proxy uses a specified mechanism to determine the = > "best" final response code, and forwards that final response upstream = > towards the sender of the associated request." > = > Considering a scenario where all the forks have failed in yielding a 2xx = > response from different UASes (UAS2 , 3 & 4 in the diagram) with = > different error codes, how will the proxy determine the "best" final = > response and to which leg would it send the best final response. What = > would happen after 199 to leg 4? > = > UAC P1 UAS_2 UAS_3 UAS_4 > = > --- INVITE ------> > --- INVITE (leg 2) -> > --- INVITE (leg 3) ----------> > --- INVITE (leg 4) -------------------> > <-- 18x (leg 2) ----- > <-- 18x (leg 2) -- > <-- 18x (leg 3) -------------- > <-- 18x (leg 3) -- > <-- 18x (leg 4) ----------------------- > <-- 18x (leg 4) -- > <-- *4xx* (leg 2) ----- > <-- 199 (leg 2) -- > <-- *5xx *(leg 3) -------------- > <-- 199 (leg 3) -- > <-- *6xx *(leg 4) ----------------------- > <-- 199 (leg 4) -- > = > Best Regards, > Ashish Saxena > 877-5570 > = > = > = > ------------------------------------------------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of = > *Attila Sipos > *Sent:* Saturday, June 14, 2008 9:30 PM > *To:* Paul Kyzivat; Dale.Worley@comcast.net > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Draft submission: draft-ietf-sip-199-00 > = > = > >>However I am still scratching my head about the UAS sending a 199. Whi= le > >>I see no reason to forbid it I'm trying to find a situation when it > >>would be helpful. > = > It may or may not be helpful but as you say, you can > see no reason to forbid it. > = > Why restrict it if the restriction isn't needed? > = > As someone has pointed out, a B2BUA scenario might benefit > from 199. In fact, any kind of SIP gateway might benefit. > = > > This is one of those cases that could probably benefit from > > simulation to judge the merits. My gut feel is that the costs > > of the UAS sending the 199 outweigh the benefits. > = > If the UAS wants to send it, that is a decision for > them - not something that needs to be prevented. > = > SIP forking, in the technical sense of sending a > response with a different to-tag, is always legal. > So, any UA which has used forking > should also be able to use 199. > = > I don't think we need to include any specific text about UAS > except to say that a UAS can use it if the UAS has created > the forking. > = > Regards, > = > Attila > = > = > = > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Paul Kyzivat > Sent: Fri 13/06/2008 15:07 > To: Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > = > This all sounds like good stuff. > = > However I am still scratching my head about the UAS sending a 199. While > I see no reason to forbid it I'm trying to find a situation when it > would be helpful. The only case I have been able to think of is: > = > There is a forking proxy upstream of the UAS, but it doesn't > support 199. Yet it may delay the final response while it > tries other forks. So the UAS sending the 199 makes up for > the inadequacy of the forking proxy. > = > The trouble with this is that it is inefficient in many cases. If each > proxy that forks also supports the sending of 199, and the UAS doesn't > send one, then we avoid sending the message except in cases where it is > helpful. If the UAS always sends it we have increased the message count > by one for all failing calls. And the majority of failing calls get no > benefit from a 199. > = > This is one of those cases that could probably benefit from simulation > to judge the merits. My gut feel is that the costs of the UAS sending > the 199 outweigh the benefits. Barring some analysis to the contrary I > think I would say that a UAS SHOULD NOT send a 199. Or perhaps MAY send, > but without any guidance of when. > = > Paul > = > Dale.Worley@comcast.net wrote: > > Here are some comments on this I-D. I don't think that any of them > > modify our understanding of the proposal. I guess this is very terse; > > please use these suggestions as you see fit. > > > > * Abstract > > > > Clarify: > > > > This specification defines a new SIP response code, 199 Early > > Dialog Terminated, which a SIP entity can use to indicate upstream > > that an early dialog has been terminated. The response code can be > > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > > an early dialog has been terminated. As the 199 response is a > > provisional response, often the UAC will receive it before > > receiving a final response to its request. > > > > * Section 1 > > > > When a forking proxy receives a non-2xx final response, it does not > > always immediately forward the response upstream towards the sender > > of the associated request. Instead, the forking proxy "stores" it > > and waits for further final responses from remote destinations where > > the forked request was forwarded. > > > > The text does not allow for serial forking, only parallel forking, > > which might be confusing to people who are more aware of serial > > forking. So amend the last sentence to: > > > > Instead, the forking proxy "stores" it and waits for further final > > responses from remote destinations where the forked request was > > forwarded, and possibly forwards the request to additional > > destinations. > > > > Also, Avoid using "..." except when indicating that the word is used > > in a non-standard way or that one is discussing the word itself: > > > > Instead, the forking proxy "stores" it [...] > > > > should be: > > > > Instead, the forking proxy stores it [...] > > > > * Section 3. > > > > REQ 1: It must be possible to indicate to the UAC that an early > > dialog has been terminated before a final response is sent. > > > > Oddly, though everyone thinks they understand this sentence, it > > doesn't really say what we want. To really ensure that the UAC > > understands the early dialog has been terminated before the UAS sends > > a final response, the UAS would have to send 199 *and get the PRACK > > saying that it was received* before sending a final response. This may > > well be worse than the present state of affairs. > > > > What we really mean is: > > > > REQ 1: It must be possible for a UAS or proxy to send an indication > > to the UAC that an early dialog has been terminated, which > > indication will not be delayed waiting for a final response from > > any UAS. > > > > * Section 4 > > > > When a client receives a 199 Early Dialog Terminated provisional > > response it MAY release resources and procedures associated with the > > early dialog the 199 response is received on. > > > > Amend to clarify the meaning of 199 independently of the consequences > > of that meaning: > > > > When a client receives a 199 Early Dialog Terminated provisional > > response, it has positive knowledge that the UAS that created the > > early dialog has terminated it, and so the client MAY release > > resources and procedures associated with the early dialog for which > > the 199 response is received. > > > > * Section 4 > > > > Add this paragraph before the last paragraph: > > > > A UAC that receives a 199 response for an early dialog MUST NOT > > send any further requests on that dialog, except for a PRACK if the > > 199 response was sent reliably, and PRACKs for other reliable > > provisional responses that are to be acknowledged. > > > > This is copied from section 7 (Backward Compatibility), but since it > > is a constraint on UACs, it should also be stated in this section. > > > > * Section 4 > > > > The UAC MAY use additional information (for example the final > > response which triggered the 199 response) received in the 199 > > response when initiating new sessions, if it is possible to avoid t= he > > new session initiation request to be rejected. > > > > What is the meaning of the final clause? > > > > * Section 5 > > > > Add "early" as marked: > > > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > > SIP final response, as specified in [RFC3261]. In addition, prior > > to sending the non-2xx SIP final response, the UAS MAY send a 199 > > response to indicate that the dialog is being terminated. > > > > This clarifies that 199 cannot be used to terminate a confirmed > > dialog. > > > > (The reason a UAS may want to send a 199 is to provide this > > information even when the upstream proxy does not support 199.) > > > > There is a subtlty to the second sentence: > > > > Sending the 199 *before* the final response is not necessary due to > > the semantics of 199 (as it will probably reach the UAC first anyway, > > and it would not matter if it did not), but rather to prevent the > > upstream proxy from generating a 199 based on the final response, and > > then to transmit the UAS's 199 immediately after -- if the UAS sends > > the 199 first, any upstream proxy will (most likely) see the 199 > > before seeing the final response (which might induce the proxy to send > > its own 199). > > > > * Section 6 > > > > When a forking proxy receives a non-2xx final response which > > terminates one or more early dialogs and the proxy does not intend = to > > forward the final response immediately (due to the rules for a > > forking proxy) it MUST send a 199 provisional response, for each > > associated early dialog that it can associate with the final > > response, upstream towards the sender of the associated request. > > > > Clarify, and note that if the proxy has already passed a 199 for an > > early dialog, it need not generate one itself. Also, I've reduced > > MUST to SHOULD, because (as the following NOTE explains), the proxy > > may not know of all early dialogs which are terminated by the final > > response. > > > > [...] it SHOULD initiate a 199 provisional response upstream > > towards the sender of the associated request, for each terminated > > early dialog, excepting those for which it has already transmitted > > a 199 response. > > > > Note that the "already transmitted 199 responses" may have come from > > downstream proxies as well as downstream UASs, so this consideration > > applies even if we do not allow UASs to send 199s. > > > > * Section 7 > > > > Since all SIP entities involved in a session setup do not necessari= ly > > support the specific meaning of the 199 Early Dialog Terminated > > provisional response, the sender of the response MUST be prepared to > > receive SIP requests associated with the dialog for which the 199 > > response was sent. > > > > This situation can also result due to race conditions. Amend to: > > > > Because of race conditions and because the client may not support t= he > > specific meaning of the 199 provisional response, the sender of the > > response MUST be prepared to receive SIP requests associated with > > the dialog for which the 199 response was sent. > > > > And add a qualifier to this sentence: > > > > If such request is received, and the receiver maintains state of > > the dialogs, the receiver MUST reply to such requests with a 481 > > final response (unless another error response is more appropriate). > > > > * Section 7 > > > > Remove "..." from this sentence and add "even" as marked: > > > > The 199 Early Dialog Terminated response code MUST NOT replace a > > final response. A final response MUST always be sent, *even* after > > one or many 199 Early Dialog Terminated provisional responses have > > been sent. > > > > * Section 8 > > > > Clarify this sentence to: > > > > The 199 Early Dialog Terminated response code allows a SIP entity > > to indicate to upstream entities that a specific early dialog has > > been terminated, before a final response reaches the upstream > > entities. > > > > Add the following: > > > > The early dialog that has been terminated is identified by the Call= -Id > > header and the to-tag value of the 199 response. > > > > Future standards may define optional additional information carried > > in the headers and/or body of the response. > > > > * Section 9 > > > > A 199 Early Dialog Terminated provisional response MUST NOT contain= a > > new SDP offer/answer message body, but the sender of the response M= AY > > insert a copy of a previously sent offer/answer message body as > > otherwise allowed by the offer/answer rules for a provisional > > response. > > > > This rule seems excessively strict, as it seems OK to send a new SDP > > answer in a 199, even if the dialog will be immediately terminated. > > Certainly, the UAC cannot tell the difference, as there could have > > been a previous but lost 1xx response carrying the same SDP. > > > > The interaction of 199 and SDP probably needs further study... > > > > * Section 11 > > > > Nit: Use "reject" here rather than "rejects": > > > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response. > > > > Here is a modification of the example, showing how a UAS can send a > > 199, and how the proxy handles it. (You may or may not want to use > > this.) I've also added the ACK's for the 4xx's, which were missing in > > the original. > > > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > > Terminated associated with UAS_2's dialog towards the UAC. P1 > > transmits UAS_3's 199, and so does not initiate one itself for > > UAS_3's dialog when it receives UAS_3's 4xx response. > > > > UAC P1 UAS_2 UAS_3 UAS_4 > > > > --- INVITE ------> > > --- INVITE (leg 2) -> > > --- INVITE (leg 3) ----------> > > --- INVITE (leg 4) -------------------> > > <-- 18x (leg 2) ----- > > <-- 18x (leg 2) -- > > <-- 18x (leg 3) -------------- > > <-- 18x (leg 3) -- > > <-- 18x (leg 4) ----------------------- > > <-- 18x (leg 4) -- > > <-- 4xx (leg 2) ----- > > <-- 199 (leg 2) -- > > --- ACK (leg 2) ----> > > <-- 199 (leg 3) -------------- > > <-- 199 (leg 3) -- > > <-- 4xx (leg 3) -------------- > > --- ACK (leg 3) -------------> > > <-- 200 (leg 4) ----------------------- > > <-- 200 (leg 4) -- > > --- ACK (leg 4) -> > > --- ACK (leg 4) ----------------------> > > > > Dale > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = > = > = > . > = > * Please do not print this email unless it is absolutely necessary. * > = > The information contained in this electronic message and any attachments = > to this message are intended for the exclusive use of the addressee(s) = > and may contain proprietary, confidential or privileged information. If = > you are not the intended recipient, you should not disseminate, = > distribute or copy this e-mail. Please notify the sender immediately and = > destroy all copies of this message and any attachments. > = > WARNING: Computer viruses can be transmitted via email. The recipient = > should check this email and any attachments for the presence of viruses. = > The company accepts no liability for any damage caused by any virus = > transmitted by this email. > = > www.wipro.com > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 10:30:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87C23A6AEB; Mon, 16 Jun 2008 10:30:05 -0700 (PDT) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D28AE3A6816; Mon, 16 Jun 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080616173001.D28AE3A6816@core3.amsl.com> Date: Mon, 16 Jun 2008 10:30:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-15.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-15.txt Pages : 48 Date : 2008-6-16 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its Registrar. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-outbound-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-16102640.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jun 16 16:22:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBEE3A6987; Mon, 16 Jun 2008 16:22:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA593A6987 for ; Mon, 16 Jun 2008 16:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 Y6hhl3rPBqDL for ; Mon, 16 Jun 2008 16:22:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2F5A93A6833 for ; Mon, 16 Jun 2008 16:22:44 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5GNNOUe023536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 16 Jun 2008 18:23:25 -0500 Message-Id: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 18:23:18 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The SIP working group spun off from the MMUSIC working group when we realized that the SIP work was reasonably separable from the other work going on in MMUSIC. The SIP working group first met officially at IETF 46 in November 1999, although we did have an earlier interim meeting. This means that the fall 1999 meeting will be our 10th anniversary. In addition to having a big party, I'd also like to plan for this being the last meeting of the SIP working group as it is now defined. Ten years is long enough. It's time we restructured. There will probably still be people who want to change, revise, extend, or otherwise manipulate the family of SIP specifications after 2009. So what should we do? How should we organize to get those needs met? Rest assured, we'll be having further discussions on this topic in the coming months. But I'd like to start the discussion now. By November 2009, I fully expect SIP to have completed the majority of currently chartered items. Between now and then, we'll probably also take on and complete a bit of new work (although I plan to be very resistant to new work). I also expect that there are a few items on our charter now that we're not going to finish. It may well be that some of those items need a different organizational structure to progress than what we have. Or maybe they don't need doing. Further, I've come to believe that most working groups should be shorter-lived and tightly constrained by their charters to produce a single concise set of deliverables. There's still a need for a longer- lived thing that maintains architectural oversight. I've come to believe that this is the "area", not the working group. Let's start the recap by looking at the current charter of the SIP WG. I've eliminated the WGLC milestones to shorten the list, as each has a following IESG milestone. Note that there's a Feb 2008 milestone for "Revise Charter". You can consider this topic the first installment on that milestone, even though it is a bit late. 1) Jul 2007 Location Conveyance with SIP to IESG (PS) 2) Aug 2007 Connection reuse mechanism to IESG (PS) 3) Sep 2007 Session Policies to IESG as PS 4) Sep 2007 Example security flows to IESG (Informational) 5) Oct 2007 New resource priority namespaces for DISA to IESG (PS) 6) Nov 2007 Requirements for media keying to IESG (Informational) 7 )Dec 2007 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to IESG (PS) 8) Dec 2007 Roadmap for SIP to IESG (Informational) 9) Dec 2007 Using SAML for SIP to IESG (PS) 10) Dec 2007 Extension for use in etags in conditional notification to IESG (PS) 11) Feb 2008 Identify requirements for test matrix to move SIP to Draft Standard 12) Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) 13) Feb 2008 Revise charter 14) Feb 2008 Establishment of secure media sessions using DTLS-SRTP to IESG (PS) 15) Apr 2008 MIME body handling in SIP to IESG (PS) 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG (PS) 17) Jul 2008 Mechanisms for UA initiated privacy to IESG (BCP) 18) Aug 2008 Guidelines for double route recording to IESG (BCP) 19) Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) 20) Sep 2008 X.509 extended key usage for SIP to IESG (PS) 21) Nov 2008 Termination of early dialog prior to final response to IESG (PS) Looking at this, we have a couple of discrete tasks that I think might make the basis for different narrowly-scoped working groups. We've also got a lot of stuff that we're late on delivering! 1) SIP WG (to finish by end of 2009) gets the bulk of these items. 2) SIP Draft Standard WG: Takes the milestone of "Identify requirements for test matrix to move SIP to Draft Standard" and all of the follow-on work needed to move SIP from Proposed to Draft on the standards track. There's certainly enough work here for a dedicated working group, with the last milestone being something like "Deliver SIP as a Draft Standards Document to IESG". We may wish to consider whether we really want to go this route or whether we should instead be thinking of a "SIP 3.0" effort. My personal though is that there's just too much cruft in the RFC 3261 family to make Draft, but I could be proven wrong. I'd rather see us put SIP 2.0 into maintenance mode at the end of 2009 and move the bulk of our resources into developing a SIP 3.0 family designed from the ground up to be Draft-Standard achievable. 3) RAI Essential Corrections WG: Does this justify its own working group? Remember, it would be not just RFC 3261, but the entire family of related RFCs that would need lock-step maintenance and corrections. Another approach might be to roll the corrections into the Draft Standard version of SIP 2.0. 4) RAI Policies WG: We have these ongoing, not-quite-committed work items like session policies, use of SAML, etc. that we've never been able to get fully wrapped up. I suspect they need their own WG. Or we need to decide that these things just aren't worth doing and stop feeling guilty about not finishing. As it is, I don't have a good feeling about SIP finishing them. 5) SIP Operations: I'd like to see SIPPING replaced with a "how to" group possibly under the OPS banner. They could deal with all the "how do we do X with SIP" from other SDOs. When confronted by a need to extend SIP to meet a given need, they could then BOF up a new WG to deal with the required extension. We already have working groups looking at conferencing, peering, telephony feature interop, provisioning, peer-to-peer, NAT traversal, Other things that might need WGs: SPIT? Identity and Reputation? I also suspect we need a couple of directorates that are not WGs to act in an advisory capacity: 1) RAI Security Directorate: Focuses on security review and architectural issues in RAI documents. 2) RAI Event Package Directorate: Reviews and approves new SIP event packages _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 19:51:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7A73A68F0; Mon, 16 Jun 2008 19:51:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FAD3A691C for ; Mon, 16 Jun 2008 19:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 EPbt3mpwUxbf for ; Mon, 16 Jun 2008 19:51:04 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 38BEC3A68A6 for ; Mon, 16 Jun 2008 19:51:04 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id edLs1Z0020ldTLk550ne00; Tue, 17 Jun 2008 02:51:46 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA04.westchester.pa.mail.comcast.net with comcast id eqrk1Z00D02AVH03Qqrldc; Tue, 17 Jun 2008 02:51:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=WPCZQANMUbwA:10 a=-TzPRHrdgPoA:10 a=tV1Jxr_MdV03bb2B1ZwA:9 a=UMX5UQZ2BTYNDkGwjScA:7 a=NK-kk85BMwg5Oz3b1Gke_cZuy_EA:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5H2piPO023177 for ; Mon, 16 Jun 2008 22:51:44 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5H2piTp023173; Mon, 16 Jun 2008 22:51:44 -0400 Date: Mon, 16 Jun 2008 22:51:44 -0400 Message-Id: <200806170251.m5H2piTp023173@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4853DB2D.7060209@cisco.com> (pkyzivat@cisco.com) References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> <18515.27718.204853.637776@taimen.test.fi> <18515.50598.566583.38032@taimen.test.fi> <4853DB2D.7060209@cisco.com> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Paul Kyzivat Well, the specification could be abstracted to remove the mention of the B2BUA while still having the same effect. It would have to say something about a UAS should send a 199 if it knows the dialog will be terminated before it can send the final response. But I think we would still need to include an example of a B2BUA in order for anybody to have a clue what we were talking about. I think the situation is simpler than people are making it out to be. The situations in which having an agent generate and send a 199 is useful are when all of the following are true: - the agent knows that an early dialog has been created because it transmitted a 1xx response (either that it generated, or that it received from downstream) (And as Rocksun pointed out, "1xx" explicitly excludes both "100" and "199".), and - the agent knows that the early dialog has been terminated due to receiving a failure final response which includes the early dialog (which was from the downstream leg from which the 1xx came), and - the agent has not transmitted a 199 response to terminate the early dialog, and - the agent will not be immediately sending a failure final response (which would indicate the termination of the early dialog) It turns out that an ordinary UAS never is in this situation (because it only generates one early dialog for an INVITE, and only ends the early dialog when it sends a failure final response), so by implication, an ordinary UAS never should send a 199. If we enumerate the above criteria, we don't have to describe the various cases of UA vs. B2BUA, etc., because they're all covered. And by making the criteria explicit, we increase the probability of useful and effective implementations. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 20:51:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F923A68AC; Mon, 16 Jun 2008 20:51:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB40D3A68AC for ; Mon, 16 Jun 2008 20:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 hZGITwbtcD4r for ; Mon, 16 Jun 2008 20:51:49 -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 607853A67AF for ; Mon, 16 Jun 2008 20:51:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,656,1204520400"; d="scan'208";a="11201270" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2008 23:52:31 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5H3qViO031043; Mon, 16 Jun 2008 23:52:31 -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.13.8) with ESMTP id m5H3qVix006961; Tue, 17 Jun 2008 03:52:31 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.1830); Mon, 16 Jun 2008 23:52:31 -0400 Received: from [10.86.240.113] ([10.86.240.113]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 23:52:31 -0400 Message-ID: <4857352C.7090002@cisco.com> Date: Mon, 16 Jun 2008 23:53:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> <18515.27718.204853.637776@taimen.test.fi> <18515.50598.566583.38032@taimen.test.fi> <4853DB2D.7060209@cisco.com> <200806170251.m5H2piTp023173@dragon.ariadne.com> In-Reply-To: <200806170251.m5H2piTp023173@dragon.ariadne.com> X-OriginalArrivalTime: 17 Jun 2008 03:52:31.0322 (UTC) FILETIME=[917F8BA0:01C8D02D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2579; t=1213674751; x=1214538751; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=Gv9SvNLqWZt4OThPDRC0d0nl24MsSgZCEENbRcbrj5A=; b=wyGvkEZV/6buHKVVanoHrKYjOR2VRSJxyXa64vKjKaxBcbwA5iGTBHckIC 20sw4LI6W2tkYd6Ki7XwOuOIgnddrCXyB2dmIJO+pr8N2RfPkTgAKfHh94cz Uuo4x2XY/E; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale, I'm fine with spinning it this way. It avoids using the *term* B2BUA, but it still is talking about a B2BUA since it is talking about a UA that has received a response from downstream of itself. So we are playing political correctness gavmes. But I'm ok with that. Thanks, Paul Dale.Worley@comcast.net wrote: > From: Paul Kyzivat > > Well, the specification could be abstracted to remove the mention of the > B2BUA while still having the same effect. It would have to say something > about a UAS should send a 199 if it knows the dialog will be terminated > before it can send the final response. But I think we would still need > to include an example of a B2BUA in order for anybody to have a clue > what we were talking about. > > I think the situation is simpler than people are making it out to be. > > The situations in which having an agent generate and send a 199 is > useful are when all of the following are true: > > - the agent knows that an early dialog has been created because it > transmitted a 1xx response (either that it generated, or that it > received from downstream) (And as Rocksun pointed out, "1xx" > explicitly excludes both "100" and "199".), and > > - the agent knows that the early dialog has been terminated due to > receiving a failure final response which includes the early dialog > (which was from the downstream leg from which the 1xx came), and > > - the agent has not transmitted a 199 response to terminate the early > dialog, and > > - the agent will not be immediately sending a failure final response > (which would indicate the termination of the early dialog) > > It turns out that an ordinary UAS never is in this situation (because > it only generates one early dialog for an INVITE, and only ends the > early dialog when it sends a failure final response), so by > implication, an ordinary UAS never should send a 199. > > If we enumerate the above criteria, we don't have to describe the > various cases of UA vs. B2BUA, etc., because they're all covered. And > by making the criteria explicit, we increase the probability of useful > and effective implementations. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 21:00:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7872E3A6903; Mon, 16 Jun 2008 21:00:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722B03A6903 for ; Mon, 16 Jun 2008 21:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 eWbf-1pg0UwM for ; Mon, 16 Jun 2008 21:00:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 751603A67AF for ; Mon, 16 Jun 2008 21:00:48 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5H41EoL026816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Jun 2008 23:01:16 -0500 Message-Id: <97AC6940-C44D-4CF9-B977-797261E46B56@softarmor.com> From: Dean Willis To: Dale.Worley@comcast.net In-Reply-To: <200806170251.m5H2piTp023173@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 23:01:08 -0500 References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> <18515.27718.204853.637776@taimen.test.fi> <18515.50598.566583.38032@taimen.test.fi> <4853DB2D.7060209@cisco.com> <200806170251.m5H2piTp023173@dragon.ariadne.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 16, 2008, at 9:51 PM, Dale.Worley@comcast.net wrote: > From: Paul Kyzivat > > Well, the specification could be abstracted to remove the mention > of the > B2BUA while still having the same effect. It would have to say > something > about a UAS should send a 199 if it knows the dialog will be > terminated > before it can send the final response. But I think we would still > need > to include an example of a B2BUA in order for anybody to have a clue > what we were talking about. Could it be explained in terms of a UA that is acting as a protocol gateway? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 16 22:17:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B923A6814; Mon, 16 Jun 2008 22:17:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6623A67EC for ; Mon, 16 Jun 2008 22:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoYXi2BD7JNf for ; Mon, 16 Jun 2008 22:17:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A724E3A6814 for ; Mon, 16 Jun 2008 22:17:30 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5H5IBVN027065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 17 Jun 2008 00:18:13 -0500 Message-Id: <55800191-9C92-4F90-A42D-56FF9CEB8AD1@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 17 Jun 2008 00:18:06 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] WG Status, and Towards a Dublin SIP Agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We have (theoretically) four hours in Dublin. Let's recap our milestones and see what needs to be talked about in dublin: 1) Jul 2007 Location Conveyance with SIP to IESG (PS) -- as far as I know, this is stable and the retransmission issue is being hashed in geopriv 2) Aug 2007 Connection reuse mechanism to IESG (PS) -- I believe this is awaiting a proto writeup and that the WG is done with it 3) Sep 2007 Session Policies to IESG as PS -- I believe this is awaiting a proto writeup and that the WG is done with it 4) Sep 2007 Example security flows to IESG (Informational) -- Ok, I've lost track on this one. 5) Oct 2007 New resource priority namespaces for DISA to IESG (PS) -- I believe this is awaiting a proto writeup and that the WG is done with it 6) Nov 2007 Requirements for media keying to IESG (Informational) -- I believe this is awaiting a proto writeup and that the WG is done with it 7 )Dec 2007 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to IESG (PS) -- I believe this is awaiting a proto writeup and that the WG is done with it 8) Dec 2007 Roadmap for SIP to IESG (Informational) -- I believe this is awaiting a proto writeup and that the WG is done with it 9) Dec 2007 Using SAML for SIP to IESG (PS) -- We seem to be stalled. I've heard from one person who is excitedly implementing, so at least there's something like a constituency. 10) Dec 2007 Extension for use in etags in conditional notification to IESG (PS) -- we are waiting on the author to finish some changes from WGLC, and have no issues to discuss. 11) Feb 2008 Identify requirements for test matrix to move SIP to Draft Standard -- I guess we need to talk about this. 12) Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) -- we seem to be stuck on this one, with two conflicting methodologies. How can we structure a conversation to produce meaningful results? 13) Feb 2008 Revise charter -- I've started this discussion on-list 14) Feb 2008 Establishment of secure media sessions using DTLS-SRTP to IESG (PS) -- We were last discussing the impact of RFC 4474's PSTN-interworking problem on this draft, and got stuck. I guess we should talk about it. 15) Apr 2008 MIME body handling in SIP to IESG (PS) -- the latest version supposedly addressed all list comments. Where are we? 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG (PS) -- This is a perennial favorite for discussion, as Essential Corrections are essential confusing to a lot of people. 17) Jul 2008 Mechanisms for UA initiated privacy to IESG (BCP) -- This seems to have gone forward as an individual draft. 18) Aug 2008 Guidelines for double route recording to IESG (BCP) -- This seems to have stalled. Do we have any issues? I'm not aware of any 19) Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) -- We are awaiting a revised draft 20) Sep 2008 X.509 extended key usage for SIP to IESG (PS) -- we are awaiting a revised draft 21) Nov 2008 Termination of early dialog prior to final response to IESG (PS) -- we seem to be discussing on-list. This leaves the following probable topics: 1) Example Security Flows 2) SAML 3) Test Matrix for Draft Standard 4) Delivering Request-URI and Parameters to UAS via Proxy 5) DTLS-SRTP and RFC 4474 6) MIME Body Handling 7) Essential Corrections 8) Termination of Early Dialog Prior to Final Response So, the floor is now open for discussing what should be on the agenda. Remember, chartered work (as listed above) gets first priority. I'm also deeply concerned about #4 and #5 above and trying to figure out how to get traction. Anybody got an idea? -- Dean, SIP chair for the last 9 years . . . _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 07:27:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A08A28C11C; Tue, 17 Jun 2008 07:27:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D469228C11C for ; Tue, 17 Jun 2008 07:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfpGfKH-Rk+t for ; Tue, 17 Jun 2008 07:27:57 -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 7D6B728C113 for ; Tue, 17 Jun 2008 07:27:57 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5HESZFL012817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2008 09:28:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Dean Willis In-Reply-To: <55800191-9C92-4F90-A42D-56FF9CEB8AD1@softarmor.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 17 Jun 2008 09:28:35 -0500 References: <55800191-9C92-4F90-A42D-56FF9CEB8AD1@softarmor.com> X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip@ietf.org Subject: Re: [Sip] WG Status, and Towards a Dublin SIP Agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > 4) Sep 2007 Example security flows to IESG (Informational) > -- Ok, I've lost track on this one. In my hands waiting for some information from ekr. > 11) Feb 2008 Identify requirements for test matrix to move SIP to > Draft Standard > -- I guess we need to talk about this. Agreed - I hope to have a strawman of some sort this time around. > 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG > (PS) > -- This is a perennial favorite for discussion, as Essential > Corrections are essential confusing to a lot of people. I will start another thread on this. > > > > This leaves the following probable topics: > > 1) Example Security Flows This needs no agenda time. > > 2) SAML > 3) Test Matrix for Draft Standard A short amount of time for this (if substantiated by list discussion) would be useful. > > 4) Delivering Request-URI and Parameters to UAS via Proxy > 5) DTLS-SRTP and RFC 4474 > 6) MIME Body Handling > 7) Essential Corrections Lets see how the other thread I start goes - hopefully we can actually do something here on list instead of eating face-time for it. > > 8) Termination of Early Dialog Prior to Final Response I strongly agree that we should focus on chartered work, and suggest that only things really getting list attention take significant agenda time. > > > So, the floor is now open for discussing what should be on the agenda. > Remember, chartered work (as listed above) gets first priority. Where is the overload discussion? (I'm not suggesting agenda time necessarily) > > > I'm also deeply concerned about #4 and #5 above and trying to figure > out how to get traction. Anybody got an idea? > > -- > Dean, SIP chair for the last 9 years . . . > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 08:02:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E7C3A6B10; Tue, 17 Jun 2008 08:02:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E42A3A6A13 for ; Tue, 17 Jun 2008 08:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJESIOjtgbTl for ; Tue, 17 Jun 2008 08:02:42 -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 B65063A6B10 for ; Tue, 17 Jun 2008 08:02:41 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5HF3O13016225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2008 10:03:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <6F6BA1A6-A732-4557-9D94-C8C8EF1BD6FF@nostrum.com> From: Robert Sparks To: "sip@ietf.org List" Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 17 Jun 2008 10:03:24 -0500 X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Dean Willis Subject: [Sip] Essential corrections checkpoint X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org So, for essential corrections as we've talked about them so far: fork-loop-fix is back in the chairs hands (for a long long time - can we escalate this? The version that needed to go back in was submitted in November - it's technically expired, but the "AD is Watching" designation is keeping it in the tracker). invfix will be revised before the dublin -00. That version should be ready to LC record-route-fix we took out of essential corrections - its moving forward as a BCP the last I saw traffic about it. Am I forgetting about something else? I still think fork-loop-fix should go through as a standalone document. That leaves only invfix to be part of the "first" bundle of things to go and I have no visibility into anything else that would go into that bundle, so, effectively, _it_ would be a standalone document. RjS _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 08:10:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697F23A6B2D; Tue, 17 Jun 2008 08:10:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7633A6B2D for ; Tue, 17 Jun 2008 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 R6qZv3tQdC3B for ; Tue, 17 Jun 2008 08:10:26 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6AF663A68A3 for ; Tue, 17 Jun 2008 08:10:26 -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 m5HFArHF017893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2008 10:11:01 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5HFApsn009016; Tue, 17 Jun 2008 10:10:51 -0500 (CDT) Message-ID: <4857D3FD.8090908@alcatel-lucent.com> Date: Tue, 17 Jun 2008 10:10:53 -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: Robert Sparks References: <6F6BA1A6-A732-4557-9D94-C8C8EF1BD6FF@nostrum.com> In-Reply-To: <6F6BA1A6-A732-4557-9D94-C8C8EF1BD6FF@nostrum.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "sip@ietf.org List" Subject: Re: [Sip] Essential corrections checkpoint X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Robert Sparks wrote: > So, for essential corrections as we've talked about them so far: > > fork-loop-fix is back in the chairs hands (for a long long time - can > we escalate this? The version that needed to go back in was submitted > in November - it's technically expired, but the "AD is Watching" > designation is keeping it in the tracker). > > invfix will be revised before the dublin -00. That version should be > ready to LC > > record-route-fix we took out of essential corrections - its moving > forward as a BCP the last I saw traffic about it. > > Am I forgetting about something else? Robert: IPv6 ABNF fix draft (see http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-02). The last known and stable version is -02 and ready to be moved forward. > I still think fork-loop-fix should go through as a standalone > document. That leaves only invfix to be part of the "first" bundle of > things to go and I have no visibility into anything else that would go > into that bundle, so, effectively, _it_ would be a standalone document. I believe the ipv6-abnf-fix was scheduled to go in the first bundle. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 08:25:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B7D3A6B48; Tue, 17 Jun 2008 08:25:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E403A6B48 for ; Tue, 17 Jun 2008 08:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QzY1dI5HqRx for ; Tue, 17 Jun 2008 08:24:57 -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 074C23A6A80 for ; Tue, 17 Jun 2008 08:24:56 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5HFPcZl017639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2008 10:25:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: "Vijay K. Gurbani" In-Reply-To: <4857D3FD.8090908@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 17 Jun 2008 10:25:38 -0500 References: <6F6BA1A6-A732-4557-9D94-C8C8EF1BD6FF@nostrum.com> <4857D3FD.8090908@alcatel-lucent.com> X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sip@ietf.org List" Subject: Re: [Sip] Essential corrections checkpoint X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks Vijay - That's why I asked what I was forgetting. RjS On Jun 17, 2008, at 10:10 AM, Vijay K. Gurbani wrote: > Robert Sparks wrote: >> So, for essential corrections as we've talked about them so far: >> fork-loop-fix is back in the chairs hands (for a long long time - >> can we escalate this? The version that needed to go back in was >> submitted in November - it's technically expired, but the "AD is >> Watching" designation is keeping it in the tracker). >> invfix will be revised before the dublin -00. That version should >> be ready to LC >> record-route-fix we took out of essential corrections - its moving >> forward as a BCP the last I saw traffic about it. >> Am I forgetting about something else? > > Robert: IPv6 ABNF fix draft (see > http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-02). The > last known and stable version is -02 and ready to be moved forward. > >> I still think fork-loop-fix should go through as a standalone >> document. That leaves only invfix to be part of the "first" bundle >> of things to go and I have no visibility into anything else that >> would go into that bundle, so, effectively, _it_ would be a >> standalone document. > > I believe the ipv6-abnf-fix was scheduled to go in the first bundle. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 11:53:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA5328C19B; Tue, 17 Jun 2008 11:53:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B8F3A67ED for ; Tue, 17 Jun 2008 11:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 tZrIfbRy5gMp for ; Tue, 17 Jun 2008 11:53:44 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 8730028C17E for ; Tue, 17 Jun 2008 11:53:44 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5HIsE728511; Tue, 17 Jun 2008 18:54:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jun 2008 13:51:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WG Status, and Towards a Dublin SIP Agenda Thread-Index: AcjQhtQyVE4w09XhQTCF4dEYqyaFrAAI7QRQ References: <55800191-9C92-4F90-A42D-56FF9CEB8AD1@softarmor.com> From: "Mary Barnes" To: "Robert Sparks" , "Dean Willis" Cc: sip@ietf.org, Volker Hilt Subject: Re: [Sip] WG Status, and Towards a Dublin SIP Agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org One question and one comment below [MB]. Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Tuesday, June 17, 2008 9:29 AM To: Dean Willis Cc: sip@ietf.org Subject: Re: [Sip] WG Status, and Towards a Dublin SIP Agenda > 4) Sep 2007 Example security flows to IESG (Informational) > -- Ok, I've lost track on this one. In my hands waiting for some information from ekr. > 11) Feb 2008 Identify requirements for test matrix to move SIP to > Draft Standard > -- I guess we need to talk about this. Agreed - I hope to have a strawman of some sort this time around. > 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG > (PS) > -- This is a perennial favorite for discussion, as Essential > Corrections are essential confusing to a lot of people. I will start another thread on this. > > > > This leaves the following probable topics: > > 1) Example Security Flows This needs no agenda time. > > 2) SAML [MB] What more needs to be done in this area? I thought the document was fairly complete or are there outstanding issues? [/MB] > 3) Test Matrix for Draft Standard A short amount of time for this (if substantiated by list discussion) would be useful. > > 4) Delivering Request-URI and Parameters to UAS via Proxy > 5) DTLS-SRTP and RFC 4474 > 6) MIME Body Handling > 7) Essential Corrections Lets see how the other thread I start goes - hopefully we can actually do something here on list instead of eating face-time for it. > > 8) Termination of Early Dialog Prior to Final Response I strongly agree that we should focus on chartered work, and suggest that only things really getting list attention take significant agenda time. > > > So, the floor is now open for discussing what should be on the agenda. > Remember, chartered work (as listed above) gets first priority. Where is the overload discussion? (I'm not suggesting agenda time necessarily) [MB] We should allow agenda time in SIPPING for an update/status from the Overload design team. The SIPPING chairs (I) still have an outstanding action to define a WG deliverable for the output of the design team. Volker will be splitting the solution out of his current individual document and discuss this as a possible document to meet that deliverable. Whether we progress that document or merge it back with the solution later should be considered. But, for now, we should keep discussion of this topic in SIPPING WG. [/MB] > > > I'm also deeply concerned about #4 and #5 above and trying to figure > out how to get traction. Anybody got an idea? > > -- > Dean, SIP chair for the last 9 years . . . > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 12:23:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983733A6A53; Tue, 17 Jun 2008 12:23:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4153A6A53 for ; Tue, 17 Jun 2008 12:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 UTJXoHXeDoMl for ; Tue, 17 Jun 2008 12:23:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 88EA93A6A04 for ; Tue, 17 Jun 2008 12:23:48 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5HJOUo17787; Tue, 17 Jun 2008 19:24:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jun 2008 14:21:55 -0500 Message-ID: In-Reply-To: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjQCAuia74LIcnHT7ahxL9B/hx+ZAAoydQQ References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> From: "Mary Barnes" To: "Dean Willis" , Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I have a few comments below [MB]. And one more mega comment/proposal here. Mobile IP is an area that has a similar history as SIP in terms of the demand and explosion of work. They considered our SIP/SIPPING model (at that time we had few other spinoffs, as I recall) when they split their WGs. They have a group for IPv6 work(mext), one for IPv4(mipv4) and one for performance, signaling and optimizations(mipshop). So, from you list of numbers, I could also see a 3 WG split for SIP/SIPPING (discounting all the current spinoffs) using your #s (and assuming SIP WG is done): A) #2+#3: SIP core protocol and extensions to fold into next protocol version B) #4: Policies and security related aspects of SIP Protocol and then put the burden of screening new work such as SPIT, identity, etc. in this group until it's decided that the workload demands a separate WG. C) #5: Basically, SIPPING slightly reduced from current charter - filtering (including OPS related items), howtos, discussing p-headers, etc. - the primary difference here is that this group would not screen basic SIP extension proposals or any of the policy/security, etc. related work. Right now we don't do the security, but some of the other stuff has been debatable. In my mind, the primary thing this would accomplish would be separating out the policy and security work to ensure there's the right focus and attention. I also think this makes scheduling only slightly easier in that it might be easier to ensure security folks could attend. However, I don't think this really helps that much with overall workload - it's just moving some things around. For example, if A above does all the SIP extension screening, that workload may make A be just as crazy as SIP is now OR if in the end the security stuff is causing the craziness, then group B becomes the crazy one, until it sheds more work to new WGs and of course C stays fairly sane, which is what I think it is now ;) In general, I agree that SIP should follow the model that SIPPING did a couple years ago and NOT accept new work items until currently chartered items are done (or at least down to a manageable handful (5-6)) rather than the current 17 (use the tools page rather than WG charter to see the delta), so putting the WG on a path to closure is an excellent idea. Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, June 16, 2008 6:23 PM To: sip@ietf.org Subject: [Sip] Toward the Evolution of SIP and Related Working Groups The SIP working group spun off from the MMUSIC working group when we realized that the SIP work was reasonably separable from the other work going on in MMUSIC. The SIP working group first met officially at IETF 46 in November 1999, although we did have an earlier interim meeting. This means that the fall 1999 meeting will be our 10th anniversary. In addition to having a big party, I'd also like to plan for this being the last meeting of the SIP working group as it is now defined. Ten years is long enough. It's time we restructured. There will probably still be people who want to change, revise, extend, or otherwise manipulate the family of SIP specifications after 2009. So what should we do? How should we organize to get those needs met? Rest assured, we'll be having further discussions on this topic in the coming months. But I'd like to start the discussion now. By November 2009, I fully expect SIP to have completed the majority of currently chartered items. Between now and then, we'll probably also take on and complete a bit of new work (although I plan to be very resistant to new work). I also expect that there are a few items on our charter now that we're not going to finish. It may well be that some of those items need a different organizational structure to progress than what we have. Or maybe they don't need doing. Further, I've come to believe that most working groups should be shorter-lived and tightly constrained by their charters to produce a single concise set of deliverables. There's still a need for a longer- lived thing that maintains architectural oversight. I've come to believe that this is the "area", not the working group. Let's start the recap by looking at the current charter of the SIP WG. I've eliminated the WGLC milestones to shorten the list, as each has a following IESG milestone. Note that there's a Feb 2008 milestone for "Revise Charter". You can consider this topic the first installment on that milestone, even though it is a bit late. 1) Jul 2007 Location Conveyance with SIP to IESG (PS) 2) Aug 2007 Connection reuse mechanism to IESG (PS) 3) Sep 2007 Session Policies to IESG as PS 4) Sep 2007 Example security flows to IESG (Informational) 5) Oct 2007 New resource priority namespaces for DISA to IESG (PS) 6) Nov 2007 Requirements for media keying to IESG (Informational) 7 )Dec 2007 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to IESG (PS) 8) Dec 2007 Roadmap for SIP to IESG (Informational) 9) Dec 2007 Using SAML for SIP to IESG (PS) 10) Dec 2007 Extension for use in etags in conditional notification to IESG (PS) 11) Feb 2008 Identify requirements for test matrix to move SIP to Draft Standard 12) Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) 13) Feb 2008 Revise charter 14) Feb 2008 Establishment of secure media sessions using DTLS-SRTP to IESG (PS) 15) Apr 2008 MIME body handling in SIP to IESG (PS) 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG (PS) 17) Jul 2008 Mechanisms for UA initiated privacy to IESG (BCP) 18) Aug 2008 Guidelines for double route recording to IESG (BCP) 19) Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) 20) Sep 2008 X.509 extended key usage for SIP to IESG (PS) 21) Nov 2008 Termination of early dialog prior to final response to IESG (PS) Looking at this, we have a couple of discrete tasks that I think might make the basis for different narrowly-scoped working groups. We've also got a lot of stuff that we're late on delivering! 1) SIP WG (to finish by end of 2009) gets the bulk of these items. 2) SIP Draft Standard WG: Takes the milestone of "Identify requirements for test matrix to move SIP to Draft Standard" and all of the follow-on work needed to move SIP from Proposed to Draft on the standards track. There's certainly enough work here for a dedicated working group, with the last milestone being something like "Deliver SIP as a Draft Standards Document to IESG". We may wish to consider whether we really want to go this route or whether we should instead be thinking of a "SIP 3.0" effort. My personal though is that there's just too much cruft in the RFC 3261 family to make Draft, but I could be proven wrong. I'd rather see us put SIP 2.0 into maintenance mode at the end of 2009 and move the bulk of our resources into developing a SIP 3.0 family designed from the ground up to be Draft-Standard achievable. [MB] I like this suggestion. [/MB] 3) RAI Essential Corrections WG: Does this justify its own working group? Remember, it would be not just RFC 3261, but the entire family of related RFCs that would need lock-step maintenance and corrections. Another approach might be to roll the corrections into the Draft Standard version of SIP 2.0. [MB] I think this should be roleed into 2) above. [/MB] 4) RAI Policies WG: We have these ongoing, not-quite-committed work items like session policies, use of SAML, etc. that we've never been able to get fully wrapped up. I suspect they need their own WG. Or we need to decide that these things just aren't worth doing and stop feeling guilty about not finishing. As it is, I don't have a good feeling about SIP finishing them. [MB] I like this idea and would it also not cover any outstanding ongoing security items or are you anticipating that to addressed entirely by the currently chartered work items? [/MB] 5) SIP Operations: I'd like to see SIPPING replaced with a "how to" group possibly under the OPS banner. They could deal with all the "how do we do X with SIP" from other SDOs. When confronted by a need to extend SIP to meet a given need, they could then BOF up a new WG to deal with the required extension. [MB] Are you proposing this to replace SIPPING WG? If so, I don't see it falling under the banner of OPS. I do see that there may potentially be the need to initially discuss OPS related items, but as in the past, I see those being completed in the appropriate OPS WGs (e.g., performance). I have mixed views on how effective it would be to have a BoF and new WG for new extensions. I don't think the model we currently have is that ineffective in terms of first discussing requirements before agreeing a solution. I see a SIP Maintenace group perhaps to handle these items, although in many cases, I think it would be far more effective to roll these things into your item 2 - i.e., don't you see SIP 3.0 as pulling in a lot of the headers that have been defined since RFC 3261 has been published. [/MB] We already have working groups looking at conferencing, peering, telephony feature interop, provisioning, peer-to-peer, NAT traversal, Other things that might need WGs: SPIT? Identity and Reputation? [MB] I would agree these two topics might warrant separate WGs, although some of that work overlaps with your WG 4, I believe, the division of work may not be so clear. [/MB] I also suspect we need a couple of directorates that are not WGs to act in an advisory capacity: [MB] I think we already have these and more covered by our current RAI area review team. These are specialized reviews and assignment of reviewers is based on area of expertise and we've got security and event package gurus already on the team. [/MB] 1) RAI Security Directorate: Focuses on security review and architectural issues in RAI documents. 2) RAI Event Package Directorate: Reviews and approves new SIP event packages _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 12:48:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9F93A6AAF; Tue, 17 Jun 2008 12:48:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51623A6A35 for ; Tue, 17 Jun 2008 12:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 iTkDXZV81n6a for ; Tue, 17 Jun 2008 12:48:39 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 770173A6AAF for ; Tue, 17 Jun 2008 12:48:39 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA06.westchester.pa.mail.comcast.net with comcast id f1ZK1Z00w0vyq2s560E400; Tue, 17 Jun 2008 19:49:24 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA05.westchester.pa.mail.comcast.net with comcast id f7pP1Z00B02AVH03R7pPJb; Tue, 17 Jun 2008 19:49:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=WPCZQANMUbwA:10 a=-TzPRHrdgPoA:10 a=qeHzJ4P1iXCGLbhCMfAA:9 a=Ex3vlasEqTWvnxStwOrxKS_zN_8A:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5HJnNPO000345 for ; Tue, 17 Jun 2008 15:49:23 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5HJnMJi000341; Tue, 17 Jun 2008 15:49:22 -0400 Date: Tue, 17 Jun 2008 15:49:22 -0400 Message-Id: <200806171949.m5HJnMJi000341@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4857352C.7090002@cisco.com> (pkyzivat@cisco.com) References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <48527F1A.90302@cisco.com> <1ECE0EB50388174790F9694F77522CCF1760FE01@zrc2hxm0.corp.nortel.com> <4852C62F.4030007@cisco.com> <1ECE0EB50388174790F9694F77522CCF17610091@zrc2hxm0.corp.nortel.com> <4852E0B2.3000306@cisco.com> <18515.27718.204853.637776@taimen.test.fi> <18515.50598.566583.38032@taimen.test.fi> <4853DB2D.7060209@cisco.com> <200806170251.m5H2piTp023173@dragon.ariadne.com> <4857352C.7090002@cisco.com> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Paul Kyzivat I'm fine with spinning it this way. It avoids using the *term* B2BUA, but it still is talking about a B2BUA since it is talking about a UA that has received a response from downstream of itself. So we are playing political correctness gavmes. But I'm ok with that. More importantly, the rule I suggest handles proxies, UAs, B2BUAs, gateways, etc. *uniformly*. (I use the term "agent" for "all devices which send and receive SIP".) There's no point attempting to make general statements about the consequences of the rule for particular classes of devices, as that only risks making a mistake by overlooking unusual cases. The rule states exactly when a 199 should be sent. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 15:26:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD623A6B89; Tue, 17 Jun 2008 15:26:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E703A6B88 for ; Tue, 17 Jun 2008 15:26:35 -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.113, 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 Kj30oCq75agH for ; Tue, 17 Jun 2008 15:26:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8CF6B3A6B75 for ; Tue, 17 Jun 2008 15:26:34 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5HMRIxY005691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 17 Jun 2008 17:27:19 -0500 Message-Id: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 17 Jun 2008 17:27:12 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We've been batting INFO around for many, many years now (like, 10 -- it predates the SIP working group). A couple of meetings back, we agreed that we would discuss use cases for INFO packages, and if we didn't find any consensus there, then we would go ahead and publish an "INFO Considered Harmful" RFC. We tried having this discussion at the last IETF, but that just didn't work out. Do we try again, or just give up and publish "INFO Considered Harmful"? Personally, I don't care anymore -- I just want to drive a stake into the heart of this undead-thing, cut off its head, stuff the mouth with holy wafers, and bury it at a crossroads somewhere. But this WG only slays by consensus, so what do you want? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 15:31:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BB53A6813; Tue, 17 Jun 2008 15:31:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84AA3A6813 for ; Tue, 17 Jun 2008 15:31:18 -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 GwOsgHYUZqot for ; Tue, 17 Jun 2008 15:31:17 -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 B72773A679C for ; Tue, 17 Jun 2008 15:31:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,660,1204531200"; d="scan'208";a="41925412" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2008 15:32:03 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5HMW3Mh019720; Tue, 17 Jun 2008 15:32:03 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m5HMW3J1026336; Tue, 17 Jun 2008 22:32:03 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 15:32:03 -0700 Received: from [128.107.103.57] ([128.107.103.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 15:32:03 -0700 Message-ID: <48583B6A.5080404@cisco.com> Date: Tue, 17 Jun 2008 18:32:10 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> In-Reply-To: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> X-OriginalArrivalTime: 17 Jun 2008 22:32:03.0312 (UTC) FILETIME=[F71FCF00:01C8D0C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2288; t=1213741923; x=1214605923; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=WvjGqcAy4gL+5nu2FqR1D1GHe0cIorn4Q+nXG9oY+YE=; b=Ylbi1N0hrAdgB6Haug02VnZ9XRxB4MRKtHw+0c+orZDOrj9CqrrR4+1HLo qZXzjBi8WP8zsCwLHYThc6PtICGglmIcd1lg8skbYm/iz5K28pPZ01QIqtWj JewuHt6I0u; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for raising this, Dean. I think the issue here is not so much 'what do we do about INFO', but rather, what are the actual extensibility models people are using with SIP and are we properly providing the techniques to make it all interoperate. In my mind, that is a really important issue. In terms of what to do, I think we should absolutely define an INFO framework along the lines of Hadriel's draft, and we should produce a guidelines document which helps people figure out whether to use INFO, event packages, or something along the lines of a media framework like I had proposed with TOTE (separate question on whether to pursue TOTE or not). I think the huge number of actual INFO usages, along with the many reasonable use cases we have identified, make a clear statement that this is something that is needed. -Jonathan R. Dean Willis wrote: > We've been batting INFO around for many, many years now (like, 10 -- > it predates the SIP working group). A couple of meetings back, we > agreed that we would discuss use cases for INFO packages, and if we > didn't find any consensus there, then we would go ahead and publish an > "INFO Considered Harmful" RFC. > > We tried having this discussion at the last IETF, but that just didn't > work out. > > Do we try again, or just give up and publish "INFO Considered Harmful"? > > Personally, I don't care anymore -- I just want to drive a stake into > the heart of this undead-thing, cut off its head, stuff the mouth with > holy wafers, and bury it at a crossroads somewhere. > > But this WG only slays by consensus, so what do you want? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 15:36:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51423A6B72; Tue, 17 Jun 2008 15:36:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235E13A6B72 for ; Tue, 17 Jun 2008 15:36:27 -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 qrPWGNGvnwtZ for ; Tue, 17 Jun 2008 15:36:25 -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 D8EB73A69B4 for ; Tue, 17 Jun 2008 15:36:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,660,1204531200"; d="scan'208";a="114677741" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 Jun 2008 15:37:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5HMb9PK019390; Tue, 17 Jun 2008 15:37:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5HMb9P0023510; Tue, 17 Jun 2008 22:37:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 15:37:07 -0700 Received: from [128.107.103.57] ([128.107.103.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 15:37:07 -0700 Message-ID: <48583C9A.7090309@cisco.com> Date: Tue, 17 Jun 2008 18:37:14 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mary Barnes References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> In-Reply-To: X-OriginalArrivalTime: 17 Jun 2008 22:37:07.0609 (UTC) FILETIME=[AC7FD890:01C8D0CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12031; t=1213742229; x=1214606229; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=GbyoJeMrhxdBBTDT2ZLkkq54vPo0YE2pqMFdqVwKyeg=; b=aJZVP+m+zQnavtfHf7bCJhkQUkYsem5TQMuCMJ4DijmgqnxPWGThNRjtC3 rbrDzCOajjaLixNV5ZlnE1Au7ISYPO3HfyPLvvf0LQKu0oagyz/IkL6W+Pta msYKc4JXTB; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree with Mary - this seems like its just moving work around. To reiterate the mantra of SIPPING itself - what PROBLEM are you trying to solve Dean? Is it that there is not enough people to do the work? As Mary points out, your suggestion only makes it worse. Is it to get more meeting slots? Is it to better align IETF work with the needs of the actual marketplace? Thanks, Jonathan R. Mary Barnes wrote: > I have a few comments below [MB]. And one more mega comment/proposal > here. Mobile IP is an area that has a similar history as SIP in terms > of the demand and explosion of work. They considered our SIP/SIPPING > model (at that time we had few other spinoffs, as I recall) when they > split their WGs. They have a group for IPv6 work(mext), one for > IPv4(mipv4) and one for performance, signaling and > optimizations(mipshop). So, from you list of numbers, I could also see a > 3 WG split for SIP/SIPPING (discounting all the current spinoffs) using > your #s (and assuming SIP WG is done): > A) #2+#3: SIP core protocol and extensions to fold into next protocol > version > B) #4: Policies and security related aspects of SIP Protocol and then > put the burden of screening new work such as SPIT, identity, etc. in > this group until it's decided that the workload demands a separate WG. > C) #5: Basically, SIPPING slightly reduced from current charter - > filtering (including OPS related items), howtos, discussing p-headers, > etc. - the primary difference here is that this group would not screen > basic SIP extension proposals or any of the policy/security, etc. > related work. Right now we don't do the security, but some of the other > stuff has been debatable. > > In my mind, the primary thing this would accomplish would be separating > out the policy and security work to ensure there's the right focus and > attention. I also think this makes scheduling only slightly easier in > that it might be easier to ensure security folks could attend. > > However, I don't think this really helps that much with overall workload > - it's just moving some things around. For example, if A above does all > the SIP extension screening, that workload may make A be just as crazy > as SIP is now OR if in the end the security stuff is causing the > craziness, then group B becomes the crazy one, until it sheds more work > to new WGs and of course C stays fairly sane, which is what I think it > is now ;) > > In general, I agree that SIP should follow the model that SIPPING did a > couple years ago and NOT accept new work items until currently chartered > items are done (or at least down to a manageable handful (5-6)) rather > than the current 17 (use the tools page rather than WG charter to see > the delta), so putting the WG on a path to closure is an excellent idea. > > > Mary. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Monday, June 16, 2008 6:23 PM > To: sip@ietf.org > Subject: [Sip] Toward the Evolution of SIP and Related Working Groups > > > The SIP working group spun off from the MMUSIC working group when we > realized that the SIP work was reasonably separable from the other work > going on in MMUSIC. > > The SIP working group first met officially at IETF 46 in November 1999, > although we did have an earlier interim meeting. > > This means that the fall 1999 meeting will be our 10th anniversary. In > addition to having a big party, I'd also like to plan for this being the > last meeting of the SIP working group as it is now defined. Ten years is > long enough. It's time we restructured. > > There will probably still be people who want to change, revise, extend, > or otherwise manipulate the family of SIP specifications after 2009. > > So what should we do? How should we organize to get those needs met? > Rest assured, we'll be having further discussions on this topic in the > coming months. But I'd like to start the discussion now. > > By November 2009, I fully expect SIP to have completed the majority of > currently chartered items. Between now and then, we'll probably also > take on and complete a bit of new work (although I plan to be very > resistant to new work). I also expect that there are a few items on our > charter now that we're not going to finish. It may well be that some of > those items need a different organizational structure to progress than > what we have. Or maybe they don't need doing. > > Further, I've come to believe that most working groups should be > shorter-lived and tightly constrained by their charters to produce a > single concise set of deliverables. There's still a need for a longer- > lived thing that maintains architectural oversight. I've come to believe > that this is the "area", not the working group. > > Let's start the recap by looking at the current charter of the SIP WG. > I've eliminated the WGLC milestones to shorten the list, as each has a > following IESG milestone. Note that there's a Feb 2008 milestone for > "Revise Charter". You can consider this topic the first installment on > that milestone, even though it is a bit late. > > 1) Jul 2007 Location Conveyance with SIP to IESG (PS) > > 2) Aug 2007 Connection reuse mechanism to IESG (PS) > > 3) Sep 2007 Session Policies to IESG as PS > > 4) Sep 2007 Example security flows to IESG (Informational) > > 5) Oct 2007 New resource priority namespaces for DISA to IESG (PS) > > 6) Nov 2007 Requirements for media keying to IESG (Informational) > > 7 )Dec 2007 Extensions to SIP UA Profile Delivery Change Notification > Event Package for XCAP to IESG (PS) > > 8) Dec 2007 Roadmap for SIP to IESG (Informational) > > 9) Dec 2007 Using SAML for SIP to IESG (PS) > > 10) Dec 2007 Extension for use in etags in conditional notification to > IESG (PS) > > 11) Feb 2008 Identify requirements for test matrix to move SIP to Draft > Standard > > 12) Feb 2008 Delivering request-URI and parameters to UAS via proxy to > IESG (PS) > > 13) Feb 2008 Revise charter > > 14) Feb 2008 Establishment of secure media sessions using DTLS-SRTP to > IESG (PS) > > 15) Apr 2008 MIME body handling in SIP to IESG (PS) > > 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG (PS) > > 17) Jul 2008 Mechanisms for UA initiated privacy to IESG (BCP) > > 18) Aug 2008 Guidelines for double route recording to IESG (BCP) > > 19) Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) > > 20) Sep 2008 X.509 extended key usage for SIP to IESG (PS) > > 21) Nov 2008 Termination of early dialog prior to final response to IESG > (PS) > > > Looking at this, we have a couple of discrete tasks that I think might > make the basis for different narrowly-scoped working groups. We've also > got a lot of stuff that we're late on delivering! > > 1) SIP WG (to finish by end of 2009) gets the bulk of these items. > > 2) SIP Draft Standard WG: Takes the milestone of "Identify requirements > for test matrix to move SIP to Draft Standard" and all of the follow-on > work needed to move SIP from Proposed to Draft on the standards track. > There's certainly enough work here for a dedicated working group, with > the last milestone being something like "Deliver SIP as a Draft > Standards Document to IESG". We may wish to consider whether we really > want to go this route or whether we should instead be thinking of a "SIP > 3.0" effort. My personal though is that there's just too much cruft in > the RFC 3261 family to make Draft, but I could be proven wrong. I'd > rather see us put SIP 2.0 into maintenance mode at the end of 2009 and > move the bulk of our resources into developing a SIP 3.0 family designed > from the ground up to be Draft-Standard achievable. > [MB] I like this suggestion. [/MB] > > 3) RAI Essential Corrections WG: Does this justify its own working > group? Remember, it would be not just RFC 3261, but the entire family of > related RFCs that would need lock-step maintenance and corrections. > Another approach might be to roll the corrections into the Draft > Standard version of SIP 2.0. > [MB] I think this should be roleed into 2) above. [/MB] > > > 4) RAI Policies WG: We have these ongoing, not-quite-committed work > items like session policies, use of SAML, etc. that we've never been > able to get fully wrapped up. I suspect they need their own WG. Or we > need to decide that these things just aren't worth doing and stop > feeling guilty about not finishing. As it is, I don't have a good > feeling about SIP finishing them. > [MB] I like this idea and would it also not cover any outstanding > ongoing security items or are you anticipating that to addressed > entirely by the currently chartered work items? [/MB] > > 5) SIP Operations: I'd like to see SIPPING replaced with a "how to" > group possibly under the OPS banner. They could deal with all the "how > do we do X with SIP" from other SDOs. When confronted by a need to > extend SIP to meet a given need, they could then BOF up a new WG to deal > with the required extension. > [MB] Are you proposing this to replace SIPPING WG? If so, I don't see > it falling under the banner of OPS. I do see that there may potentially > be the need to initially discuss OPS related items, but as in the past, > I see those being completed in the appropriate OPS WGs (e.g., > performance). I have mixed views on how effective it would be to have a > BoF and new WG for new extensions. I don't think the model we currently > have is that ineffective in terms of first discussing requirements > before agreeing a solution. I see a SIP Maintenace group perhaps to > handle these items, although in many cases, I think it would be far more > effective to roll these things into your item 2 - i.e., don't you see > SIP 3.0 as pulling in a lot of the headers that have been defined since > RFC 3261 has been published. [/MB] > > We already have working groups looking at conferencing, peering, > telephony feature interop, provisioning, peer-to-peer, NAT traversal, > > Other things that might need WGs: SPIT? Identity and Reputation? > > [MB] I would agree these two topics might warrant separate WGs, although > some of that work overlaps with your WG 4, I believe, the division of > work may not be so clear. [/MB] > > I also suspect we need a couple of directorates that are not WGs to act > in an advisory capacity: > > [MB] I think we already have these and more covered by our current RAI > area review team. These are specialized reviews and assignment of > reviewers is based on area of expertise and we've got security and event > package gurus already on the team. [/MB] > > 1) RAI Security Directorate: Focuses on security review and > architectural issues in RAI documents. > > 2) RAI Event Package Directorate: Reviews and approves new SIP event > packages > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 16:20:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DDB3A694E; Tue, 17 Jun 2008 16:20:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65B73A694E for ; Tue, 17 Jun 2008 16:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 BtfUFq9PN01K for ; Tue, 17 Jun 2008 16:20:41 -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 E8EF83A690D for ; Tue, 17 Jun 2008 16:20:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,661,1204520400"; d="scan'208";a="11303190" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2008 19:21:23 -0400 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 m5HNLO3M008279; Tue, 17 Jun 2008 19:21:24 -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.13.8) with ESMTP id m5HNLNjF014718; Tue, 17 Jun 2008 23:21:24 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.1830); Tue, 17 Jun 2008 19:21:23 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 19:21:23 -0400 Message-ID: <48584720.4030708@cisco.com> Date: Tue, 17 Jun 2008 19:22:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dean Willis References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> In-Reply-To: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> X-OriginalArrivalTime: 17 Jun 2008 23:21:23.0428 (UTC) FILETIME=[DB7DAA40:01C8D0D0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1270; t=1213744884; x=1214608884; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20 |To:=20Dean=20Willis=20; bh=8GWmT/oZ16P8qXfQUaGRpQQSJGbtZCqQtbQ+Z+DhDYo=; b=EvqncNF3iwWzJXNP7PBmhwwNZ+YU6McRDGf1ipjLTPzGN/7/o5HTRTfb75 4drfaSD5reNSIf88IPps83Ih+KMGZLFR9+Z76TBDBHnUMgOzPJakZwioFi2K vA1H5QydUq; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > We've been batting INFO around for many, many years now (like, 10 -- > it predates the SIP working group). A couple of meetings back, we > agreed that we would discuss use cases for INFO packages, and if we > didn't find any consensus there, then we would go ahead and publish an > "INFO Considered Harmful" RFC. > > We tried having this discussion at the last IETF, but that just didn't > work out. > > Do we try again, or just give up and publish "INFO Considered Harmful"? > > Personally, I don't care anymore -- I just want to drive a stake into > the heart of this undead-thing, cut off its head, stuff the mouth with > holy wafers, and bury it at a crossroads somewhere. I gave my try, very unsuccessfully. So I just want to remind you not to forget the garlic, the silver cross, and the sunlight. > But this WG only slays by consensus, so what do you want? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 16:32:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8B73A6924; Tue, 17 Jun 2008 16:32:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1363A6924 for ; Tue, 17 Jun 2008 16:32:15 -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 uw5DmbYU77hN for ; Tue, 17 Jun 2008 16:32:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C230D3A690D for ; Tue, 17 Jun 2008 16:32:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 17 Jun 2008 19:32:11 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 17 Jun 2008 19:32:11 -0400 From: Bob Penfield To: "sip@ietf.org" Date: Tue, 17 Jun 2008 19:32:10 -0400 Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: Aci8+J2JhcYV4gLPT4e5QA8ZpSE2EAT1Cg3g Message-ID: References: <20080523171502.3779528C27B@core3.amsl.com> In-Reply-To: <20080523171502.3779528C27B@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Some comments on this draft. I apologize if they are duplicates. Section 5 should only allow the UAS to send a 199 if it sent a dialog creating (101-199) provisional response. I know its implicit, but needs to be explicitly stated to prevent extra traffic. Suggest something like this: When a UAS wants to terminate an INVITE server transaction it sends a non-2xx SIP final response, as specified in [RFC3261]. In addition, if the UAS has previously sent a dialog creating 1xx response (101-199) for the transaction, then prior to sending the non-2xx SIP final response, the UAS MAY send a 199 response to indicate that the early dialog is being terminated. The 199 response MUST have the same tag in the To header as sent in the dialog creating 1xx response. In section 6 requires a forking proxy to send 199s for all early dialogs associated with the non-2xx response. However, if there are multiple forking proxies along the path (or some UASs send 199s), that could result in multiple 199's for a given dialog. IMO, if the proxy has already forwarded a 199 for a given dialog, it should not send one of its own. On the topic of UAS's sending 199, I actually think things will work better if they did. I know there has been lots of discussion about B2BUAs doing it, but consider a UAS that is aware that it has multiple registered contacts (via presence or registration event package or other means), it might want to send the 199 to be sure that it does reach the UAC (in case the proxy does not support it). Section 8 Open Issues: IMO, the 199's To-tag should identify the dialog being terminated. IMO, the 199's body MAY contain message/sipfrag with the non-2xx response code and important headers like Warning. cheers, (-:bob -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, May 23, 2008 1:15 PM To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sip-199-00.txt Pages : 9 Date : 2008-5-15 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP entity can use to indicate upstream that an early dialog has been terminated. The response code can be used by a SIP entity, normally a forking SIP proxy, to allow the UAC to know that an early dialog has been terminated before it a final response is sent to the request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-199-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 19:27:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455E73A68B8; Tue, 17 Jun 2008 19:27:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7FBB3A68B8 for ; Tue, 17 Jun 2008 19:27: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=[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 kLpjGtl0xyeW for ; Tue, 17 Jun 2008 19:27:49 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by core3.amsl.com (Postfix) with ESMTP id D07DE3A683C for ; Tue, 17 Jun 2008 19:27:44 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jun 2008 19:28:26 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m5I2P3G3015581; Tue, 17 Jun 2008 19:25:04 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m5I2SGqJ018975; Tue, 17 Jun 2008 19:28:22 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 19:28:16 -0700 Received: from 10.7.240.222 ([10.7.240.222]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Jun 2008 02:28:15 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 17 Jun 2008 21:28:14 -0500 From: Henry Sinnreich To: Dean Willis , Message-ID: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjQ6vWDeIPZmyuRxEyyjBJr1fkb6g== In-Reply-To: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> Mime-version: 1.0 X-OriginalArrivalTime: 18 Jun 2008 02:28:16.0882 (UTC) FILETIME=[F73AF520:01C8D0EA] Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SIP is actually an excellent success story. Not only is SIP the world standard but there are countless SIP implementations as OS SW. Maybe we could agree on the following to declare victory and preserve its success: 1. Any SIP and related work in the IETF is focused on the (stupid = no intelligence) Internet, as defined in AIB issued RFCs, keeping the e2e principle in mind. 2. Service provider specific protocols (to support "network based services") belong in ITU-T or other similar service provider focused organizations, 3. The main deliverable of a WG is free software to validate and support the protocol document and its refinement. If no free software is contributed, the WG activity should be suspended. Internet-Drafts not supported by freely available software (that can be inspected and tried out) and measurements cannot be proven right or wrong and should therefore be ignored. There is plenty of IEEE and University work to prove this approach, which was also the basis for the rise and success of the IETF. Thanks (and feel free to flame), Henry On 6/16/08 6:23 PM, "Dean Willis" wrote: > > The SIP working group spun off from the MMUSIC working group when we > realized that the SIP work was reasonably separable from the other > work going on in MMUSIC. > > The SIP working group first met officially at IETF 46 in November > 1999, although we did have an earlier interim meeting. > > This means that the fall 1999 meeting will be our 10th anniversary. In > addition to having a big party, I'd also like to plan for this being > the last meeting of the SIP working group as it is now defined. Ten > years is long enough. It's time we restructured. > > There will probably still be people who want to change, revise, > extend, or otherwise manipulate the family of SIP specifications after > 2009. > > So what should we do? How should we organize to get those needs met? > Rest assured, we'll be having further discussions on this topic in the > coming months. But I'd like to start the discussion now. > > By November 2009, I fully expect SIP to have completed the majority of > currently chartered items. Between now and then, we'll probably also > take on and complete a bit of new work (although I plan to be very > resistant to new work). I also expect that there are a few items on > our charter now that we're not going to finish. It may well be that > some of those items need a different organizational structure to > progress than what we have. Or maybe they don't need doing. > > Further, I've come to believe that most working groups should be > shorter-lived and tightly constrained by their charters to produce a > single concise set of deliverables. There's still a need for a longer- > lived thing that maintains architectural oversight. I've come to > believe that this is the "area", not the working group. > > Let's start the recap by looking at the current charter of the SIP WG. > I've eliminated the WGLC milestones to shorten the list, as each has a > following IESG milestone. Note that there's a Feb 2008 milestone for > "Revise Charter". You can consider this topic the first installment on > that milestone, even though it is a bit late. > > 1) Jul 2007 Location Conveyance with SIP to IESG (PS) > > 2) Aug 2007 Connection reuse mechanism to IESG (PS) > > 3) Sep 2007 Session Policies to IESG as PS > > 4) Sep 2007 Example security flows to IESG (Informational) > > 5) Oct 2007 New resource priority namespaces for DISA to IESG (PS) > > 6) Nov 2007 Requirements for media keying to IESG (Informational) > > 7 )Dec 2007 Extensions to SIP UA Profile Delivery Change Notification > Event Package for XCAP to IESG (PS) > > 8) Dec 2007 Roadmap for SIP to IESG (Informational) > > 9) Dec 2007 Using SAML for SIP to IESG (PS) > > 10) Dec 2007 Extension for use in etags in conditional notification to > IESG (PS) > > 11) Feb 2008 Identify requirements for test matrix to move SIP to > Draft Standard > > 12) Feb 2008 Delivering request-URI and parameters to UAS via proxy to > IESG (PS) > > 13) Feb 2008 Revise charter > > 14) Feb 2008 Establishment of secure media sessions using DTLS-SRTP to > IESG (PS) > > 15) Apr 2008 MIME body handling in SIP to IESG (PS) > > 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG (PS) > > 17) Jul 2008 Mechanisms for UA initiated privacy to IESG (BCP) > > 18) Aug 2008 Guidelines for double route recording to IESG (BCP) > > 19) Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) > > 20) Sep 2008 X.509 extended key usage for SIP to IESG (PS) > > 21) Nov 2008 Termination of early dialog prior to final response to > IESG (PS) > > > Looking at this, we have a couple of discrete tasks that I think might > make the basis for different narrowly-scoped working groups. We've > also got a lot of stuff that we're late on delivering! > > 1) SIP WG (to finish by end of 2009) gets the bulk of these items. > > 2) SIP Draft Standard WG: Takes the milestone of "Identify > requirements for test matrix to move SIP to Draft Standard" and all of > the follow-on work needed to move SIP from Proposed to Draft on the > standards track. There's certainly enough work here for a dedicated > working group, with the last milestone being something like "Deliver > SIP as a Draft Standards Document to IESG". We may wish to consider > whether we really want to go this route or whether we should instead > be thinking of a "SIP 3.0" effort. My personal though is that there's > just too much cruft in the RFC 3261 family to make Draft, but I could > be proven wrong. I'd rather see us put SIP 2.0 into maintenance mode > at the end of 2009 and move the bulk of our resources into developing > a SIP 3.0 family designed from the ground up to be Draft-Standard > achievable. > > 3) RAI Essential Corrections WG: Does this justify its own working > group? Remember, it would be not just RFC 3261, but the entire family > of related RFCs that would need lock-step maintenance and corrections. > Another approach might be to roll the corrections into the Draft > Standard version of SIP 2.0. > > 4) RAI Policies WG: We have these ongoing, not-quite-committed work > items like session policies, use of SAML, etc. that we've never been > able to get fully wrapped up. I suspect they need their own WG. Or we > need to decide that these things just aren't worth doing and stop > feeling guilty about not finishing. As it is, I don't have a good > feeling about SIP finishing them. > > 5) SIP Operations: I'd like to see SIPPING replaced with a "how to" > group possibly under the OPS banner. They could deal with all the "how > do we do X with SIP" from other SDOs. When confronted by a need to > extend SIP to meet a given need, they could then BOF up a new WG to > deal with the required extension. > > We already have working groups looking at conferencing, peering, > telephony feature interop, provisioning, peer-to-peer, NAT traversal, > > Other things that might need WGs: SPIT? Identity and Reputation? > > I also suspect we need a couple of directorates that are not WGs to > act in an advisory capacity: > > 1) RAI Security Directorate: Focuses on security review and > architectural issues in RAI documents. > > 2) RAI Event Package Directorate: Reviews and approves new SIP event > packages > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 20:41:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BAD83A6A03; Tue, 17 Jun 2008 20:41:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D9A3A6A03 for ; Tue, 17 Jun 2008 20:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 4E0qodJaVEA5 for ; Tue, 17 Jun 2008 20:41:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3B02C3A6982 for ; Tue, 17 Jun 2008 20:41:34 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2BEDF219A1; Wed, 18 Jun 2008 05:42:17 +0200 (CEST) X-AuditID: c1b4fb3e-ac995bb000004ec0-fa-4858832e3370 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C9FF02198F; Wed, 18 Jun 2008 05:38:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 05:37:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jun 2008 05:37:15 +0200 Message-ID: In-Reply-To: <48583B6A.5080404@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjQyhFVnIJsDZdxTIqbLfKXK5C1wQAKifsw References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <48583B6A.5080404@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" , "Dean Willis" X-OriginalArrivalTime: 18 Jun 2008 03:37:16.0495 (UTC) FILETIME=[9AA1C5F0:01C8D0F4] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I agree with Jonathan. Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonat= han Rosenberg Sent: 18. kes=E4kuuta 2008 1:32 To: Dean Willis Cc: sip@ietf.org Subject: Re: [Sip] INFO and what to do about it? Thanks for raising this, Dean. I think the issue here is not so much 'what do we do about INFO', but rathe= r, what are the actual extensibility models people are using with SIP and a= re we properly providing the techniques to make it all interoperate. In my = mind, that is a really important issue. In terms of what to do, I think we should absolutely define an INFO framewo= rk along the lines of Hadriel's draft, and we should produce a guidelines d= ocument which helps people figure out whether to use INFO, event packages, = or something along the lines of a media framework like I had proposed with = TOTE (separate question on whether to pursue TOTE or not). I think the huge number of actual INFO usages, along with the many reasonab= le use cases we have identified, make a clear statement that this is someth= ing that is needed. -Jonathan R. Dean Willis wrote: > We've been batting INFO around for many, many years now (like, 10 -- = > it predates the SIP working group). A couple of meetings back, we = > agreed that we would discuss use cases for INFO packages, and if we = > didn't find any consensus there, then we would go ahead and publish an = > "INFO Considered Harmful" RFC. > = > We tried having this discussion at the last IETF, but that just didn't = > work out. > = > Do we try again, or just give up and publish "INFO Considered Harmful"? > = > Personally, I don't care anymore -- I just want to drive a stake into = > the heart of this undead-thing, cut off its head, stuff the mouth with = > holy wafers, and bury it at a crossroads somewhere. > = > But this WG only slays by consensus, so what do you want? > = > -- > Dean > = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > = -- = Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 20:42:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F1E3A68B0; Tue, 17 Jun 2008 20:42:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8D53A68C5 for ; Tue, 17 Jun 2008 20:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQp++simxuhg for ; Tue, 17 Jun 2008 20:42:43 -0700 (PDT) Received: from rtp-iport-2.cisco.com (unknown [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 326E03A67F2 for ; Tue, 17 Jun 2008 20:42:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,662,1204520400"; d="scan'208";a="11326831" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2008 23:43:28 -0400 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 m5I3hRJE025382; Tue, 17 Jun 2008 23:43:27 -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.13.8) with ESMTP id m5I3hRcn000865; Wed, 18 Jun 2008 03:43:27 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.1830); Tue, 17 Jun 2008 23:43:27 -0400 Received: from [10.86.240.23] ([10.86.240.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 23:43:27 -0400 Message-ID: <4858848B.1080804@cisco.com> Date: Tue, 17 Jun 2008 23:44:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Bob Penfield References: <20080523171502.3779528C27B@core3.amsl.com> In-Reply-To: X-OriginalArrivalTime: 18 Jun 2008 03:43:27.0572 (UTC) FILETIME=[77CFA140:01C8D0F5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1123; t=1213760607; x=1214624607; 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[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-1 99-00.txt |Sender:=20 |To:=20Bob=20Penfield=20; bh=/pSuES8KrKbpe9rr4eGI67xhaQXR7YX7pS2KLOhdsaU=; b=K/OaTDnIeKefGCuiFzC4Y2mpKq6zSrDnKzvo6E9iJXAr5IX3G8pQ1jEdYy B6gtvDyghY3ftHK2ylh8qDbVI5T4S6uNJJ4/2v+ZW3DDhx1XdOv6JN3gcYz4 aQpbAZ8+R9; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Bob Penfield wrote: > On the topic of UAS's sending 199, I actually think things will work better if they did. I know there has been lots of discussion about B2BUAs doing it, but consider a UAS that is aware that it has multiple registered contacts (via presence or registration event package or other means), it might want to send the 199 to be sure that it does reach the UAC (in case the proxy does not support it). Bob, I don't understand the point you are making. Can you explain further? Are you talking about a case where there is a forking proxy in front of the UAS, and the proxy doesn't know about 199, and the UAS wants to send the 199 to give the UAC a warning in case the final response is delayed by the proxy? While there may be some cases where that would be advantageous, in many others it would just increase the message traffic for every failing call. And I don't see how the UAS would be able to discern the cases where it would be advantageous. I guess it could be configured in those cases where all inbound calls are forked, but how many such cases are there? Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 22:33:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDEB3A6918; Tue, 17 Jun 2008 22:33:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C3D3A6918 for ; Tue, 17 Jun 2008 22:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 cbd2A7OxKv+p for ; Tue, 17 Jun 2008 22:33:11 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 38B2D3A6768 for ; Tue, 17 Jun 2008 22:33:11 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5I5XkEC008405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2008 00:33:48 -0500 Message-Id: <5C078A5B-A9D9-4BA9-80EC-F7D9B08A1CC5@softarmor.com> From: Dean Willis To: Jonathan Rosenberg In-Reply-To: <48583C9A.7090309@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 18 Jun 2008 00:33:40 -0500 References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> <48583C9A.7090309@cisco.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org, Mary Barnes Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 17, 2008, at 5:37 PM, Jonathan Rosenberg wrote: > I agree with Mary - this seems like its just moving work around. > > To reiterate the mantra of SIPPING itself - what PROBLEM are you > trying to solve Dean? Is it that there is not enough people to do > the work? As Mary points out, your suggestion only makes it worse. > Is it to get more meeting slots? Is it to better align IETF work > with the needs of the actual marketplace? The problem that I'm trying to solve is making the task space manageable. The first thing is to distribute the chair load. Everybody says "The problem isn't the chairs, it;s the lack of reviewers". Well, everybody but the chairs say that, actually. If you look at the current status from the beginning of this thread, you'll see that Keith and I are the long poles in the SIP tent. Sometimes stuff waits a year for us to finish the proto writeup -- usually because when we get to doing the writeup, we find a bajillion errors the reviewers and authors missed. I typically see drafts revved at least twice during the writeup cycle, and that's a heck of a lot of work on the part of the chairs! The second problem is "learning to say no". I think WGs should have very narrowly defined charters and that it should be very, very difficult to add substantial new work to a charter. That is, it should be nearly as difficult to add work to a WG as it is to form up a new WG, and that often, the correct answer actually is "form a new WG". Perhaps even more often, the correct answer is "no". I think developing a SIP extension should be a Big Thing. If it's important enough to develop a SIP extension for, it is probably important enough to charter a working group to develop that extension. It's a Really Bad Idea to have a standing working group that sits around and develops SIP extensions. All that gets us is a whole lot of extensions. It doesn't get us any closer to a draft standard. Working groups shouldn't last ten years. Only in rare circumstances should they last two years, and the average should be more like one year. The key result of this sort of reorg is that a WG, and most especially the chairs of that WG, can be narrowly focused on a small and manageable set of deliverables. We should give them the luxury of doing one job and doing it well. Chairs should be able to do a real day-to-day job and run a working group on the side. I can tell you, SIP doesn't work that way now! Even the lousy job I do requires at least 50% of my working time, and that's going to break the bank eventually. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 17 22:37:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CD33A6901; Tue, 17 Jun 2008 22:37:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869D23A6A05 for ; Tue, 17 Jun 2008 22:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 uDpobLH2T8Cu for ; Tue, 17 Jun 2008 22:37:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4D49028C0F2 for ; Tue, 17 Jun 2008 22:37:04 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5I5bmeF008420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 18 Jun 2008 00:37:50 -0500 Message-Id: From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 18 Jun 2008 00:37:43 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] Cut-off dates reminder for IETF 72 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mary said this beautifully on SIPPING, so I'll just borrow her text and repost it here: This is a reminder of the cut-off dates for draft submission for IETF-72: - Monday, July 7th for -00s - Monday, July 14th for -01+ Refer here for complete details: http://www.ietf.org/meetings/72/72-cutoff_dates.html So, these dates are just a few weeks off and our WG agenda is due on July 16th (less than a month away). Also, please use the tool to upload your document: https://datatracker.ietf.org/idst/upload.cgi It will be published very, very quickly this way, but I will note that it does not check for ALL the nits, so it's a good idea to run idnits before submitting: http://tools.ietf.org/tools/idnits/ -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 18 05:03:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB0C3A68FC; Wed, 18 Jun 2008 05:03:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CD83A68FC for ; Wed, 18 Jun 2008 05:03:36 -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 prgao7vs8W26 for ; Wed, 18 Jun 2008 05:03:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B69603A6824 for ; Wed, 18 Jun 2008 05:03:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Wed, 18 Jun 2008 08:03:34 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 18 Jun 2008 08:03:34 -0400 From: Bob Penfield To: Paul Kyzivat Date: Wed, 18 Jun 2008 08:03:33 -0400 Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt Thread-Index: AcjQ9V3SIkA8CCRnT/eN6QXBmVfpdwAQzAEw Message-ID: References: <20080523171502.3779528C27B@core3.amsl.com> <4858848B.1080804@cisco.com> In-Reply-To: <4858848B.1080804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, June 17, 2008 11:44 PM > To: Bob Penfield > Cc: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > > > Bob Penfield wrote: > >> On the topic of UAS's sending 199, I actually think things will work >> better if they did. I know there has been lots of discussion about >> B2BUAs doing it, but consider a UAS that is aware that it has multiple >> registered contacts (via presence or registration event package or >> other means), it might want to send the 199 to be sure that it does >> reach the UAC (in case the proxy does not support it). > > Bob, I don't understand the point you are making. Can you explain further? > > Are you talking about a case where there is a forking proxy in front of > the UAS, and the proxy doesn't know about 199, and the UAS wants to send > the 199 to give the UAC a warning in case the final response is delayed > by the proxy? Yes, that is pretty much the case I was considering. > > While there may be some cases where that would be advantageous, in many > others it would just increase the message traffic for every failing > call. And I don't see how the UAS would be able to discern the cases > where it would be advantageous. I guess it could be configured in those > cases where all inbound calls are forked, but how many such cases are there? > If the UAS knows that the AOR has multiple registered contacts, it knows that inbound calls will be forked. In that case, it could send the 199. As long as proxies don't generate 199s in addition to ones they forward, the increased traffic could be limited. Having proxies generate responses on behalf of a UAS is a bit of a violation of the end-to-end principle from a purist point of view. By certainly having only proxies generate 199s would limit the increase in messages. I was just trying to point out that there might be cases where real User Agent would send 199 and not just B2BUAs. > Paul > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 18 05:32:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38BDF3A6AD7; Wed, 18 Jun 2008 05:32:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648F428C0DC for ; Wed, 18 Jun 2008 05:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 ZL56ODgu4szt for ; Wed, 18 Jun 2008 05:32:21 -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 326DC28C0F8 for ; Wed, 18 Jun 2008 05:32:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,664,1204520400"; d="scan'208";a="11381359" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Jun 2008 08:33:06 -0400 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 m5ICX6wv022278; Wed, 18 Jun 2008 08:33:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5ICX2sG020878; Wed, 18 Jun 2008 12:33:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 08:33:06 -0400 Received: from [10.86.240.23] ([10.86.240.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 08:33:02 -0400 Message-ID: <485900AB.1070902@cisco.com> Date: Wed, 18 Jun 2008 08:33:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Bob Penfield References: <20080523171502.3779528C27B@core3.amsl.com> <4858848B.1080804@cisco.com> In-Reply-To: X-OriginalArrivalTime: 18 Jun 2008 12:33:02.0618 (UTC) FILETIME=[7336DFA0:01C8D13F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3071; t=1213792386; x=1214656386; 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[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-1 99-00.txt |Sender:=20 |To:=20Bob=20Penfield=20; bh=rDlq79Mcbp5h5/dFob/hN1WtafHa1VC3Bw7NmrrkxHY=; b=EDqaskB8Zq2eTBABo6qAUjtG3quC3fpDY3Smsg0+ZTMeBVrGkgQc9Ln4PA mwvjTawr+wKU7n7ns47DbZ7epoV4XTH42XoyUFeC35xdUUnOlSedhHNAiKIa GRAjH0QhkE; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Bob Penfield wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, June 17, 2008 11:44 PM >> To: Bob Penfield >> Cc: sip@ietf.org >> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt >> >> >> Bob Penfield wrote: >> >>> On the topic of UAS's sending 199, I actually think things will work >>> better if they did. I know there has been lots of discussion about >>> B2BUAs doing it, but consider a UAS that is aware that it has multiple >>> registered contacts (via presence or registration event package or >>> other means), it might want to send the 199 to be sure that it does >>> reach the UAC (in case the proxy does not support it). >> Bob, I don't understand the point you are making. Can you explain further? >> >> Are you talking about a case where there is a forking proxy in front of >> the UAS, and the proxy doesn't know about 199, and the UAS wants to send >> the 199 to give the UAC a warning in case the final response is delayed >> by the proxy? > > Yes, that is pretty much the case I was considering. > >> While there may be some cases where that would be advantageous, in many >> others it would just increase the message traffic for every failing >> call. And I don't see how the UAS would be able to discern the cases >> where it would be advantageous. I guess it could be configured in those >> cases where all inbound calls are forked, but how many such cases are there? >> > > If the UAS knows that the AOR has multiple registered contacts, it knows that inbound calls will be forked. In that case, it could send the 199. As long as proxies don't generate 199s in addition to ones they forward, the increased traffic could be limited. How often does a UAS know that there are multiple contacts for this AOR? Even if it does, it presumably can't know if it is the last one tried, the first, or whatever. > Having proxies generate responses on behalf of a UAS is a bit of a violation of the end-to-end principle from a purist point of view. By certainly having only proxies generate 199s would limit the increase in messages. Yes, it is. > I was just trying to point out that there might be cases where real User Agent would send 199 and not just B2BUAs. I do appreciate the point that there *can* be cases where the UAS would have enough info to justify sending a 199 response. But the cases where a UAS is likely to know that in practice seem limited, with the exception of B2BUAs. I would just like to avoid giving UA developers the idea that they *ought* to be generating 199 responses on a regular basis. Doing so "to be helpful" is likely to be sub-optimal in many cases. >> Paul >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 18 12:42:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1D33A687E; Wed, 18 Jun 2008 12:42:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C935D3A67FB for ; Wed, 18 Jun 2008 12:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 yZLPO8eUKg2i for ; Wed, 18 Jun 2008 12:42:53 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 591D93A687E for ; Wed, 18 Jun 2008 12:42:53 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5IJgAS00874; Wed, 18 Jun 2008 19:42:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jun 2008 14:41:02 -0500 Message-ID: In-Reply-To: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjQyXbke5J72NsDTvGBpjhyVWwv8QArnJDQ References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> From: "Mary Barnes" To: "Dean Willis" , Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org As Jonathan noted, there is a clear need for something, as I don't see folks giving up on using INFO at all and providing some structure/standardization around the use is a good thing. The following documents are a good starting place IMHO: http://tools.ietf.org/id/draft-kaplan-sip-info-use-cases-01.txt http://tools.ietf.org/id/draft-kaplan-sip-info-events-01.txt http://tools.ietf.org/id/draft-kaplan-sipping-dtmf-package-00.txt As far as providing guidelines on what approaches folks should use depending upon requirements and problem statements, I agree with Jonathan that a document of this sort would be useful, perhaps using this document as a starting point: http://tools.ietf.org/id/draft-rosenberg-sip-info-litmus-00.txt We would of course need to decide how to partition the work either using the traditional SIP/SIPPING split of new SIP headers, etc. in SIP and event packages, informational docs, etc. in SIPPING or possibly consider this as a test case for your (Dean's) proposal of starting new WGs for new work items, since it would seem that in the end there could be a reasonable handful of work items to progress and the work could be fairly tightly scoped. Although, I fear this group would have the same difficulty in reaching a stopping point as SIP/SIPPING in terms of folks wanting to define new INFO event packages. Likely, the most contentious topic of debate is whether we need to define a general extensibility model. Given we don't have a lot of use cases (other than cases where we've already completed work or well on the way to completing), it's kinda tough to say that if we build it, folks will use it. So, personally, my opinion would be to defer this topic until we see a real need, although I realize there's a risk of not being able to deliver this in a timely manner if we wait, particularly given past history on how quickly we can complete work items. However, in one sense I feel that it's just way too late to do this sort of thing (at least in SIP 2.0). Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, June 17, 2008 5:27 PM To: sip@ietf.org Subject: [Sip] INFO and what to do about it? We've been batting INFO around for many, many years now (like, 10 -- it predates the SIP working group). A couple of meetings back, we agreed that we would discuss use cases for INFO packages, and if we didn't find any consensus there, then we would go ahead and publish an "INFO Considered Harmful" RFC. We tried having this discussion at the last IETF, but that just didn't work out. Do we try again, or just give up and publish "INFO Considered Harmful"? Personally, I don't care anymore -- I just want to drive a stake into the heart of this undead-thing, cut off its head, stuff the mouth with holy wafers, and bury it at a crossroads somewhere. But this WG only slays by consensus, so what do you want? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 18 15:25:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933263A69D9; Wed, 18 Jun 2008 15:25:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA6C3A69D9 for ; Wed, 18 Jun 2008 15:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV18dYMmublQ for ; Wed, 18 Jun 2008 15:25:31 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 6B54E3A679F for ; Wed, 18 Jun 2008 15:25:31 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id fQx31Z0030EPchoA50iL00; Wed, 18 Jun 2008 22:26:19 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id faSG1Z00U02AVH08MaSJqQ; Wed, 18 Jun 2008 22:26:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=_-sNiBJt8moA:10 a=tOApwWXgQhcA:10 a=oWnWj-26cJ_OkNzu3q0A:9 a=657_JLhXyNYpK7y1j6xQ2PVays0A:4 a=_ZcFjiH73_8A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5IMQGPO019627 for ; Wed, 18 Jun 2008 18:26:16 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5IMQEsj019623; Wed, 18 Jun 2008 18:26:14 -0400 Date: Wed, 18 Jun 2008 18:26:14 -0400 Message-Id: <200806182226.m5IMQEsj019623@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: References: Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Henry Sinnreich 3. The main deliverable of a WG is free software to validate and support the protocol document and its refinement. A good concept, but I would amend this to "... two interoperable and idependenly-implemented free softwares [grammar?] ...", as it was in the Good Old Days. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 18 16:00:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABADB3A68F4; Wed, 18 Jun 2008 16:00:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2A13A68F4 for ; Wed, 18 Jun 2008 16:00:44 -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 XYABibL+D11v for ; Wed, 18 Jun 2008 16:00:43 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 76CB23A68EA for ; Wed, 18 Jun 2008 16:00:43 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id fYUx1Z00T0b6N64A605f00; Wed, 18 Jun 2008 23:01:31 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id fb1R1Z00402AVH08Pb1Sgz; Wed, 18 Jun 2008 23:01:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=WPCZQANMUbwA:10 a=-TzPRHrdgPoA:10 a=GiKfffVuL0VWlQRq108A:9 a=Mk7zSPvhW9sDp5NuVTwA:7 a=u7nGTz6YaopWikESHUzMnDTBJDwA:4 a=f7GxY0FH8QIA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5IN1OPO022196 for ; Wed, 18 Jun 2008 19:01:24 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5IN1Ofk022192; Wed, 18 Jun 2008 19:01:24 -0400 Date: Wed, 18 Jun 2008 19:01:24 -0400 Message-Id: <200806182301.m5IN1Ofk022192@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (christer.holmberg@ericsson.com) References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Christer Holmberg" Regarding the few open items: >* Section 1 > > When a forking proxy receives a non-2xx final response, it does not > always immediately forward the response upstream towards the sender > of the associated request. Instead, the forking proxy "stores" it > and waits for further final responses from remote destinations where > the forked request was forwarded. > >The text does not allow for serial forking, only parallel forking, which might be confusing to people who are more aware >of serial forking. So amend the last sentence to: > > Instead, the forking proxy "stores" it and waits for further final > responses from remote destinations where the forked request was > forwarded, and possibly forwards the request to additional > destinations. [CHH] I can change the text. My intention was not to prevent serial forking. Because, no matter what type of forking it is, the forking proxy will "store" final responses from the different forked legs. Yes, I am sure that you did not intend to prevent or ignore serial forking. But I am afraid that the original text might lead a naive reader to assume that only parallel forking is relevant regarding 199. Fortunately, we only need to add a few words to ensure that no such misunderstanding happens. >* Section 3. > > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. > >Oddly, though everyone thinks they understand this sentence, it doesn't really say what we want. To really ensure that >the UAC understands the early dialog has been terminated before the UAS sends a final response, the UAS would have to >send 199 *and get the PRACK saying that it was received* before sending a final response. This may well be worse than >the present state of affairs. > >What we really mean is: > > REQ 1: It must be possible for a UAS or proxy to send an indication > to the UAC that an early dialog has been terminated, which > indication will not be delayed waiting for a final response from > any UAS. [CHH] I hear what you are saying, but it is a copy of the requirement text we agreed to in SIPPING. The odd thing is that although the mechanism described in the I-D solves the problem we want to solve, the requirement *as stated* does not describe the problem we want to solve, nor does the I-D satisfy the requirement as stated. It is easy, when reading the requirement to mis-interpret it (I did so myself several times), but what it says is not what we intend. How do we proceed if what SIPPING approved is not what we are interested in? >* Section 4 > >Add this paragraph before the last paragraph: > > A UAC that receives a 199 response for an early dialog MUST NOT > send any further requests on that dialog, except for a PRACK if the > 199 response was sent reliably, and PRACKs for other reliable > provisional responses that are to be acknowledged. > >This is copied from section 7 (Backward Compatibility), but since it is a constraint on UACs, it should also be stated in >this section. [CHH] Whether the text should be in the document at all depends on if we allow 199 to be sent reliably in the first place. Based on the comments received so far we should not mandate 199 to be sent reliably, even if 100rel is required by the UAC. But, the question if whether we want to FORBID sending it reliably. That is true, if we forbid reliable 199, then this proposed paragraph would be modified in parallel with the paragraph in section 7. >* Section 4 > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initiation request to be rejected. > >What is the meaning of the final clause? [CHH] Others have asked the same, so I guess it needs some modification. The meaning is that the information received in the 199 may be used to solve the HERFP problem. It is not in the scope of the document to solve that problem, just to mention that the information may be used for a future mechanism solving it. How about: "The UAC MAY use additional information (for example the final response which triggered the 199 response) received in the 199 response for additional purposes." >* Section 5 > >Add "early" as marked: > > When a UAS wants to terminate *an early* dialog it sends a non-2xx > SIP final response, as specified in [RFC3261]. In addition, prior > to sending the non-2xx SIP final response, the UAS MAY send a 199 > response to indicate that the dialog is being terminated. > >This clarifies that 199 cannot be used to terminate a confirmed dialog. [CHH] I have nothing against your proposal as such, but is this marking method that you are proposing something we normally use in IETF specs? I am using *...* to make clear the words I inserted. I do not intend that the "*" would remain in the text of the I-D. >(The reason a UAS may want to send a 199 is to provide this information even when the upstream proxy does not support >199.) > >There is a subtlty to the second sentence: > >Sending the 199 *before* the final response is not necessary due to the semantics of 199 (as it will probably reach the >UAC first anyway, and it would not matter if it did not), but rather to prevent the upstream proxy from generating a 199 >based on the final response, and then to transmit the UAS's 199 immediately after -- if the UAS sends the 199 first, any >upstream proxy will (most likely) see the 199 before seeing the final response (which might induce the proxy to send its >own 199). [CHH] This depends on whether we should keep the UAS text in the first place, or only describe when proxies send 199. Based on the comments I've received so far, we should not describe UAS behavior for sending 199. My preference is to state the explicit rule for when to send 199 that we've been discussing on the list. That rule implies all of the consequences we've discussed. It also correctly handles various peculiar situations whose proper handling might not be clear at first analysis. Example: Suppose that before ringing, a UA plays a message to the caller through a separate early dialog. So it sends the following messages: 183 Session Progress, to-tag = A, with SDP A RTP, according to SDP A 199 Early Dialog Terminated, to-tag = A 180 Ringing, to-tag = B 200 OK, to-tag = B, with SDP B Following the rule, it's clear that sending the 199 is acceptable (and it is useful). Of course, we could also analyze the UA as a proxy that forks the call serially to two UAs, one of which plays the announcement, and we would obtain the same result. But it's easier to apply the rule to the UA as a whole. >* Section 8 > >Clarify this sentence to: > > The 199 Early Dialog Terminated response code allows a SIP entity > to indicate to upstream entities that a specific early dialog has > been terminated, before a final response reaches the upstream > entities. > >Add the following: > > The early dialog that has been terminated is identified by the Call-Id > header and the to-tag value of the 199 response. > > Future standards may define optional additional information carried > in the headers and/or body of the response. [CHH] I am ok with the first sentence, but I don't understand the meaning of the other ("Future standards...") in this context. It is to allow future standardization of additional headers or body-content (e.g., to provide HERFP information). >* Section 9 > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > >This rule seems excessively strict, as it seems OK to send a new SDP answer in a 199, even if the dialog will be >immediately terminated. >Certainly, the UAC cannot tell the difference, as there could have been a previous but lost 1xx response carrying the >same SDP. > >The interaction of 199 and SDP probably needs further study... [CHH] If we are not going to specify UAS sending of 199 then there will be no SDP in it. I don't think the forking proxy should store received SDPs, and then insert one when triggering the 199. Originally, I saw no use for having an SDP body in a 199, but I saw no reason to forbid it, either. Except that I have changed my mind -- since we are reserving the body of 199 for future standardization (especially, to carry the corresponding failure response), we should avoid letting it be used for other purposes. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 18 21:08:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468D73A6A3C; Wed, 18 Jun 2008 21:08:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9622E3A6A19 for ; Wed, 18 Jun 2008 21:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 UthCoclvV1+N for ; Wed, 18 Jun 2008 21:08:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B1C933A67F9 for ; Wed, 18 Jun 2008 21:08:20 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5J491nV015347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2008 23:09:02 -0500 Message-Id: <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> From: Dean Willis To: sip@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 18 Jun 2008 23:08:55 -0500 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> X-Mailer: Apple Mail (2.924) Cc: Cullen Jennings , Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I asked: > We've been batting INFO around for many, many years now (like, 10 -- > it predates the SIP working group). A couple of meetings back, we > agreed that we would discuss use cases for INFO packages, and if we > didn't find any consensus there, then we would go ahead and publish an > "INFO Considered Harmful" RFC. > > We tried having this discussion at the last IETF, but that just didn't > work out. > > Do we try again, or just give up and publish "INFO Considered > Harmful"? > > Personally, I don't care anymore -- I just want to drive a stake into > the heart of this undead-thing, cut off its head, stuff the mouth with > holy wafers, and bury it at a crossroads somewhere. > > But this WG only slays by consensus, so what do you want? Several people (Jonathan, Mary, Christer, Paul) have responded to the list with various things that added up to "Publish INFO packages AND document the extension models for SIP". So far, nobody has suggested otherwise. Does anybody want to do anything else? Speak now or forever visualize whirled peas. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 00:43:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261083A6B6A; Thu, 19 Jun 2008 00:43:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0785028C0E6 for ; Thu, 19 Jun 2008 00:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 EiSCRuXBQB9u for ; Thu, 19 Jun 2008 00:43:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DCF203A69A7 for ; Thu, 19 Jun 2008 00:43:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5A51120CC3 for ; Thu, 19 Jun 2008 09:43:52 +0200 (CEST) X-AuditID: c1b4fb3c-ab896bb00000193b-c7-485a0e2425cc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8114420D3B for ; Thu, 19 Jun 2008 09:43:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 09:43:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 09:43:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: REFER a target-refresh Thread-Index: AcjR4DX+B+zRrlceSpuGSicwQHL2/Q== From: "Christer Holmberg" To: X-OriginalArrivalTime: 19 Jun 2008 07:43:49.0083 (UTC) FILETIME=[361D52B0:01C8D1E0] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] REFER a target-refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1210867394==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1210867394== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D1E0.360A732F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D1E0.360A732F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding the REFER method: is it a target refresh method? RFC 3515 doesn't say anything about it. However, the Contact header seems to be MANDATED in the REFER request (eventhough not shown in the examples in the draft). And, chapter 4 of RFC 4488 says: "This document defines a new SIP header field: "Refer-Sub". This header field is meaningful and MAY be used with a REFER request and the corresponding 2XX response only. This header field set to "false" specifies that a REFER-Issuer requests that the REFER- Recipient doesn't establish an implicit subscription and the resultant dialog. Note that when using this extension, the REFER remains a target refresh request (as in the default case -- when the extension is not used)." So, I guess that means that REFER IS a target refresh method? Regards, Christer ------_=_NextPart_001_01C8D1E0.360A732F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REFER a target-refresh

Hi,

I have a question regarding the = REFER method: is it a target refresh method?

RFC 3515 doesn't say anything = about it. However, the Contact header seems to be MANDATED in the REFER = request (eventhough not shown in the examples in the draft).

And, chapter 4 of RFC 4488 = says:

"This document defines a new = SIP header field: "Refer-Sub". This header field is meaningful = and MAY be used with a REFER request and the corresponding 2XX response = only. This header field set to "false" specifies that a = REFER-Issuer requests that the REFER- Recipient doesn't establish an = implicit subscription and the resultant dialog. Note that when using = this extension, the REFER remains a target refresh request (as in the = default case -- when the extension is not used)."

So, I guess that means that REFER = IS a target refresh method?

Regards,

Christer


------_=_NextPart_001_01C8D1E0.360A732F-- --===============1210867394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1210867394==-- From sip-bounces@ietf.org Thu Jun 19 02:29:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE91428C1E4; Thu, 19 Jun 2008 02:29:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7905428C1E4 for ; Thu, 19 Jun 2008 02:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 GEQEPZJHZrRs for ; Thu, 19 Jun 2008 02:29:46 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6FCB23A6B8E for ; Thu, 19 Jun 2008 02:29:46 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m5J9UXXa006752; Thu, 19 Jun 2008 04:30:33 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 04:30:33 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 11:30:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 11:30:30 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 19 Jun 2008 09:30:30.0922 (UTC) FILETIME=[1DE86EA0:01C8D1EF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Christer Holmberg Subject: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) We have been asked by the author of http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt Whether the SIP WG can progress this document. Because this draft arose as a result of the discussion of outbound, and indeed seems to reuse the requirements from outbound, and these requirements never really got handled in the SIPPING WG, it has been agreed with the SIPPING chairs that we will handle this entirely within SIP. Now in order to ask for charter milestones, and indeed when we finally present this to IESG, we will be asked for the level of support in the WG, which is also predicated on does this fix a real problem, or is it just a corner case with limited application. So: QUESTION 1 TO SIP WG: Are the use cases sufficiently important to proceed with this draft? The document states: Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] defines two keep-alive techniques. Even though the keep-alive techniques are separated from the Outbound mechanism [I-D.ietf-sip-outbound], it is currently not possible to indicate support of the keep-alive techniques without also indicating support for the Outbound mechanism. The Outbound mechanism is enabled during the UA registration phase. However, there are use-cases where the UA does not register itself, but still needs to be able to make calls and maintain NAT bindings open during the duration of that call. A typical example is emergency calls. There are also cases where entities do not support the Outbound mechanism, but still want to be able to indicate support and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. At first sight this is not the most inspiring declaration of the need for the document. Please respond indicating whether you consider this a useful draft, and propose text that you think would be useful in this section. Conversely, if you think this draft is not useful and the WG has other more important things to work on first, please also respond. QUESTION 2 TO SIP WG: Do we have a robust set of requirements for proceeding with this work? The document currently lists: REQ 1: It MUST be possible for a UA to indicate support of the keep- alive techniques defined [I-D.ietf-sip-outbound] if the UA supports only the keep-alive part of [I-D.ietf-sip-outbound]. REQ 2: It MUST be possible for an edge proxy to indicate support of the keep-alive techniques defined [I-D.ietf-sip-outbound] if the edge poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. It would be desirable to agree these at the outset, and not revisit them if we continue with the work. So if you require clarification, modification, or addition to these two requirements, then please also response with your questions and proposals. I suggest we would like responses by 30th June 2008 in order to allow the author to revise the document before the deadlines. Please note that we are looking to make this decision on the list within this deadline based on responses received, not leave it until the Dublin meeting. Regards Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 03:33:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76F53A685C; Thu, 19 Jun 2008 03:33:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974C43A6A3D for ; Thu, 19 Jun 2008 03:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.700, 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 blZctHs5OFy8 for ; Thu, 19 Jun 2008 03:33:52 -0700 (PDT) Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id E18913A685C for ; Thu, 19 Jun 2008 03:33:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,672,1204482600"; d="scan'208";a="8989656" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-2.cisco.com with ESMTP; 19 Jun 2008 16:04:40 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5JAYd8t018424; Thu, 19 Jun 2008 18:34:39 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5JAYdt7021317; Thu, 19 Jun 2008 10:34:39 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 18:34:39 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 18:34:43 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re: [Sip] REFER a target-refresh Thread-Index: AcjR+BXg7Q/mXoppTLaHmP27W6FO9A== From: "Rockson Li (zhengyli)" To: , X-OriginalArrivalTime: 19 Jun 2008 10:34:39.0488 (UTC) FILETIME=[13D50000:01C8D1F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1336; t=1213871680; x=1214735680; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20re=3A=20[Sip]=20REFER=20a=20target-refresh |Sender:=20; bh=X6MGwZaoLRYsBQ/DoZGVw0E4wyuu9IerE8sYVAAErsQ=; b=RiH0zDq8dZMwTTwz1WpR/GgM5vqrdvRIC9wYiPqtX+CHdPYwl/V15V1ZiC o5FyHy74Ol/0Kc6dMplrHf4/jOAZxBHFcx5KKCNTakynVlPUtv2Ark0kzrZl a3cZviVFV6nw2gnIC0z5mBbg7MwKo5XH36aHPcU+RyBXLlaLzHp6A=; Authentication-Results: hkg-dkim-1; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Subject: Re: [Sip] REFER a target-refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Christer, I think it's target refresh method. please check RFC5057 5.4. Target Refresh Requests Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER. Regards, -Rockson ------------------------------------------------------------------------ ----------------------------- Hi, I have a question regarding the REFER method: is it a target refresh method? RFC 3515 doesn't say anything about it. However, the Contact header seems to be MANDATED in the REFER request (eventhough not shown in the examples in the draft). And, chapter 4 of RFC 4488 says: "This document defines a new SIP header field: "Refer-Sub". This header field is meaningful and MAY be used with a REFER request and the corresponding 2XX response only. This header field set to "false" specifies that a REFER-Issuer requests that the REFER- Recipient doesn't establish an implicit subscription and the resultant dialog. Note that when using this extension, the REFER remains a target refresh request (as in the default case -- when the extension is not used)." So, I guess that means that REFER IS a target refresh method? Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 03:43:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F98D3A6B8E; Thu, 19 Jun 2008 03:43:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462543A6B8E for ; Thu, 19 Jun 2008 03:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-1.133, 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 iQGGMMExE-rh for ; Thu, 19 Jun 2008 03:43:17 -0700 (PDT) Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id 5E4DE3A6767 for ; Thu, 19 Jun 2008 03:43:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,672,1204482600"; d="scan'208";a="8990409" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-2.cisco.com with ESMTP; 19 Jun 2008 16:14:03 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5JAi402028475; Thu, 19 Jun 2008 18:44:04 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5JAi4d2023261; Thu, 19 Jun 2008 10:44:04 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 18:39:32 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 18:39:35 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re: [Sip] REFER a target-refresh Thread-Index: AcjR+BXg7Q/mXoppTLaHmP27W6FO9AAAKImA From: "Rockson Li (zhengyli)" To: , X-OriginalArrivalTime: 19 Jun 2008 10:39:32.0181 (UTC) FILETIME=[C24A6850:01C8D1F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1593; t=1213872244; x=1214736244; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20RE=3A=20re=3A=20[Sip]=20REFER=20a=20target-refr esh |Sender:=20; bh=OonjYXpZM8x3CmqnK/HH0gjhji0DeXvRgvt1adTcvpo=; b=axTLO5JJ+OZI+O6BMUoXGK8ZAc8XVDgwLTG9nOeqacZKP/Avzgr2J4ox1h 2PZLV80GAAWoHjlZ0p/PdnruLfV2/u/C1WdIsz9oOeeLbj1PxmHgNPryXmzU Pve9biSIZxKEcN0nMykHY7Y7ArdAz4IvTbBm0FxUTae8b6lw2RLEI=; Authentication-Results: hkg-dkim-2; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: Re: [Sip] REFER a target-refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org And more http://bugs.sipit.net/show_bug.cgi?id=764 -----Original Message----- From: Rockson Li (zhengyli) Sent: Thursday, June 19, 2008 6:35 PM To: 'christer.holmberg@ericsson.com'; 'sip@ietf.org' Subject: re: [Sip] REFER a target-refresh Hi Christer, I think it's target refresh method. please check RFC5057 5.4. Target Refresh Requests Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER. Regards, -Rockson ------------------------------------------------------------------------ ----------------------------- Hi, I have a question regarding the REFER method: is it a target refresh method? RFC 3515 doesn't say anything about it. However, the Contact header seems to be MANDATED in the REFER request (eventhough not shown in the examples in the draft). And, chapter 4 of RFC 4488 says: "This document defines a new SIP header field: "Refer-Sub". This header field is meaningful and MAY be used with a REFER request and the corresponding 2XX response only. This header field set to "false" specifies that a REFER-Issuer requests that the REFER- Recipient doesn't establish an implicit subscription and the resultant dialog. Note that when using this extension, the REFER remains a target refresh request (as in the default case -- when the extension is not used)." So, I guess that means that REFER IS a target refresh method? Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 03:55:35 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44063A6892; Thu, 19 Jun 2008 03:55:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406B63A6892 for ; Thu, 19 Jun 2008 03:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 QCacOwxlcvGh for ; Thu, 19 Jun 2008 03:55:33 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 043B63A67F8 for ; Thu, 19 Jun 2008 03:55:32 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58DC620C38; Thu, 19 Jun 2008 12:56:22 +0200 (CEST) X-AuditID: c1b4fb3c-ad89abb00000193b-be-485a3b56eeb2 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 39FA320C2D; Thu, 19 Jun 2008 12:56:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 12:56:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 12:56:40 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] REFER a target-refresh Thread-Index: AcjR+BXg7Q/mXoppTLaHmP27W6FO9AAAwx9g References: From: "Christer Holmberg" To: "Rockson Li (zhengyli)" , X-OriginalArrivalTime: 19 Jun 2008 10:56:40.0623 (UTC) FILETIME=[274A33F0:01C8D1FB] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] REFER a target-refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks! Regards, Christer = -----Original Message----- From: Rockson Li (zhengyli) [mailto:zhengyli@cisco.com] = Sent: 19. kes=E4kuuta 2008 13:35 To: Christer Holmberg; sip@ietf.org Subject: re: [Sip] REFER a target-refresh Hi Christer, I think it's target refresh method. please check RFC5057 5.4. Target Refresh Requests Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER. Regards, -Rockson = ------------------------------------------------------------------------ ----------------------------- Hi, = I have a question regarding the REFER method: is it a target refresh method= ? = RFC 3515 doesn't say anything about it. However, the Contact header seems t= o be MANDATED in the REFER request (eventhough not shown in the examples in= the draft). And, chapter 4 of RFC 4488 says: = "This document defines a new SIP header field: "Refer-Sub". This header fie= ld is meaningful and MAY be used with a REFER request and the corresponding= 2XX response only. This header field set to "false" specifies that a REFER-Issuer requests that the REFER- Recipient doesn't es= tablish an implicit subscription and the resultant dialog. Note that when u= sing this extension, the REFER remains a target refresh request (as in the = default case -- when the extension is not used)." So, I guess that means that REFER IS a target refresh method? = Regards, = Christer = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 05:37:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A7B3A6A30; Thu, 19 Jun 2008 05:37:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A00B3A6A1A for ; Thu, 19 Jun 2008 05:37:11 -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.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQbl7KTvHGCi for ; Thu, 19 Jun 2008 05:37:10 -0700 (PDT) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id DA4263A696B for ; Thu, 19 Jun 2008 05:37:09 -0700 (PDT) X-AuditID: cb5bdd58-a98febb000000d33-8f-485a5322776d Received: from blr-ec-aa01.wipro.com (unknown [10.201.18.41]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id 6DD22558002 for ; Thu, 19 Jun 2008 18:07:54 +0530 (IST) Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jun 2008 18:07:54 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jun 2008 18:07:53 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 18:07:57 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE06FFA879@BLR-EC-MBX02.wipro.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] REFER a target-refresh Thread-Index: AcjR+BXg7Q/mXoppTLaHmP27W6FO9AAEOVbg References: From: To: , , X-OriginalArrivalTime: 19 Jun 2008 12:37:53.0749 (UTC) FILETIME=[4B27B050:01C8D209] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] REFER a target-refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 3261 says Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. REFER does change the remote-target URI. Best Regards, Ashish Saxena 877-5570 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rockson Li (zhengyli) Sent: Thursday, June 19, 2008 4:05 PM To: christer.holmberg@ericsson.com; sip@ietf.org Subject: Re: [Sip] REFER a target-refresh Hi Christer, I think it's target refresh method. please check RFC5057 5.4. Target Refresh Requests Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER. Regards, -Rockson ------------------------------------------------------------------------ ----------------------------- Hi, I have a question regarding the REFER method: is it a target refresh method? RFC 3515 doesn't say anything about it. However, the Contact header seems to be MANDATED in the REFER request (eventhough not shown in the examples in the draft). And, chapter 4 of RFC 4488 says: "This document defines a new SIP header field: "Refer-Sub". This header field is meaningful and MAY be used with a REFER request and the corresponding 2XX response only. This header field set to "false" specifies that a REFER-Issuer requests that the REFER- Recipient doesn't establish an implicit subscription and the resultant dialog. Note that when using this extension, the REFER remains a target refresh request (as in the default case -- when the extension is not used)." So, I guess that means that REFER IS a target refresh method? Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 10:38:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9C73A68F1; Thu, 19 Jun 2008 10:38:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039623A693C for ; Thu, 19 Jun 2008 10:38:25 -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 Qd6KRWzNTdHB for ; Thu, 19 Jun 2008 10:38:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id AF8C33A68F1 for ; Thu, 19 Jun 2008 10:38:23 -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 m5JHdBR13450 for ; Thu, 19 Jun 2008 17:39:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 18:39:10 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E9005356D2B@zharhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-03 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgAWxgY1AAU+QSkADEwpDwAKKwTdA= From: "Milan Patel" To: "DRAGE, Keith (Keith)" , Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I too would like to show support for the draft being progressed as a WG ite= m. The procedures in the draft are indeed useful to 3GPP and the Proxy-Auth= entication-Info header has been included in 3GPP specifications. The additi= on of Motivation in section 3 is a useful addition to the draft. Regards, Milan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris= ter Holmberg Sent: 16 June 2008 12:43 To: DRAGE, Keith (Keith); sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 Hi, My position of the draft is supportive. Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of DRAGE= , Keith (Keith) Sent: 12. kes=E4kuuta 2008 16:50 To: sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 (As SIP WG cochair) The document has now been updated based on comments received. http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-03.txt I will give a few more days for responses to the question of support / no s= upport. Please read the draft and indicate your postion. Regards Keith = > -----Original Message----- > From: Stuart Hoggan [mailto:s.hoggan@CableLabs.com] > Sent: Tuesday, June 10, 2008 11:01 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > = > All, > = > We have updated the document to incorporate feedback received so far. > It now contains a section that helps clarify the motivation. = > Let us know if you have further comments. = > = > -Stuart > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 04, 2008 3:48 AM > > To: sip@ietf.org > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > (As SIP WG cochair) > > = > > This has been raised in the SIP group a couple of times, and we have > not > > yet gained an idea of whether to proceed with it in the SIP > WG or not. > > = > > There have been a couple of technical comments raised in > the past from > > the security experts; my understanding is that these have now been = > > clarified. > > = > > I believe in the past there has been an interested > community that says > > this is useful. It has also been clarified that 3GPP would > like to use > > it in their specifications. > > = > > So could I ask the WG to look at this document, and formally to > indicate > > whether they believe some work with this scope should be > progressed as > a > > SIP WG item. > > = > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > th-02.txt > > = > > So if you support it please indicate to the SIP WG chairs. > > = > > If you have technical concerns (i.e. it should not proceed > because it > is > > technically flawed beyond fixing) then please ideally mail > the list, > > although the SIP WG chairs will also accept input. > > = > > Responses please in 1 calendar week from this date. > > = > > Regards > > = > > Keith > > = > > = > > ________________________________ > > = > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of > > Stuart Hoggan > > Sent: Friday, May 02, 2008 5:15 PM > > To: sip@ietf.org > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > = > > = > > Folks, > > = > > = > > = > > Based on the feedback received in Philadelphia, we have updated = > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the = > > Proxy-Authentication-Info header, including support for multiple > values. > > = > > = > > = > > = > > Any further comments or suggestions will be > appreciated. It would > > also be nice to obtain WG feedback on pursuing this I-D as a WG = > > document. > > = > > = > > = > > Regards, > > = > > Stuart > > = > > = > > = > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use = > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 12:12:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D3A3A68AD; Thu, 19 Jun 2008 12:12:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62E53A684C for ; Thu, 19 Jun 2008 12:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[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 0kAXPkwepla4 for ; Thu, 19 Jun 2008 12:12:34 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 857953A68AD for ; Thu, 19 Jun 2008 12:12:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-203.messagelabs.com!1213902733!23867329!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 7001 invoked from network); 19 Jun 2008 19:12:14 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 19 Jun 2008 19:12:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5JJCShv012168 for ; Thu, 19 Jun 2008 15:12:29 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5JJCOK9012084 for ; Thu, 19 Jun 2008 15:12:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 15:12:23 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA06DBDA@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E9005356D2B@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-03 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgAWxgY1AAU+QSkADEwpDwAKKwTdAAA+NCIA== References: <0913B6CD18F370498CD65864CF254E9005356D2B@zharhxm1.corp.nortel.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Milan Patel" , "DRAGE, Keith (Keith)" , Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Keith, We are supportive of this draft. Cheers, Martin = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Milan= Patel Sent: Thursday, June 19, 2008 1:39 PM To: DRAGE, Keith (Keith); sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 Hi, I too would like to show support for the draft being progressed as a WG ite= m. The procedures in the draft are indeed useful to 3GPP and the Proxy-Auth= entication-Info header has been included in 3GPP specifications. The additi= on of Motivation in section 3 is a useful addition to the draft. Regards, Milan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris= ter Holmberg Sent: 16 June 2008 12:43 To: DRAGE, Keith (Keith); sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 Hi, My position of the draft is supportive. Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of DRAGE= , Keith (Keith) Sent: 12. kes=E4kuuta 2008 16:50 To: sip@ietf.org Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 (As SIP WG cochair) The document has now been updated based on comments received. http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-03.txt I will give a few more days for responses to the question of support / no s= upport. Please read the draft and indicate your postion. Regards Keith = > -----Original Message----- > From: Stuart Hoggan [mailto:s.hoggan@CableLabs.com] > Sent: Tuesday, June 10, 2008 11:01 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > = > All, > = > We have updated the document to incorporate feedback received so far. > It now contains a section that helps clarify the motivation. = > Let us know if you have further comments. = > = > -Stuart > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 04, 2008 3:48 AM > > To: sip@ietf.org > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > (As SIP WG cochair) > > = > > This has been raised in the SIP group a couple of times, and we have > not > > yet gained an idea of whether to proceed with it in the SIP > WG or not. > > = > > There have been a couple of technical comments raised in > the past from > > the security experts; my understanding is that these have now been = > > clarified. > > = > > I believe in the past there has been an interested > community that says > > this is useful. It has also been clarified that 3GPP would > like to use > > it in their specifications. > > = > > So could I ask the WG to look at this document, and formally to > indicate > > whether they believe some work with this scope should be > progressed as > a > > SIP WG item. > > = > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > th-02.txt > > = > > So if you support it please indicate to the SIP WG chairs. > > = > > If you have technical concerns (i.e. it should not proceed > because it > is > > technically flawed beyond fixing) then please ideally mail > the list, > > although the SIP WG chairs will also accept input. > > = > > Responses please in 1 calendar week from this date. > > = > > Regards > > = > > Keith > > = > > = > > ________________________________ > > = > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of > > Stuart Hoggan > > Sent: Friday, May 02, 2008 5:15 PM > > To: sip@ietf.org > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > = > > = > > = > > Folks, > > = > > = > > = > > Based on the feedback received in Philadelphia, we have updated = > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the = > > Proxy-Authentication-Info header, including support for multiple > values. > > = > > = > > = > > = > > Any further comments or suggestions will be > appreciated. It would > > also be nice to obtain WG feedback on pursuing this I-D as a WG = > > document. > > = > > = > > = > > Regards, > > = > > Stuart > > = > > = > > = > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use = > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 13:59:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D243A6873; Thu, 19 Jun 2008 13:59:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4FB3A6873 for ; Thu, 19 Jun 2008 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, 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 fysveaskJ6dQ for ; Thu, 19 Jun 2008 13:59:11 -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 CC8653A67ED for ; Thu, 19 Jun 2008 13:59:10 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5JKx66m047175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2008 15:59:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <42195615-199A-43A0-835C-214B9A258F0E@nostrum.com> From: Robert Sparks To: =?UTF-8?B?5a2Z5rC45YWJ?= In-Reply-To: <2374a5fb0805271811m2cdbeee1k32ec26145054bbf@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 19 Jun 2008 15:59:06 -0500 References: <4CF736A4-616A-4F37-8578-093071B3E763@nostrum.com> <2374a5fb0805271811m2cdbeee1k32ec26145054bbf@mail.gmail.com> X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.1/7507/Thu Jun 19 11:54:40 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: "sip@ietf.org List" Subject: Re: [Sip] draft-sparks-sip-invfix-01: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Zml4ZWQKT24gTWF5IDI3LCAyMDA4LCBhdCA4OjExIFBNLCDlrZnmsLjlhYkgd3JvdGU6Cgo+IEgg aSBBbGwKPgo+IDcuMS4gIFVBUyBJbXBhY3RzCj4KPiAgSWYgdGhlIFVBQydzIFRVIGlzc3VlcyBh IDJ4eCByZXNwb25zZSBmb3IgdGhpcyB0cmFuc2FjdGlvbiB3aGlsZSB0aGUKPiAgICBzdGF0ZSBt YWNoaW5lIGlzIGluIHRoZSAiUHJvY2VlZGluZyIgc3RhdGUsIGl0IE1VU1QgdHJhbnNpc2l0aW9u IHRvCj4gICAgdGhlICJBY2NlcHRlZCIgc3RhdGUgYW5kIHNldCBUaW1lciBMIHRvIDY0KlQxLgo+ Cj4gdGhlIFVBQyBzaG91bGQgYmUgVUFTCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcApUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0 aGUgY29yZSBTSVAgUHJvdG9jb2wKVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1 IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXAKVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5l dyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA== From sip-bounces@ietf.org Thu Jun 19 14:42:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012913A69DC; Thu, 19 Jun 2008 14:42:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61AC93A69DC for ; Thu, 19 Jun 2008 14:42:52 -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=[AWL=0.150, 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 AtQ0Dt2Paach for ; Thu, 19 Jun 2008 14:42:51 -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 EDA3A3A6908 for ; Thu, 19 Jun 2008 14:42:50 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5JLgkmb049631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2008 16:42:47 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Brett Tate In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 19 Jun 2008 16:42:46 -0500 References: X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.1/7508/Thu Jun 19 14:34:25 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip@ietf.org Subject: Re: [Sip] draft-sparks-sip-invfix-01: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Brett - I got to go through this very carefully today. You found a real bug here. Timer D is going to have to be set to 64*T1 without regard to transport. It needs to balance what's potentially happening on the server side with either Timer H or Timer L. I'll also go through the whole text again to see if this was an isolated bug or a class-of bug that has other instances, and will issue an update to the draft shortly. RjS On May 27, 2008, at 10:01 AM, Brett Tate wrote: > Thanks for the response. Reply inline. > >>> Section 8.4: >>> >>> Concerning timer D and "zero seconds for reliable >>> transports", is "reliable" obtained from INVITE >>> or ACK. >>> >>> Concerning timer D being zero, at first glance >>> it looks like the state machine text no longer >>> ensures ACK will be sent for extra 2xx or >>> 300-699. The same applies, to ensuring ACK resent >>> in situations where transport not reliable >>> end-to-end. Per 7.2 paragraph 2, this might be >>> intentional; if so, the motivation and flexibility >>> in handling from section 7.2 should potentially >>> also be included within 8.4. If I'm misinterpreting >>> the fix, where does it say the ACK MUST, SHOULD, or >>> MAY still be (re-)sent for the extra responses when >>> timer D is 0? >> >> Well, the main requirement you're looking for is >> (still) on the TU. But I see your point in wondering >> if a retransmitted 200 will still _get_ to the TU if >> it came over UDP. Let me look at it for awhile. > > Okay. > > >> To carve that away from some of the other questions >> you ask above: >> >> You're talking about receiving a response over a >> reliable transport (like TCP). >> >> Over such a transport, there won't _be_ any >> additional 300-699 responses unless the thing on the >> other end is violating the specification - remember >> those are hop-by-hop messages, and the thing sending >> them is required to hand reliability to the reliable >> transport (it won't retransmit - timer G is not set >> for reliable transports). The path through the machines >> when a 300-699 occurs hasn't changed from 3261. > > By extra 300-699, I was mainly referring to 1) race conditions with > 2xx > and 2) interoperability with pre-rfc3261 devices. > > 1) This should be rare since usually only results from connection > issues, threading issues, or stateless proxy issues causing the > reordering. > > 2) Unfortunately this is not as rare as everyone would like. > However it > is likely not much of an issue if the invfix chooses not to remain > backwards compatible with rfc2543 concerning resending the ACK. > > >> For a 200 class response, the transaction state machine doesn't send >> the ACK - that is still the TU's job and this draft doesn't change >> that. What we need to make sure is that we're leaving the path for a >> retransmitted (or a 200 from another branch) to _get_ to the TU. I >> thought we had, but its possible that's messed up. I'll look at it >> some more. > > Okay. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 14:57:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D863A695A; Thu, 19 Jun 2008 14:57:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A012D3A69B6 for ; Thu, 19 Jun 2008 14:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[AWL=0.075, 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 3aALFKmbGYde for ; Thu, 19 Jun 2008 14:57:43 -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 1F5743A695A for ; Thu, 19 Jun 2008 14:57:42 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5JLvdMZ050560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2008 16:57:39 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <89B3083B-309D-41D2-99CE-62803C9D8AA1@nostrum.com> From: Robert Sparks To: Robert Sparks In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 19 Jun 2008 16:57:38 -0500 References: X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.1/7508/Thu Jun 19 14:34:25 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip@ietf.org, Brett Tate Subject: Re: [Sip] draft-sparks-sip-invfix-01: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hrm. While working this over, it occurs to me that this might not be the right thing to do. It would force the client transaction to continue to exist for 32 seconds(ish) after acknowledging a >=300 response over TCP. There's no reason to do so in this case since there will never be a retransmission of the response to absorb (failure responses are hop- by-hop and the hop is TCP, so this client would not have retransmitted the request). It probably makes more sense to use another state in the client, matching the new state in the server instead of just trying to reuse this existing state. This new state would be where the client transaction sits waiting for multiple (or retransmitted) 2xx responses. The Completed state would, then, be completely unchanged from what's in 3261. Anyhow, the next rev will have a concrete proposal. RjS On Jun 19, 2008, at 4:42 PM, Robert Sparks wrote: > Hi Brett - > > I got to go through this very carefully today. You found a real bug > here. > Timer D is going to have to be set to 64*T1 without regard to > transport. > It needs to balance what's potentially happening on the server side > with > either Timer H or Timer L. > > I'll also go through the whole text again to see if this was an > isolated bug > or a class-of bug that has other instances, and will issue an update > to the > draft shortly. > > RjS > > On May 27, 2008, at 10:01 AM, Brett Tate wrote: > >> Thanks for the response. Reply inline. >> >>>> Section 8.4: >>>> >>>> Concerning timer D and "zero seconds for reliable >>>> transports", is "reliable" obtained from INVITE >>>> or ACK. >>>> >>>> Concerning timer D being zero, at first glance >>>> it looks like the state machine text no longer >>>> ensures ACK will be sent for extra 2xx or >>>> 300-699. The same applies, to ensuring ACK resent >>>> in situations where transport not reliable >>>> end-to-end. Per 7.2 paragraph 2, this might be >>>> intentional; if so, the motivation and flexibility >>>> in handling from section 7.2 should potentially >>>> also be included within 8.4. If I'm misinterpreting >>>> the fix, where does it say the ACK MUST, SHOULD, or >>>> MAY still be (re-)sent for the extra responses when >>>> timer D is 0? >>> >>> Well, the main requirement you're looking for is >>> (still) on the TU. But I see your point in wondering >>> if a retransmitted 200 will still _get_ to the TU if >>> it came over UDP. Let me look at it for awhile. >> >> Okay. >> >> >>> To carve that away from some of the other questions >>> you ask above: >>> >>> You're talking about receiving a response over a >>> reliable transport (like TCP). >>> >>> Over such a transport, there won't _be_ any >>> additional 300-699 responses unless the thing on the >>> other end is violating the specification - remember >>> those are hop-by-hop messages, and the thing sending >>> them is required to hand reliability to the reliable >>> transport (it won't retransmit - timer G is not set >>> for reliable transports). The path through the machines >>> when a 300-699 occurs hasn't changed from 3261. >> >> By extra 300-699, I was mainly referring to 1) race conditions with >> 2xx >> and 2) interoperability with pre-rfc3261 devices. >> >> 1) This should be rare since usually only results from connection >> issues, threading issues, or stateless proxy issues causing the >> reordering. >> >> 2) Unfortunately this is not as rare as everyone would like. >> However it >> is likely not much of an issue if the invfix chooses not to remain >> backwards compatible with rfc2543 concerning resending the ACK. >> >> >>> For a 200 class response, the transaction state machine doesn't send >>> the ACK - that is still the TU's job and this draft doesn't change >>> that. What we need to make sure is that we're leaving the path for a >>> retransmitted (or a 200 from another branch) to _get_ to the TU. I >>> thought we had, but its possible that's messed up. I'll look at it >>> some more. >> >> Okay. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 22:26:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0848A3A68D0; Thu, 19 Jun 2008 22:26:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7823A697D for ; Thu, 19 Jun 2008 22:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR0TKnw8zWSm for ; Thu, 19 Jun 2008 22:26:40 -0700 (PDT) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id 828273A6867 for ; Thu, 19 Jun 2008 22:26:39 -0700 (PDT) X-AuditID: cb5bdd58-a50f5bb000000d33-c5-485b3f802564 Received: from blr-ec-aa03.wipro.com (unknown [10.201.18.42]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id 2C30F558002 for ; Fri, 20 Jun 2008 10:56:24 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 10:56:23 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 10:56:23 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 10:56:21 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE06FFABC7@BLR-EC-MBX02.wipro.com> In-Reply-To: <200806182301.m5IN1Ofk022192@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjRl0/EYbU/+hKdT5qLjDHUex+HHQA/IZmA References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806182301.m5IN1Ofk022192@dragon.ariadne.com> From: To: X-OriginalArrivalTime: 20 Jun 2008 05:26:23.0922 (UTC) FILETIME=[2E075920:01C8D296] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Christer, From Section 4 (Client Behaviour) part of this draft, I understood that primary objective of this draft is to give indication to UAC to release resources, if any. I am little worried about extra messaging that will be seen because of 199 implementation. Can there be a way to tell proxies and UAS downstream that UAC has some resources reserved for this call and would be interested in receiving 199, if possible? IMO, UAC (mostly) is in better understanding of the resources that it has reserved for a particular call. So UAC can selectively add something in INVITE to tell downstream proxies/ UAS' about its interest. IMO, we can have a package for 199 and UAC can use "Supported" header to indicate entities downstream that it would be interested in getting 199 for this *particular* call. Implicitly it would mean that UAC has reserved some resources. I understand that we would changing the meaning of "Supported" header on per call basis :-(. Something else may be? Comments please. Best Regards, Ashish Saxena _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 23:10:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9BA3A6916; Thu, 19 Jun 2008 23:10:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC84A3A693E for ; Thu, 19 Jun 2008 23:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 daecvMjLc6OH for ; Thu, 19 Jun 2008 23:10:56 -0700 (PDT) Received: from web33502.mail.mud.yahoo.com (web33502.mail.mud.yahoo.com [68.142.206.151]) by core3.amsl.com (Postfix) with SMTP id 1414A3A6916 for ; Thu, 19 Jun 2008 23:10:55 -0700 (PDT) Received: (qmail 28121 invoked by uid 60001); 20 Jun 2008 06:10:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=sbg4RsSkBUtSdbtkgFjdG+D94qEamwDr4cXcL2Pcaxf8OKbWJTh/4VH/TVx37cUhfO+JCJL7V+D+o1oYjn4fA3cHMvxEtITZBbJI/U0DvmOPkPUeqDAdGuHDASdhH1vnt6CCsc2tq+w3CB8ntqwJwCYMYWjzG+W/ZwYYLl2FIsw=; Received: from [203.78.214.150] by web33502.mail.mud.yahoo.com via HTTP; Thu, 19 Jun 2008 23:10:45 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Thu, 19 Jun 2008 23:10:45 -0700 (PDT) From: brijesh nair To: sip@ietf.org In-Reply-To: <005d01c64da4$e6e5c130$1200a8c0@leo> MIME-Version: 1.0 Message-ID: <541032.28064.qm@web33502.mail.mud.yahoo.com> Subject: [Sip] Regarding provisional responses to SIP requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: briju31@yahoo.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I have a question regarding provisional responses in SIP. Can the username/displayname part of To/From header be changed in a provisional response to a SIP request ? If so, can you please direct me to a draft/rfc which states this can be done ? Thanks and Regards, Brijesh _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 19 23:55:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDCD13A6965; Thu, 19 Jun 2008 23:55:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120C93A6812 for ; Thu, 19 Jun 2008 23:55:12 -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 aKhupaGcr8-f for ; Thu, 19 Jun 2008 23:55:01 -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 D58EE3A68D0 for ; Thu, 19 Jun 2008 23:55:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204531200"; d="scan'208";a="81938275" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2008 23:55:02 -0700 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 m5K6t23g026682; Thu, 19 Jun 2008 23:55:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5K6t2gM001947; Fri, 20 Jun 2008 06:55:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 23:55:02 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.83.117]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 23:55:02 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Jun 2008 01:55:01 -0500 To: briju31@yahoo.com, sip@ietf.org From: "James M. Polk" In-Reply-To: <541032.28064.qm@web33502.mail.mud.yahoo.com> References: <005d01c64da4$e6e5c130$1200a8c0@leo> <541032.28064.qm@web33502.mail.mud.yahoo.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 20 Jun 2008 06:55:02.0475 (UTC) FILETIME=[902221B0:01C8D2A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=866; t=1213944902; x=1214808902; c=relaxed/simple; s=sjdkim4002; 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[Sip]=20Regarding=20provisional=20respo nses=20to=20SIP=20requests |Sender:=20; bh=lb19ACePwsU1IoUm8UK61dlICWAZQ0uRD53a00sjIUY=; b=asdJaqor8iFppPOszPY13UCVgwmw03n/NG7LL8yAd6AX/maH0P0RDWaPs0 gQRE1eI4fMdJYsfuhVDAhGLLl3BqFdwxHaUfzdZD1xaFDbjA6abdHvmW5mEm IfQ3gigvbA; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] Regarding provisional responses to SIP requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 01:10 AM 6/20/2008, brijesh nair wrote: >Hi, > > I have a question regarding provisional responses in SIP. Can the > username/displayname part of To/From header be changed in a > provisional response to a SIP request ? If so, can you please > direct me to a draft/rfc which states this can be done ? RFC 4474 (SIP Identity) states the display name in the To header cannot be prevented from being changed (therefore shouldn't be trusted) in any response. Does that answer your question? >Thanks and Regards, >Brijesh > > > >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 02:03:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB4A3A6969; Fri, 20 Jun 2008 02:03:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100523A6815 for ; Fri, 20 Jun 2008 02:03:58 -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 gT8QFpUpUOyu for ; Fri, 20 Jun 2008 02:03:57 -0700 (PDT) Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id 481F93A6969 for ; Fri, 20 Jun 2008 02:03:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204482600"; d="scan'208";a="9083757" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-2.cisco.com with ESMTP; 20 Jun 2008 14:33:54 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5K93sWH020746; Fri, 20 Jun 2008 17:03:54 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5K93qII018421; Fri, 20 Jun 2008 09:03:54 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 17:03:53 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 17:03:58 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Sip] Regarding provisional responses to SIP requests Thread-Index: AcjStJMw7VfRAAnzQx+lO8oLccHgFA== From: "Rockson Li (zhengyli)" To: X-OriginalArrivalTime: 20 Jun 2008 09:03:53.0005 (UTC) FILETIME=[8FE365D0:01C8D2B4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2531; t=1213952634; x=1214816634; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20Re=3A=20[Sip]=20Regarding=20provisional=20respo nses=20to=20SIP=20requests |Sender:=20; bh=HS/2hlyIlBBzaVsAsgAXN7IqoHoum4Gm8GR9VH94Aiw=; b=VvSfRiGCKaAEpXIfHI0EgmqXuvtc4isYwoU7HOxdlpg0M+CXrNEaR0QChF TKbePjRo/DMz4ULOYdKi8UxGkS6L3XSuEmg0r/w17/WhM5pt0divkTrQVMNl 7slzkNm7+ocUXF5DglRFCf8NIDWYtu+y1FYAxijawjclthfAoWz6A=; Authentication-Results: hkg-dkim-2; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Regarding provisional responses to SIP requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Brijesh, For RFC3261-complianet UA, this can be done, the main concern over this modification is dialog matching. RFC2543 use whole from/to/call-id header to match dialog, whereas, RFC3261 uses only from tag / to tag/call-id So we can find in RFC sec5.3 Currently, dialog matching uses only the tags in the To and From headers, rather than the whole header fields. Thus, under the new rules the URI values in the To and From headers themselves could be altered by intermediaries. However, some legacy clients might consider it an error condition if the value of the URI in the From header altered between the request and the response. But to better cover RFC2543 UA it later says, Therefore, any time that a privacy service needs to modify any dialog-matching headers for privacy reasons, it SHOULD act as a transparent back-to-back user agent, and it MUST persist the former values of the dialog-matching headers. These values MUST be restored in any messages that are sent to the originating user agent. So, IMO, if the UAs you are facing is based on RFC3261, I think the from header change is OK. Regards, -Rockson On Fri, Jun 20, 2008 at 2:55 PM, James M. Polk wrote: > At 01:10 AM 6/20/2008, brijesh nair wrote: > > Hi, > > > > I have a question regarding provisional responses in SIP. Can the > > username/displayname part of To/From header be changed in a > > provisional response to a SIP request ? If so, can you please > > direct me to a draft/rfc which states this can be done ? > > RFC 4474 (SIP Identity) states the display name in the To header cannot be prevented from being changed (therefore shouldn't be trusted) in any response. Does that answer your question? > > > > > Thanks and Regards, > > Brijesh > > > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 02:31:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A253A6913; Fri, 20 Jun 2008 02:31:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8C53A6913 for ; Fri, 20 Jun 2008 02:31:40 -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 nrYvyf5GLuxr for ; Fri, 20 Jun 2008 02:31:39 -0700 (PDT) Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id BDBA13A68F4 for ; Fri, 20 Jun 2008 02:31:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204482600"; d="scan'208";a="9086354" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-2.cisco.com with ESMTP; 20 Jun 2008 15:01:37 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5K9VbKw022432; Fri, 20 Jun 2008 17:31:37 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5K9UNMI023930; Fri, 20 Jun 2008 09:31:37 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 17:31:03 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 17:31:09 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Sip] Regarding provisional responses to SIP requests Thread-Index: AcjStJMw7VfRAAnzQx+lO8oLccHgFAAA4Khg From: "Rockson Li (zhengyli)" To: X-OriginalArrivalTime: 20 Jun 2008 09:31:03.0647 (UTC) FILETIME=[5BD39EF0:01C8D2B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2806; t=1213954297; x=1214818297; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20RE=3A=20Re=3A=20[Sip]=20Regarding=20provisional =20responses=20to=20SIP=20requests |Sender:=20; bh=0ClyUseis9Sdfai6DbRNHbjpYcb2EPN45zpZpWrVwK0=; b=FUDMUgS0PQDl1pnFJgXqSwgyqJ3NELnR/vLy0H8W3koUscTrUXl1G5DXDv LzCiJ0SOeN2do8EGoED9L17+jQh3WCum51KvWsuPqTAY69gu5qpRvgvSs1h9 1oirlRry5oEGkD+dBiIKYU8q2QGDpCLZYz7RdZkv3cwKgvdXImS38=; Authentication-Results: hkg-dkim-1; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Regarding provisional responses to SIP requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Forget the RFC id , RFC3323 -----Original Message----- From: Rockson Li (zhengyli) Sent: Friday, June 20, 2008 5:04 PM To: 'briju31@yahoo.com' Cc: 'sip@ietf.org' Subject: Re: [Sip] Regarding provisional responses to SIP requests Hi Brijesh, For RFC3261-complianet UA, this can be done, the main concern over this modification is dialog matching. RFC2543 use whole from/to/call-id header to match dialog, whereas, RFC3261 uses only from tag / to tag/call-id So we can find in RFC sec5.3 [Rockson]RFC3323 Currently, dialog matching uses only the tags in the To and From headers, rather than the whole header fields. Thus, under the new rules the URI values in the To and From headers themselves could be altered by intermediaries. However, some legacy clients might consider it an error condition if the value of the URI in the From header altered between the request and the response. But to better cover RFC2543 UA it later says, Therefore, any time that a privacy service needs to modify any dialog-matching headers for privacy reasons, it SHOULD act as a transparent back-to-back user agent, and it MUST persist the former values of the dialog-matching headers. These values MUST be restored in any messages that are sent to the originating user agent. So, IMO, if the UAs you are facing is based on RFC3261, I think the from header change is OK. Regards, -Rockson On Fri, Jun 20, 2008 at 2:55 PM, James M. Polk wrote: > At 01:10 AM 6/20/2008, brijesh nair wrote: > > Hi, > > > > I have a question regarding provisional responses in SIP. Can the > > username/displayname part of To/From header be changed in a > > provisional response to a SIP request ? If so, can you please direct > > me to a draft/rfc which states this can be done ? > > RFC 4474 (SIP Identity) states the display name in the To header cannot be prevented from being changed (therefore shouldn't be trusted) in any response. Does that answer your question? > > > > > Thanks and Regards, > > Brijesh > > > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 10:20:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA4C3A6991; Fri, 20 Jun 2008 10:20:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BDD53A697F for ; Fri, 20 Jun 2008 10:20:26 -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 tOM7J977EEur for ; Fri, 20 Jun 2008 10:20:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 185B63A63EC for ; Fri, 20 Jun 2008 10:20:22 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 20 Jun 2008 13:19:35 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 20 Jun 2008 13:19:35 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "sip@ietf.org" Date: Fri, 20 Jun 2008 13:19:35 -0400 Thread-Topic: Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQ Message-ID: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My 2 cents: it is a useful draft. Personally, I would like to have it available for two reasons not cited: PBX connections a la SIP trunks, and proxy-proxy connections. Today I think a lot of people are using OPTIONS requests or proprietary means to perform such keep-alives when registration is not appropriate, but it has led to some interop issues and performance concerns in some cases. Since the contentious issue of what form the keep-alives take have already been agreed on for outbound, this seems like a simple draft to get done. (famous last words, I know) -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: Thursday, June 19, 2008 5:31 AM > To: sip@ietf.org > Cc: Christer Holmberg > Subject: [Sip] Progress draft-holmberg-sip-keep > > (As SIP WG cochair) > > We have been asked by the author of > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > Whether the SIP WG can progress this document. > > Because this draft arose as a result of the discussion of outbound, and > indeed seems to reuse the requirements from outbound, and these > requirements never really got handled in the SIPPING WG, it has been > agreed with the SIPPING chairs that we will handle this entirely within > SIP. > > Now in order to ask for charter milestones, and indeed when we finally > present this to IESG, we will be asked for the level of support in the > WG, which is also predicated on does this fix a real problem, or is it > just a corner case with limited application. So: > > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to > proceed with this draft? The document states: > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > defines two keep-alive techniques. Even though the keep-alive > techniques are separated from the Outbound mechanism > [I-D.ietf-sip-outbound], it is currently not possible to indicate > support of the keep-alive techniques without also indicating support > for the Outbound mechanism. > > The Outbound mechanism is enabled during the UA registration phase. > However, there are use-cases where the UA does not register itself, > but still needs to be able to make calls and maintain NAT bindings > open during the duration of that call. A typical example is > emergency calls. There are also cases where entities do not support > the Outbound mechanism, but still want to be able to indicate support > and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. > > At first sight this is not the most inspiring declaration of the need > for the document. Please respond indicating whether you consider this a > useful draft, and propose text that you think would be useful in this > section. Conversely, if you think this draft is not useful and the WG > has other more important things to work on first, please also respond. > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for > proceeding with this work? The document currently lists: > > REQ 1: It MUST be possible for a UA to indicate support of the keep- > alive techniques defined [I-D.ietf-sip-outbound] if the UA supports > only the keep-alive part of [I-D.ietf-sip-outbound]. > > REQ 2: It MUST be possible for an edge proxy to indicate support of > the keep-alive techniques defined [I-D.ietf-sip-outbound] if the edge > poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. > > It would be desirable to agree these at the outset, and not revisit them > if we continue with the work. So if you require clarification, > modification, or addition to these two requirements, then please also > response with your questions and proposals. > > I suggest we would like responses by 30th June 2008 in order to allow > the author to revise the document before the deadlines. Please note that > we are looking to make this decision on the list within this deadline > based on responses received, not leave it until the Dublin meeting. > > Regards > > Keith > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 10:22:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8873A697F; Fri, 20 Jun 2008 10:22:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7383A697F for ; Fri, 20 Jun 2008 10:22:04 -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 r5-FGwm-qk8h for ; Fri, 20 Jun 2008 10:22:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7A31A3A63EC for ; Fri, 20 Jun 2008 10:22:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 20 Jun 2008 13:21:16 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 20 Jun 2008 13:21:17 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "sip@ietf.org" Date: Fri, 20 Jun 2008 13:21:16 -0400 Thread-Topic: [Sip] draft-dotson-sip-mutual-auth-03 Thread-Index: Acisb7EWlf1RomROQAK7pEwUUCOO4gZIj1CgAWxgY1AAU+QSkADEwpDwAKKwTdAAA+NCIAAuAb+w Message-ID: References: <0913B6CD18F370498CD65864CF254E9005356D2B@zharhxm1.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA06DBDA@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA06DBDA@gaalpa1msgusr7e.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Same here. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > DOLLY, MARTIN C, ATTLABS > Sent: Thursday, June 19, 2008 3:12 PM > To: Milan Patel; DRAGE, Keith (Keith); sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 > > Keith, > > We are supportive of this draft. > > Cheers, > > Martin > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Milan Patel > Sent: Thursday, June 19, 2008 1:39 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 > > Hi, > > I too would like to show support for the draft being progressed as a WG > item. The procedures in the draft are indeed useful to 3GPP and the Proxy- > Authentication-Info header has been included in 3GPP specifications. The > addition of Motivation in section 3 is a useful addition to the draft. > > Regards, > Milan > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 16 June 2008 12:43 > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 > > > Hi, > > My position of the draft is supportive. > > Regards, > > Christer > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: 12. kes=E4kuuta 2008 16:50 > To: sip@ietf.org > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-03 > > (As SIP WG cochair) > > The document has now been updated based on comments received. > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-03.txt > > I will give a few more days for responses to the question of support / no > support. > > Please read the draft and indicate your postion. > > Regards > > Keith > > > -----Original Message----- > > From: Stuart Hoggan [mailto:s.hoggan@CableLabs.com] > > Sent: Tuesday, June 10, 2008 11:01 PM > > To: DRAGE, Keith (Keith); sip@ietf.org > > Subject: RE: [Sip] draft-dotson-sip-mutual-auth-02 > > > > All, > > > > We have updated the document to incorporate feedback received so far. > > It now contains a section that helps clarify the motivation. > > Let us know if you have further comments. > > > > -Stuart > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > DRAGE, Keith (Keith) > > > Sent: Wednesday, June 04, 2008 3:48 AM > > > To: sip@ietf.org > > > Subject: Re: [Sip] draft-dotson-sip-mutual-auth-02 > > > > > > (As SIP WG cochair) > > > > > > This has been raised in the SIP group a couple of times, and we have > > not > > > yet gained an idea of whether to proceed with it in the SIP > > WG or not. > > > > > > There have been a couple of technical comments raised in > > the past from > > > the security experts; my understanding is that these have now been > > > clarified. > > > > > > I believe in the past there has been an interested > > community that says > > > this is useful. It has also been clarified that 3GPP would > > like to use > > > it in their specifications. > > > > > > So could I ask the WG to look at this document, and formally to > > indicate > > > whether they believe some work with this scope should be > > progressed as > > a > > > SIP WG item. > > > > > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-au > > th-02.txt > > > > > > So if you support it please indicate to the SIP WG chairs. > > > > > > If you have technical concerns (i.e. it should not proceed > > because it > > is > > > technically flawed beyond fixing) then please ideally mail > > the list, > > > although the SIP WG chairs will also accept input. > > > > > > Responses please in 1 calendar week from this date. > > > > > > Regards > > > > > > Keith > > > > > > > > > ________________________________ > > > > > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > Stuart Hoggan > > > Sent: Friday, May 02, 2008 5:15 PM > > > To: sip@ietf.org > > > Subject: [Sip] draft-dotson-sip-mutual-auth-02 > > > > > > > > > > > > Folks, > > > > > > > > > > > > Based on the feedback received in Philadelphia, we have updated > > > draft-dotson-sip-mutual-auth. The changes clarify the usage of the > > > Proxy-Authentication-Info header, including support for multiple > > values. > > > > > > > > > > > > > > > Any further comments or suggestions will be > > appreciated. It would > > > also be nice to obtain WG feedback on pursuing this I-D as a WG > > > document. > > > > > > > > > > > > Regards, > > > > > > Stuart > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use sip- > implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 11:03:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34533A6A6E; Fri, 20 Jun 2008 11:03:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299233A6A6E for ; Fri, 20 Jun 2008 11:03:21 -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 OIIzVmmYEn1X for ; Fri, 20 Jun 2008 11:03:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3CB293A67B3 for ; Fri, 20 Jun 2008 11:03:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 20 Jun 2008 14:02:34 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 20 Jun 2008 14:02:34 -0400 From: Hadriel Kaplan To: Henry Sinnreich , Dean Willis , "sip@ietf.org" Date: Fri, 20 Jun 2008 14:02:34 -0400 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjQ6vWDeIPZmyuRxEyyjBJr1fkb6gCD88rQ Message-ID: References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Henry Sinnreich > > 3. The main deliverable of a WG is free software to validate and support > the > protocol document and its refinement. If no free software is contributed, > the WG activity should be suspended. Internet-Drafts not supported by > freely > available software (that can be inspected and tried out) and measurements > cannot be proven right or wrong and should therefore be ignored. > There is plenty of IEEE and University work to prove this approach, which > was also the basis for the rise and success of the IETF. Since when is the main deliverable of the IETF free software? The main deliverable of the IETF is documentation, for the purpose of achieving interoperability, to make the Internet better. That's it. (i.e., RFC 3935) Open source implementation is one means to an end goal, not the end goal itself. And as it is, I think some of the extensions in SIP have *only* been implemented in open source software and never seen the light of day in real world use even of that open source software. (or in any degree one would consider "broad use") In that sense, maybe we should only continue work in things that have seen commercial implementation! ;) -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 11:16:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B543A6997; Fri, 20 Jun 2008 11:16:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9628C3A6997 for ; Fri, 20 Jun 2008 11:16:36 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCqTOI3TBWSa for ; Fri, 20 Jun 2008 11:16:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 70CDE3A6807 for ; Fri, 20 Jun 2008 11:16:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 20 Jun 2008 14:15:49 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 20 Jun 2008 14:15:49 -0400 From: Hadriel Kaplan To: Dean Willis , "sip@ietf.org" Date: Fri, 20 Jun 2008 14:15:48 -0400 Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjRwiMGEJYJUmj+TL2Tv4/2d3sJyQBPJv4A Message-ID: References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> In-Reply-To: <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Cullen Jennings , Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org [Not surprisingly] I also think we should just do it. I don't know if it will succeed, but the longer we wait the less the probability it will. Right now people have to provision devices to send XYZ thing in INFO, and different vendors are using different syntaxes/means for the same mechanism, and I loathe that. If we want to stop devices in the middle from meddling, we need to stop giving them reasons to. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Thursday, June 19, 2008 12:09 AM > To: sip@ietf.org > Cc: Cullen Jennings; Jon Peterson > Subject: Re: [Sip] INFO and what to do about it? > > I asked: > > > > We've been batting INFO around for many, many years now (like, 10 -- > > it predates the SIP working group). A couple of meetings back, we > > agreed that we would discuss use cases for INFO packages, and if we > > didn't find any consensus there, then we would go ahead and publish an > > "INFO Considered Harmful" RFC. > > > > We tried having this discussion at the last IETF, but that just didn't > > work out. > > > > Do we try again, or just give up and publish "INFO Considered > > Harmful"? > > > > Personally, I don't care anymore -- I just want to drive a stake into > > the heart of this undead-thing, cut off its head, stuff the mouth with > > holy wafers, and bury it at a crossroads somewhere. > > > > But this WG only slays by consensus, so what do you want? > > Several people (Jonathan, Mary, Christer, Paul) have responded to the > list with various things that added up to "Publish INFO packages AND > document the extension models for SIP". So far, nobody has suggested > otherwise. > > Does anybody want to do anything else? Speak now or forever visualize > whirled peas. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 11:32:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C026C3A6A8C; Fri, 20 Jun 2008 11:32:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F84528C137 for ; Fri, 20 Jun 2008 11:32:17 -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 IxOw5PYL33yB for ; Fri, 20 Jun 2008 11:32:16 -0700 (PDT) Received: from outbound-nd.Cantata.com (outbound-nd.cantata.com [204.176.74.8]) by core3.amsl.com (Postfix) with ESMTP id 7C1A13A6A83 for ; Fri, 20 Jun 2008 11:32:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 14:32:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjRwiMGEJYJUmj+TL2Tv4/2d3sJyQBPJv4AAAExlAA= References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> From: "Rafferty, James" To: "Hadriel Kaplan" , "Dean Willis" , Cc: Cullen Jennings , Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree with Hadriel on this one. I'm getting requests for different oddba= ll uses of INFO all of the time, most of them driven by the need to interop= erate with deployed applications. Creating real INFO packages would give u= s a way to increase the likelihood of interoperability for the different us= es. Is it too late? Hard to say, but it is worth a shot. = James = James Rafferty = Product Line Director, Integrated Media Gateways = Dialogic, Inc.=A0 = 15 Crawford Street = Needham, MA 02494 = USA = Tel:=A0=A0=A0 781 433 9462 Mobile: 781 929 3895 Fax:=A0=A0=A0 781 433 9268 Email:=A0 james.rafferty@dialogic.com Web:=A0=A0=A0 www.dialogic.com This e-mail is intended only for the named recipient(s) and may contain inf= ormation that is privileged, confidential and/or exempt from disclosure und= er applicable law. No waiver of privilege, confidence or otherwise is inten= ded by virtue of communication via the internet. Any unauthorized use, diss= emination or copying is strictly prohibited. If you have received this e-ma= il in error, or are not named as a recipient, please immediately notify the= sender and destroy all copies of this e-mail. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hadri= el Kaplan Sent: Friday, June 20, 2008 2:16 PM To: Dean Willis; sip@ietf.org Cc: Cullen Jennings; Jon Peterson Subject: Re: [Sip] INFO and what to do about it? [Not surprisingly] I also think we should just do it. I don't know if it w= ill succeed, but the longer we wait the less the probability it will. Righ= t now people have to provision devices to send XYZ thing in INFO, and diffe= rent vendors are using different syntaxes/means for the same mechanism, and= I loathe that. If we want to stop devices in the middle from meddling, we= need to stop giving them reasons to. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Thursday, June 19, 2008 12:09 AM > To: sip@ietf.org > Cc: Cullen Jennings; Jon Peterson > Subject: Re: [Sip] INFO and what to do about it? > > I asked: > > > > We've been batting INFO around for many, many years now (like, 10 -- > > it predates the SIP working group). A couple of meetings back, we > > agreed that we would discuss use cases for INFO packages, and if we > > didn't find any consensus there, then we would go ahead and publish an > > "INFO Considered Harmful" RFC. > > > > We tried having this discussion at the last IETF, but that just didn't > > work out. > > > > Do we try again, or just give up and publish "INFO Considered > > Harmful"? > > > > Personally, I don't care anymore -- I just want to drive a stake into > > the heart of this undead-thing, cut off its head, stuff the mouth with > > holy wafers, and bury it at a crossroads somewhere. > > > > But this WG only slays by consensus, so what do you want? > > Several people (Jonathan, Mary, Christer, Paul) have responded to the > list with various things that added up to "Publish INFO packages AND > document the extension models for SIP". So far, nobody has suggested > otherwise. > > Does anybody want to do anything else? Speak now or forever visualize > whirled peas. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 11:50:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1E03A68FA; Fri, 20 Jun 2008 11:50:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970B13A68FA for ; Fri, 20 Jun 2008 11:50:17 -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 orqlayTUe+ru for ; Fri, 20 Jun 2008 11:50:16 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 8C66E3A684D for ; Fri, 20 Jun 2008 11:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 45C361EC1FC; Fri, 20 Jun 2008 21:50:17 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtWTKx6oSPdg; Fri, 20 Jun 2008 21:50:07 +0300 (EEST) Received: from taimen (h144195.gprs.dnafinland.fi [87.93.144.195]) by tutpro.com (Postfix) with ESMTP; Fri, 20 Jun 2008 21:50:07 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id B3794AC106; Fri, 20 Jun 2008 21:50:00 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18523.64472.706506.741194@taimen.test.fi> Date: Fri, 20 Jun 2008 21:50:00 +0300 To: Hadriel Kaplan In-Reply-To: References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> X-Mailer: VM 7.19 under Emacs 22.1.1 From: jh@tutpro.com (Juha Heinanen) Cc: "sip@ietf.org" , Henry Sinnreich , Dean Willis Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan writes: > The main deliverable of the IETF is documentation, for the purpose of > achieving interoperability, to make the Internet better. please let me know how all those 3gpp/ims related drafts/rfcs that sip[ping] wgs have produced help to make Internet better? -- juha _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 12:28:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C8D3A69D2; Fri, 20 Jun 2008 12:28:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2AA3A699E for ; Fri, 20 Jun 2008 12:28:01 -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 PjHeAIPDVCxf for ; Fri, 20 Jun 2008 12:28:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 558FE3A69D2 for ; Fri, 20 Jun 2008 12:28:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 20 Jun 2008 15:27:13 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 20 Jun 2008 15:27:13 -0400 From: Hadriel Kaplan To: Juha Heinanen Date: Fri, 20 Jun 2008 15:27:13 -0400 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjTBmDvc0ryxuyTTmqbL3VpKEkAFwAARMAQ Message-ID: References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> <18523.64472.706506.741194@taimen.test.fi> In-Reply-To: <18523.64472.706506.741194@taimen.test.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Henry Sinnreich , Dean Willis Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If by "3GPP/IMS related drafts/rfcs" you mean the P-headers in 3455, it's the IETF that wanted them to be submitted I thought. It's only informational. What drafts were you thinking of? They use the Internet, or their private networks connect to the Internet, and thus we should want them to tell us what they feel is missing from SIP. We can use the info to decide if it's generally useful for everyone, or not, or even as an example of what not to do and try to persuade them down a different path. They potentially represent a significant population of UA's that we should want to be reachable over the Internet in some form, to/from pure IETF-compliant UA's. -hadriel > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, June 20, 2008 2:50 PM > To: Hadriel Kaplan > Cc: Henry Sinnreich; Dean Willis; sip@ietf.org > Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups > > Hadriel Kaplan writes: > > > The main deliverable of the IETF is documentation, for the purpose of > > achieving interoperability, to make the Internet better. > > please let me know how all those 3gpp/ims related drafts/rfcs that > sip[ping] wgs have produced help to make Internet better? > > -- juha _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 20 13:23:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4213A683E; Fri, 20 Jun 2008 13:23:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD68B3A683E for ; Fri, 20 Jun 2008 13:23:47 -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 8iqCLzhEbjow for ; Fri, 20 Jun 2008 13:23:46 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 337AE3A67D1 for ; Fri, 20 Jun 2008 13:23:43 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Fri, 20 Jun 2008 13:23:44 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m5KKKKG3025541; Fri, 20 Jun 2008 13:20:21 -0700 (PDT) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m5KKL3qh002427; Fri, 20 Jun 2008 13:23:27 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jun 2008 05:22:18 +0900 Received: from 10.48.76.113 ([10.48.76.113]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jun 2008 20:22:11 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 20 Jun 2008 15:22:10 -0500 From: Henry Sinnreich To: Hadriel Kaplan , Dean Willis , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjQ6vWDeIPZmyuRxEyyjBJr1fkb6gCD88rQAAYjIcQ= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 20 Jun 2008 20:22:18.0773 (UTC) FILETIME=[566AAC50:01C8D313] Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > The main deliverable of the IETF is documentation, for the purpose of > achieving interoperability, to make the Internet better. Docs without Code Documentation without available code has led us to use Jabber IM in the SIMPLE WG meetings. Is this a success story for SIMPLE/SIP? Serial Writers Other harmful effects of writing specs on the editor "platform" is the deluge of SIP related RFCs and I-Ds since there is no threshold to stop serial writers. * Does anyone expect developers to read and understand the 100's of documents? * How can the concepts and definitions in a document without code be proven in the first place? By discussion and voting? In Conflict With The Internet Principles Last but not least, supporting commercial products or business plans is not the same as supporting the Internet. There may be actually a fundamental conflict here, for example closed stacks vs. the e2e principle, supporting Internet transparency, etc. It is the reason why all work related to the service provider market, which is important work BTW, should be moved to the ITU-T IMO. These topics deserves however a larger discussion, outside of this list. Enjoy the weekend, Henry On 6/20/08 1:02 PM, "Hadriel Kaplan" wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Henry Sinnreich >> >> 3. The main deliverable of a WG is free software to validate and support >> the >> protocol document and its refinement. If no free software is contributed, >> the WG activity should be suspended. Internet-Drafts not supported by >> freely >> available software (that can be inspected and tried out) and measurements >> cannot be proven right or wrong and should therefore be ignored. >> There is plenty of IEEE and University work to prove this approach, which >> was also the basis for the rise and success of the IETF. > > Since when is the main deliverable of the IETF free software? > > The main deliverable of the IETF is documentation, for the purpose of > achieving interoperability, to make the Internet better. That's it. (i.e., > RFC 3935) Open source implementation is one means to an end goal, not the end > goal itself. > > And as it is, I think some of the extensions in SIP have *only* been > implemented in open source software and never seen the light of day in real > world use even of that open source software. (or in any degree one would > consider "broad use") In that sense, maybe we should only continue work in > things that have seen commercial implementation! ;) > > -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.kirstenpfad@navigate-online.de Fri Jun 20 21:08:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB3A3A68B8; Fri, 20 Jun 2008 21:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.697 X-Spam-Level: X-Spam-Status: No, score=-88.697 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 EOPaUNaiq4h1; Fri, 20 Jun 2008 21:08:51 -0700 (PDT) Received: from 139-59-112.adsl.terra.cl (139-59-112.adsl.terra.cl [200.112.59.139]) by core3.amsl.com (Postfix) with SMTP id 9FD463A683C; Fri, 20 Jun 2008 21:08:41 -0700 (PDT) X-Originating-IP: 68.60.221.97 by smtp.200.112.59.139; Sat, 21 Jun 2008 00:08:44 -0500 Message-ID: From: "Adrian Brennan" Reply-To: "Adrian Brennan" To: send-archive@ietf.org Subject: Get 15% off these watches Date: Sat, 21 Jun 2008 00:08:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://gerinedipin61.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://gerinedipin61.blogspot.com/ From sip-bounces@ietf.org Sat Jun 21 09:28:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB0B3A6961; Sat, 21 Jun 2008 09:28:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D0D3A6986 for ; Sat, 21 Jun 2008 09:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.08 X-Spam-Level: X-Spam-Status: No, score=-104.08 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 uixV24ChThkJ for ; Sat, 21 Jun 2008 09:28:48 -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 A83853A69A1 for ; Sat, 21 Jun 2008 09:28:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,684,1204531200"; d="scan'208";a="82367854" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2008 09:28:26 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5LGSQrc031845; Sat, 21 Jun 2008 09:28:26 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m5LGSH5i008146; Sat, 21 Jun 2008 16:28:26 GMT Message-Id: From: Cullen Jennings To: Dean Willis In-Reply-To: <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 19 Jun 2008 17:49:00 -0600 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> X-Mailer: Apple Mail (2.924) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1462; t=1214065706; x=1214929706; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=DGAfW7zP3KBBIB/45woZZLmiizXlDQtsG1m1KfNbmDU=; b=g/UcdOGImc63Can6gEka088INnf5gRVAygX29aRI4XrrxJDnvicolc147S R0mJwS2VebltIXxwrBiobsuigamrjvOynTVosVe9xKKLSnw8fCyGnDQsUiBe Q06XyM7/L+xqx5VK5Xud2+/F6jdWrTBs56JTmQHGYfS1RK3ckBjB8=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Personally, I'd like to see some coherent discussion around it in a WG meeting then try to get to consensus on it. The totally number of people bothering to follow the conversation at this point is extremely low. On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: > I asked: > > > > We've been batting INFO around for many, many years now (like, 10 -- > > it predates the SIP working group). A couple of meetings back, we > > agreed that we would discuss use cases for INFO packages, and if we > > didn't find any consensus there, then we would go ahead and > publish an > > "INFO Considered Harmful" RFC. > > > > We tried having this discussion at the last IETF, but that just > didn't > > work out. > > > > Do we try again, or just give up and publish "INFO Considered > > Harmful"? > > > > Personally, I don't care anymore -- I just want to drive a stake > into > > the heart of this undead-thing, cut off its head, stuff the mouth > with > > holy wafers, and bury it at a crossroads somewhere. > > > > But this WG only slays by consensus, so what do you want? > > Several people (Jonathan, Mary, Christer, Paul) have responded to the > list with various things that added up to "Publish INFO packages AND > document the extension models for SIP". So far, nobody has suggested > otherwise. > > Does anybody want to do anything else? Speak now or forever visualize > whirled peas. > > -- > Dean > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 21 12:10:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4853A6858; Sat, 21 Jun 2008 12:10:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F083A6887 for ; Sat, 21 Jun 2008 12:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.905 X-Spam-Level: X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, 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 O2HL8Vxucb27 for ; Sat, 21 Jun 2008 12:10:38 -0700 (PDT) Received: from smtp05.bis.na.blackberry.com (smtp05.bis.na.blackberry.com [216.9.248.52]) by core3.amsl.com (Postfix) with ESMTP id 5E6CC3A67F7 for ; Sat, 21 Jun 2008 12:10:34 -0700 (PDT) Received: from bda379.bisx.prod.on.blackberry (bda379.bisx.prod.on.blackberry [172.20.234.79]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m5LJAYg5014340 for ; Sat, 21 Jun 2008 19:10:34 GMT Received: from bda379.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda379.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id m5LJAWAf017376 for ; Sat, 21 Jun 2008 19:10:32 GMT X-rim-org-msg-ref-id: 807133087 Message-ID: <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> X-Priority: Normal References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> In-Reply-To: Sensitivity: Normal Importance: Normal To: SIP@ietf.org From: eburger@standardstrack.com Date: Sat, 21 Jun 2008 19:10:44 +0000 MIME-Version: 1.0 Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If people care, I'll work, but if nobody cares, I won't. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Cullen Jennings Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis Cc:sip@ietf.org, Jon Peterson Subject: Re: [Sip] INFO and what to do about it? Personally, I'd like to see some coherent discussion around it in a WG meeting then try to get to consensus on it. The totally number of people bothering to follow the conversation at this point is extremely low. On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: > I asked: > > > > We've been batting INFO around for many, many years now (like, 10 -- > > it predates the SIP working group). A couple of meetings back, we > > agreed that we would discuss use cases for INFO packages, and if we > > didn't find any consensus there, then we would go ahead and > publish an > > "INFO Considered Harmful" RFC. > > > > We tried having this discussion at the last IETF, but that just > didn't > > work out. > > > > Do we try again, or just give up and publish "INFO Considered > > Harmful"? > > > > Personally, I don't care anymore -- I just want to drive a stake > into > > the heart of this undead-thing, cut off its head, stuff the mouth > with > > holy wafers, and bury it at a crossroads somewhere. > > > > But this WG only slays by consensus, so what do you want? > > Several people (Jonathan, Mary, Christer, Paul) have responded to the > list with various things that added up to "Publish INFO packages AND > document the extension models for SIP". So far, nobody has suggested > otherwise. > > Does anybody want to do anything else? Speak now or forever visualize > whirled peas. > > -- > Dean > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 21 14:59:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFDE3A6914; Sat, 21 Jun 2008 14:59:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B413A6914 for ; Sat, 21 Jun 2008 14:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105 X-Spam-Level: X-Spam-Status: No, score=-105 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, J_CHICKENPOX_24=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 JS4AjG9SE-5W for ; Sat, 21 Jun 2008 14:59:19 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 20D7A3A687E for ; Sat, 21 Jun 2008 14:59:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-203.messagelabs.com!1214085548!23988745!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 28009 invoked from network); 21 Jun 2008 21:59:09 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 21 Jun 2008 21:59:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5LLxLMj001987 for ; Sat, 21 Jun 2008 17:59:21 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5LLxAS7001932 for ; Sat, 21 Jun 2008 17:59:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 21 Jun 2008 17:59:10 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjT0olx3dV+7tqnQcmUdah4kkI4/QAFu6Xw References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> From: "DOLLY, MARTIN C, ATTLABS" To: , Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Deployments and support of INFO is a reality, unlike some of the other (@#$ in SIP. So either you believe it is real, or you hide your head under the covers and pretend that there are no ghosts in the closet. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of eburger@standardstrack.com Sent: Saturday, June 21, 2008 3:11 PM To: SIP@ietf.org Subject: Re: [Sip] INFO and what to do about it? If people care, I'll work, but if nobody cares, I won't. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Cullen Jennings Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis Cc:sip@ietf.org, Jon Peterson Subject: Re: [Sip] INFO and what to do about it? Personally, I'd like to see some coherent discussion around it in a WG meeting then try to get to consensus on it. The totally number of people bothering to follow the conversation at this point is extremely low. On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: > I asked: > > > > We've been batting INFO around for many, many years now (like, 10 -- > > it predates the SIP working group). A couple of meetings back, we > > agreed that we would discuss use cases for INFO packages, and if we > > didn't find any consensus there, then we would go ahead and > publish an > > "INFO Considered Harmful" RFC. > > > > We tried having this discussion at the last IETF, but that just > didn't > > work out. > > > > Do we try again, or just give up and publish "INFO Considered > > Harmful"? > > > > Personally, I don't care anymore -- I just want to drive a stake > into > > the heart of this undead-thing, cut off its head, stuff the mouth > with > > holy wafers, and bury it at a crossroads somewhere. > > > > But this WG only slays by consensus, so what do you want? > > Several people (Jonathan, Mary, Christer, Paul) have responded to the > list with various things that added up to "Publish INFO packages AND > document the extension models for SIP". So far, nobody has suggested > otherwise. > > Does anybody want to do anything else? Speak now or forever visualize > whirled peas. > > -- > Dean > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 21 15:58:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B80F3A67C0; Sat, 21 Jun 2008 15:58:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55ECD3A67C0 for ; Sat, 21 Jun 2008 15:58:04 -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 qBeGiyeqQ8WH for ; Sat, 21 Jun 2008 15:58:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8115E3A6782 for ; Sat, 21 Jun 2008 15:58:03 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5LMvG3B003418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 21 Jun 2008 17:57:21 -0500 Message-ID: <485D873E.1090100@softarmor.com> Date: Sat, 21 Jun 2008 17:57:02 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Cullen Jennings References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> In-Reply-To: Cc: sip@ietf.org, Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > Personally, I'd like to see some coherent discussion around it in a WG > meeting then try to get to consensus on it. The totally number of people > bothering to follow the conversation at this point is extremely low. We tried to do that in the last meeting, but I seem to remember AD intervention taking our agenda time away. So it's do it on the list, or don't do it at all, as far as I can tell. To be honest, I'd say that we have the people who usually pat attention to SIP work paying attention now, and the people who usually don't aren't. -- dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 21 16:14:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D033A6910; Sat, 21 Jun 2008 16:14:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFBB3A6782 for ; Sat, 21 Jun 2008 16:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=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 qs0OdGPz3HF0 for ; Sat, 21 Jun 2008 16:14:50 -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 959F43A6910 for ; Sat, 21 Jun 2008 16:14:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,684,1204520400"; d="scan'208";a="11838377" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jun 2008 19:14:54 -0400 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 m5LNEsYq022533; Sat, 21 Jun 2008 19:14:54 -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.13.8) with ESMTP id m5LNEsX0006219; Sat, 21 Jun 2008 23:14:54 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.1830); Sat, 21 Jun 2008 19:14:54 -0400 Received: from [10.86.248.21] ([10.86.248.21]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jun 2008 19:14:53 -0400 Message-ID: <485D8B99.8070607@cisco.com> Date: Sat, 21 Jun 2008 19:15:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "DOLLY, MARTIN C, ATTLABS" References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> X-OriginalArrivalTime: 21 Jun 2008 23:14:53.0730 (UTC) FILETIME=[9CDD7820:01C8D3F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4086; t=1214090094; x=1214954094; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20 |To:=20=22DOLLY,=20MARTIN=20C,=20ATTLABS=22=20; bh=XVF78GjTBEF68F+K+Zo0qqeVlOV42OjCl+LcbMVNLAM=; b=CLHuX4eOi03URVUUqFsyAbFeXA/xPjxWWzQZxpxR5HcTaI1Cwm8wb56Y+t zQ7vZqgRYImCeQWn1zJbtpK1ieQAF9wZa5joleg3Lbpx5u5MRkKvHMrjLuP7 QvlPvMgOnm; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP@ietf.org Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm with Eric on this. I worked for awhile and the results seemed futile, so I'm not overly motivated to start again. But if there is some possibility of reaching a conclusion then I'll join in. Certainly I agree with Martin that there are lots of deployments and support for INFO in some form. But most of them are non-standard in one way or another. And I think this leaves us in a Catch-22 situation: - we can just bless unrestricted use of INFO. But that would serve no purpose, and wouldn't enhance interoperability. - or we can formalize rules for negotiating usages of INFO. That will provide the potential of enhanced interop. But then all the existing deployments will be incompatible with it. Paul DOLLY, MARTIN C, ATTLABS wrote: > Deployments and support of INFO is a reality, unlike some of the other > (@#$ in SIP. > > So either you believe it is real, or you hide your head under the covers > and pretend that there are no ghosts in the closet. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > eburger@standardstrack.com > Sent: Saturday, June 21, 2008 3:11 PM > To: SIP@ietf.org > Subject: Re: [Sip] INFO and what to do about it? > > If people care, I'll work, but if nobody cares, I won't. > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Cullen Jennings > > Date: Thu, 19 Jun 2008 17:49:00 > To:Dean Willis > Cc:sip@ietf.org, Jon Peterson > Subject: Re: [Sip] INFO and what to do about it? > > > > Personally, I'd like to see some coherent discussion around it in a WG > meeting then try to get to consensus on it. The totally number of > people bothering to follow the conversation at this point is extremely > low. > > On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: > >> I asked: >> >> >>> We've been batting INFO around for many, many years now (like, 10 -- >>> it predates the SIP working group). A couple of meetings back, we >>> agreed that we would discuss use cases for INFO packages, and if we >>> didn't find any consensus there, then we would go ahead and >> publish an >>> "INFO Considered Harmful" RFC. >>> >>> We tried having this discussion at the last IETF, but that just >> didn't >>> work out. >>> >>> Do we try again, or just give up and publish "INFO Considered >>> Harmful"? >>> >>> Personally, I don't care anymore -- I just want to drive a stake >> into >>> the heart of this undead-thing, cut off its head, stuff the mouth >> with >>> holy wafers, and bury it at a crossroads somewhere. >>> >>> But this WG only slays by consensus, so what do you want? >> Several people (Jonathan, Mary, Christer, Paul) have responded to the >> list with various things that added up to "Publish INFO packages AND >> document the extension models for SIP". So far, nobody has suggested >> otherwise. >> >> Does anybody want to do anything else? Speak now or forever visualize >> whirled peas. >> >> -- >> Dean >> >> > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.ryan@virtualbookkeeping.ca Sat Jun 21 23:03:03 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4817E3A68BB; Sat, 21 Jun 2008 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.162 X-Spam-Level: X-Spam-Status: No, score=-67.162 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 WFW9TWLKtrc5; Sat, 21 Jun 2008 23:03:02 -0700 (PDT) Received: from 201-212-49-149.cab.prima.net.ar (201-212-49-149.cab.prima.net.ar [201.212.49.149]) by core3.amsl.com (Postfix) with SMTP id 840F33A67F9; Sat, 21 Jun 2008 23:02:50 -0700 (PDT) X-Originating-IP: 208.168.160.227 by smtp.201.212.49.149; Sun, 22 Jun 2008 02:02:56 -0500 Message-ID: From: "Angela Morin" Reply-To: "Angela Morin" To: send-archive@ietf.org Subject: Affordable replica watches Date: Sun, 22 Jun 2008 02:02:56 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://ladovuxizyl44.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://ladovuxizyl44.blogspot.com/ From sip-bounces@ietf.org Sun Jun 22 21:27:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586773A689E; Sun, 22 Jun 2008 21:27:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3283A67A4 for ; Sun, 22 Jun 2008 21:16:18 -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 cLwprWYqzIrJ for ; Sun, 22 Jun 2008 21:16:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A994E3A63CB for ; Sun, 22 Jun 2008 21:16:14 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5N4G7u4021249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Jun 2008 23:16:08 -0500 Message-ID: <485F2382.20507@softarmor.com> Date: Sun, 22 Jun 2008 23:16:02 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.14pre (X11/20080305) MIME-Version: 1.0 To: Paul Kyzivat References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> In-Reply-To: <485D8B99.8070607@cisco.com> X-Enigmail-Version: 0.94.2.0 Cc: SIP@ietf.org Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > I'm with Eric on this. I worked for awhile and the results seemed > futile, so I'm not overly motivated to start again. But if there is some > possibility of reaching a conclusion then I'll join in. > > Certainly I agree with Martin that there are lots of deployments and > support for INFO in some form. But most of them are non-standard in one > way or another. And I think this leaves us in a Catch-22 situation: > > - we can just bless unrestricted use of INFO. But that would serve no > purpose, and wouldn't enhance interoperability. > > - or we can formalize rules for negotiating usages of INFO. That will > provide the potential of enhanced interop. But then all the existing > deployments will be incompatible with it. That sounds like a vote for defaulting and publishing Eric's original "Why you shouldn't use INFO for anything" draft. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 22 22:06:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4853A689B; Sun, 22 Jun 2008 22:06:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511ED3A680E for ; Sun, 22 Jun 2008 21:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BG5osAHt+Xn for ; Sun, 22 Jun 2008 21:54:31 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 233F53A67FE for ; Sun, 22 Jun 2008 21:54:28 -0700 (PDT) X-AuditID: cb5bdd57-a79c6bb000000d32-d6-485f2c7a0a55 Received: from blr-ec-aa01.wipro.com (unknown [10.201.18.41]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id 7B28F4E4003 for ; Mon, 23 Jun 2008 10:24:18 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 10:23:57 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 10:23:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 10:23:49 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjRl0/EYbU/+hKdT5qLjDHUex+HHQA/IZmAAJZOh+A= References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806182301.m5IN1Ofk022192@dragon.ariadne.com> From: To: , X-OriginalArrivalTime: 23 Jun 2008 04:53:57.0235 (UTC) FILETIME=[24F3BC30:01C8D4ED] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Probably everybody is busy. Any thoughts on this one. Best Regards, Ashish Saxena 877-5570 -----Original Message----- From: Ashish Saxena (WT01 - Telecom Equipment) Sent: Friday, June 20, 2008 10:56 AM To: christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 Hi Christer, From Section 4 (Client Behaviour) part of this draft, I understood that primary objective of this draft is to give indication to UAC to release resources, if any. I am little worried about extra messaging that will be seen because of 199 implementation. Can there be a way to tell proxies and UAS downstream that UAC has some resources reserved for this call and would be interested in receiving 199, if possible? IMO, UAC (mostly) is in better understanding of the resources that it has reserved for a particular call. So UAC can selectively add something in INVITE to tell downstream proxies/ UAS' about its interest. IMO, we can have a package for 199 and UAC can use "Supported" header to indicate entities downstream that it would be interested in getting 199 for this *particular* call. Implicitly it would mean that UAC has reserved some resources. I understand that we would changing the meaning of "Supported" header on per call basis :-(. Something else may be? Comments please. Best Regards, Ashish Saxena _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 22 23:56:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4028D3A6864; Sun, 22 Jun 2008 23:56:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1061B3A6816 for ; Sun, 22 Jun 2008 23:56:49 -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 ygx66VBigdKc for ; Sun, 22 Jun 2008 23:56:48 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 379933A6864 for ; Sun, 22 Jun 2008 23:56:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1214204207!9713005!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25654 invoked from network); 23 Jun 2008 06:56:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 23 Jun 2008 06:56:47 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m5N6ukX6012384 for ; Sun, 22 Jun 2008 23:56:46 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m5N6ukYF006901 for ; Mon, 23 Jun 2008 01:56:46 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m5N6ui9r006891 for ; Mon, 23 Jun 2008 01:56:45 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 14:56:43 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> In-Reply-To: <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjRl0/EYbU/+hKdT5qLjDHUex+HHQA/IZmAAJZOh+AABEogkA== References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> From: "Avasarala Ranjit-A20990" To: , X-CFilter-Loop: Reflected Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Can we use Require:199 to indicate to proxy to send 199? Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of ashish.hsaxena@wipro.com Sent: Monday, June 23, 2008 10:24 AM To: ashish.hsaxena@wipro.com; christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Probably everybody is busy. Any thoughts on this one. Best Regards, Ashish Saxena 877-5570 -----Original Message----- From: Ashish Saxena (WT01 - Telecom Equipment) Sent: Friday, June 20, 2008 10:56 AM To: christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 Hi Christer, From Section 4 (Client Behaviour) part of this draft, I understood that primary objective of this draft is to give indication to UAC to release resources, if any. I am little worried about extra messaging that will be seen because of 199 implementation. Can there be a way to tell proxies and UAS downstream that UAC has some resources reserved for this call and would be interested in receiving 199, if possible? IMO, UAC (mostly) is in better understanding of the resources that it has reserved for a particular call. So UAC can selectively add something in INVITE to tell downstream proxies/ UAS' about its interest. IMO, we can have a package for 199 and UAC can use "Supported" header to indicate entities downstream that it would be interested in getting 199 for this *particular* call. Implicitly it would mean that UAC has reserved some resources. I understand that we would changing the meaning of "Supported" header on per call basis :-(. Something else may be? Comments please. Best Regards, Ashish Saxena _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 01:59:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12AB3A695A; Mon, 23 Jun 2008 01:59:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14F43A6954 for ; Mon, 23 Jun 2008 01:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZAiX8L3AWv0 for ; Mon, 23 Jun 2008 01:59:22 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 1E3F33A6953 for ; Mon, 23 Jun 2008 01:59:22 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so7398301rvf.49 for ; Mon, 23 Jun 2008 01:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=kLzkSJ+7ARHCX96aEowvq3jPJoXodsg2CbzXeAzr0io=; b=JpsYVlxq6k4dISkru2pe1OpADbWYFwbgSFT7IwNX8EpkUHG7k6GpxkaDJkwTtLrjHO 4E2kNqOcvn/QX+UJGwrVtykd5KioqiIymhfrmWp/fV7+7yP+N7GCA3yjQ6ZnFcFk5Euu VjWElffw87N5gPTubAJBObB8frNUEH8a2JRLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=XUCrsMXwTmOXqQtxo8J3v2nIKI6H6xYrFyGQvcKeNaTkgUD7Hczd1eQ4KF4OoLPzYY YjgWaQUpBDYGyj6t+6OZqHz9SAAZxzXqitArfYhYNWL7JxdvlwXwJMaZxDl8AmUrGmKu KiFoqqW34fVECNY/IXqPridVWZmoRaanvViNE= Received: by 10.141.20.7 with SMTP id x7mr12357521rvi.61.1214211557434; Mon, 23 Jun 2008 01:59:17 -0700 (PDT) Received: by 10.114.166.16 with HTTP; Mon, 23 Jun 2008 01:59:17 -0700 (PDT) Message-ID: <458913680806230159g1be835caxd1e33b1011cc4b61@mail.gmail.com> Date: Mon, 23 Jun 2008 10:59:17 +0200 From: "Xavier Marjou" To: "DRAGE, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> X-Google-Sender-Auth: 7e828bc9572c3a67 Cc: sip@ietf.org, Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to > proceed with this draft? The document states: I agree this is a relevant use-case. If there's no other one, I think we don't have to torture ourselves with too many use-cases, as it would complicate the solution. By the way, I like short & simple drafts like this one ;-) > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for > proceeding with this work? The document currently lists: I would add one explicit requirement like: It MUST be possible for a UA to negotiate a keep-alive mecanism outside a SIP registration. Cheers, Xavier _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 02:00:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735813A695A; Mon, 23 Jun 2008 02:00:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA053A6953 for ; Mon, 23 Jun 2008 02:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdRn5HzW5QUZ for ; Mon, 23 Jun 2008 02:00:14 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 9E2523A698C for ; Mon, 23 Jun 2008 02:00:13 -0700 (PDT) X-AuditID: cb5bdd57-a99cabb000000d32-ce-485f66184a6c Received: from blr-ec-aa01.wipro.com (unknown [10.201.18.41]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id 805C64E4002 for ; Mon, 23 Jun 2008 14:30:08 +0530 (IST) Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 14:30:08 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 14:29:59 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 14:29:54 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE07043BD7@BLR-EC-MBX02.wipro.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjRl0/EYbU/+hKdT5qLjDHUex+HHQA/IZmAAJZOh+AABEogkAAD99tw References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> From: To: , X-OriginalArrivalTime: 23 Jun 2008 08:59:59.0275 (UTC) FILETIME=[83D047B0:01C8D50F] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks Ranjit, IMO it will be too restrictive on entities because we do not want to block the call if the entities do not support this package. Thanks. Best Regards, Ashish Saxena 877-5570 -----Original Message----- From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] Sent: Monday, June 23, 2008 12:27 PM To: Ashish Saxena (WT01 - Telecom Equipment); christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 Hi Can we use Require:199 to indicate to proxy to send 199? Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of ashish.hsaxena@wipro.com Sent: Monday, June 23, 2008 10:24 AM To: ashish.hsaxena@wipro.com; christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Probably everybody is busy. Any thoughts on this one. Best Regards, Ashish Saxena 877-5570 -----Original Message----- From: Ashish Saxena (WT01 - Telecom Equipment) Sent: Friday, June 20, 2008 10:56 AM To: christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 Hi Christer, From Section 4 (Client Behaviour) part of this draft, I understood that primary objective of this draft is to give indication to UAC to release resources, if any. I am little worried about extra messaging that will be seen because of 199 implementation. Can there be a way to tell proxies and UAS downstream that UAC has some resources reserved for this call and would be interested in receiving 199, if possible? IMO, UAC (mostly) is in better understanding of the resources that it has reserved for a particular call. So UAC can selectively add something in INVITE to tell downstream proxies/ UAS' about its interest. IMO, we can have a package for 199 and UAC can use "Supported" header to indicate entities downstream that it would be interested in getting 199 for this *particular* call. Implicitly it would mean that UAC has reserved some resources. I understand that we would changing the meaning of "Supported" header on per call basis :-(. Something else may be? Comments please. Best Regards, Ashish Saxena _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 02:20:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2933A695A; Mon, 23 Jun 2008 02:20:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4430E3A6965 for ; Mon, 23 Jun 2008 02:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q44Bk6UKWZ8B for ; Mon, 23 Jun 2008 02:20:20 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id D3E463A695A for ; Mon, 23 Jun 2008 02:20:20 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so7405465rvf.49 for ; Mon, 23 Jun 2008 02:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=KVDeX1R6FaYJbxyfhqv0OWDjNzDdnqpDgvdp2CDLiAA=; b=mOG6/grBQuWJGPiy1DxYF8X092lkx2tz0Q5UlEd8A24rE2eK0VZoBrrbY6b5wq8F1Q F5oqt4zWxlXuZcM4jFEE4uNjGg4N+j0/hCV3HQZhnZW4yFW7OTkxCpEdRFQppjOBmXaS M0frwLC6j6RrHPvctBPwtaJ+d36fL1LwQvZKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=mPqC3TyAQ32gslje2gleHIlXyu/qNkkq/Lw7Q/pwUhRIWtJBT6KC6+U28n2eNvALK+ WzGzmp+j3pL3BaSQVX9wR762fCfKN31uyo/QdIRZVD8resbkzr8ZnRswL7mJ3h8KwkVY npQFWA0W0kuPk9jP3eOqsu4JxgMfXCgATXhiI= Received: by 10.140.185.1 with SMTP id i1mr4433242rvf.102.1214212816953; Mon, 23 Jun 2008 02:20:16 -0700 (PDT) Received: by 10.114.166.16 with HTTP; Mon, 23 Jun 2008 02:20:16 -0700 (PDT) Message-ID: <458913680806230220n1116f816s47129eac7c9a46aa@mail.gmail.com> Date: Mon, 23 Jun 2008 11:20:16 +0200 From: "Xavier Marjou" To: "Dean Willis" In-Reply-To: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> MIME-Version: 1.0 Content-Disposition: inline References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> X-Google-Sender-Auth: 376cf52dce119a47 Cc: sip@ietf.org Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My opinion is that INFO is used a lot in SIP whatever people like it or not. It should thus be accepted, as well as corrected in its details if some minor aspects need to be enhanced. The work done in draft-kaplan-sip-info-events goes this direction and should thus become a WG item. Cheers, Xavier On Wed, Jun 18, 2008 at 12:27 AM, Dean Willis wrote: > > We've been batting INFO around for many, many years now (like, 10 -- > it predates the SIP working group). A couple of meetings back, we > agreed that we would discuss use cases for INFO packages, and if we > didn't find any consensus there, then we would go ahead and publish an > "INFO Considered Harmful" RFC. > > We tried having this discussion at the last IETF, but that just didn't > work out. > > Do we try again, or just give up and publish "INFO Considered Harmful"? > > Personally, I don't care anymore -- I just want to drive a stake into > the heart of this undead-thing, cut off its head, stuff the mouth with > holy wafers, and bury it at a crossroads somewhere. > > But this WG only slays by consensus, so what do you want? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 05:33:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0323A693B; Mon, 23 Jun 2008 05:33:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97ABF3A67B4 for ; Mon, 23 Jun 2008 05:33:14 -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 veEQtXteDx7n for ; Mon, 23 Jun 2008 05:33:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7C7823A68EF for ; Mon, 23 Jun 2008 05:33:13 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2FCB620119; Mon, 23 Jun 2008 14:33:12 +0200 (CEST) X-AuditID: c1b4fb3e-ab993bb000004ec0-e3-485f98080413 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1339720100; Mon, 23 Jun 2008 14:33:12 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 14:33:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 14:33:27 +0200 Message-ID: In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjRl0/EYbU/+hKdT5qLjDHUex+HHQA/IZmAAJZOh+AABEogkAALu7fA References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> From: "Christer Holmberg" To: "Avasarala Ranjit-A20990" , X-OriginalArrivalTime: 23 Jun 2008 12:33:37.0418 (UTC) FILETIME=[5C05AEA0:01C8D52D] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >Can we use Require:199 to indicate to proxy to send 199? No. The Require header is only applicaple to a UAS. You can use Proxy-Require for proxies, but the problem is that you would require this from EVERY proxy in the path. Regards, Christer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of ashish.hsaxena@wipro.com Sent: Monday, June 23, 2008 10:24 AM To: ashish.hsaxena@wipro.com; christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Probably everybody is busy. Any thoughts on this one. Best Regards, Ashish Saxena 877-5570 -----Original Message----- From: Ashish Saxena (WT01 - Telecom Equipment) Sent: Friday, June 20, 2008 10:56 AM To: christer.holmberg@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 Hi Christer, From Section 4 (Client Behaviour) part of this draft, I understood that primary objective of this draft is to give indication to UAC to release resources, if any. I am little worried about extra messaging that will be seen because of 199 implementation. Can there be a way to tell proxies and UAS downstream that UAC has some resources reserved for this call and would be interested in receiving 199, if possible? IMO, UAC (mostly) is in better understanding of the resources that it has reserved for a particular call. So UAC can selectively add something in INVITE to tell downstream proxies/ UAS' about its interest. IMO, we can have a package for 199 and UAC can use "Supported" header to indicate entities downstream that it would be interested in getting 199 for this *particular* call. Implicitly it would mean that UAC has reserved some resources. I understand that we would changing the meaning of "Supported" header on per call basis :-(. Something else may be? Comments please. Best Regards, Ashish Saxena _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 05:40:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39C93A69B3; Mon, 23 Jun 2008 05:40:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A163A68EF for ; Mon, 23 Jun 2008 05:40:05 -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 fjzsSE0DvxpA for ; Mon, 23 Jun 2008 05:40:04 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 540F53A6975 for ; Mon, 23 Jun 2008 05:40:04 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 39B8020FB6; Mon, 23 Jun 2008 14:40:00 +0200 (CEST) X-AuditID: c1b4fb3e-ab993bb000004ec0-28-485f99a03303 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 128512033B; Mon, 23 Jun 2008 14:40:00 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 14:40:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 14:39:36 +0200 Message-ID: In-Reply-To: <01949ABCDD38EF4A95B8C347C399D1CE06FFABC7@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjRl0/EYbU/+hKdT5qLjDHUex+HHQA/IZmAAKZlLVA= References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE06FFABC7@BLR-EC-MBX02.wipro.com> From: "Christer Holmberg" To: X-OriginalArrivalTime: 23 Jun 2008 12:40:25.0140 (UTC) FILETIME=[4F0B1F40:01C8D52E] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >From Section 4 (Client Behaviour) part of this draft, I understood that primary objective of this draft is to give >indication to UAC to release resources, if any. I am little worried about extra messaging that will be seen because of >199 implementation. Can there be a way to tell proxies and UAS downstream that UAC has some resources reserved for this >call and would be interested in receiving 199, if possible? > >IMO, UAC (mostly) is in better understanding of the resources that it has reserved for a particular call. So UAC can >selectively add something in INVITE to tell downstream proxies/ UAS' about its interest. > >IMO, we can have a package for 199 and UAC can use "Supported" header to indicate entities downstream that it would be >interested in getting 199 for this *particular* call. Implicitly it would mean that UAC has reserved some resources. I >understand that we would changing the meaning of "Supported" header on per call basis :-(. Something else may be? I am not sure you would "break" anything by using Supported "per call". As far as I know, it is nowhere said that a UAC must included the same option-tags in the Supported header for every call it makes... It is true that the primary objective is to give the indication to the UAC, but in some environments there could also be intermediates (P-CSCF controlling PCC in IMS for example) that are interested in this indication. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 05:57:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7060A3A6975; Mon, 23 Jun 2008 05:57:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CE73A6975 for ; Mon, 23 Jun 2008 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 wOQYBXQLbJso for ; Mon, 23 Jun 2008 05:57:08 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D64463A68FD for ; Mon, 23 Jun 2008 05:57:07 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5NCutM3013634; Mon, 23 Jun 2008 15:57:00 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 15:56:48 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 15:56:47 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 15:56:33 +0300 Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5NCuWog019222; Mon, 23 Jun 2008 15:56:32 +0300 From: Aki Niemi To: "ext DRAGE, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> Organization: Nokia Devices R&D Date: Mon, 23 Jun 2008 15:56:55 +0300 Message-Id: <1214225815.9973.374.camel@little.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-OriginalArrivalTime: 23 Jun 2008 12:56:33.0626 (UTC) FILETIME=[904E5BA0:01C8D530] X-Nokia-AV: Clean Cc: sip@ietf.org, Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org to, 2008-06-19 kello 11:30 +0200, ext DRAGE, Keith (Keith) kirjoitti: > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to > proceed with this draft? The document states: > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > defines two keep-alive techniques. Even though the keep-alive > techniques are separated from the Outbound mechanism > [I-D.ietf-sip-outbound], it is currently not possible to indicate > support of the keep-alive techniques without also indicating support > for the Outbound mechanism. > > The Outbound mechanism is enabled during the UA registration phase. > However, there are use-cases where the UA does not register itself, > but still needs to be able to make calls and maintain NAT bindings > open during the duration of that call. A typical example is > emergency calls. There are also cases where entities do not support > the Outbound mechanism, but still want to be able to indicate support > and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. > > At first sight this is not the most inspiring declaration of the need > for the document. Please respond indicating whether you consider this a > useful draft, and propose text that you think would be useful in this > section. Conversely, if you think this draft is not useful and the WG > has other more important things to work on first, please also respond. In theory, there is a small, but valid, reason for the draft to exists. The draft could serve as a way to deploy outbound-aware proxies in front of outbound-unaware registrars, using UDP transport. However, arguably UDP is deployed and works through NAT today, which is why I find it unlikely that anyone would deploy outbound keepalives in this way. > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for > proceeding with this work? The document currently lists: > > REQ 1: It MUST be possible for a UA to indicate support of the keep- > alive techniques defined [I-D.ietf-sip-outbound] if the UA supports > only the keep-alive part of [I-D.ietf-sip-outbound]. > > REQ 2: It MUST be possible for an edge proxy to indicate support of > the keep-alive techniques defined [I-D.ietf-sip-outbound] if the edge > poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. > > It would be desirable to agree these at the outset, and not revisit them > if we continue with the work. So if you require clarification, > modification, or addition to these two requirements, then please also > response with your questions and proposals. These requirements would make sense, but iff there was an actual need to have this ability in the first place, as I described above. I don't think such a need exists in practice. (Note, this upgrade path only exists for UDP; for TCP registrars need to be outbound-aware.) Cheers, Aki _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 06:14:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3863A69CA; Mon, 23 Jun 2008 06:14:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E6F3A69CA for ; Mon, 23 Jun 2008 06:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 tIU5zDMwy+Jx for ; Mon, 23 Jun 2008 06:14:53 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 91A663A69C9 for ; Mon, 23 Jun 2008 06:14:52 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5NDEN9b015638 for ; Mon, 23 Jun 2008 16:14:50 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 16:14:42 +0300 Received: from esdhcp04089.research.nokia.com ([172.21.40.89]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 16:14:42 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: sip@ietf.org Date: Mon, 23 Jun 2008 16:15:00 +0300 User-Agent: KMail/1.9.9 References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806231615.01075.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 Jun 2008 13:14:42.0760 (UTC) FILETIME=[197B0480:01C8D533] X-Nokia-AV: Clean Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Le Thursday 19 June 2008 12:30:30 ext DRAGE, Keith (Keith), vous avez =E9cr= it=A0: > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to > proceed with this draft? The document states: (...) > The Outbound mechanism is enabled during the UA registration phase. > However, there are use-cases where the UA does not register itself, > but still needs to be able to make calls and maintain NAT bindings > open during the duration of that call. > A typical example is emergency calls. I don't get this one. You don't need to send keep-alive packets to make an = outbound call (be it urgent or not). > There are also cases where entities do not support = > the Outbound mechanism, but still want to be able to indicate support > and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. I don't get this either. If you don't support Outbound, why not use plain S= IP = OPTIONS, which works _today_? -- = R=E9mi Denis-Courmont _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 06:21:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FB83A6979; Mon, 23 Jun 2008 06:21:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECBA43A6904 for ; Mon, 23 Jun 2008 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 PEERtkwLcSEy for ; Mon, 23 Jun 2008 06:20:59 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DB61E3A6868 for ; Mon, 23 Jun 2008 06:20:58 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 72CCD207F3; Mon, 23 Jun 2008 15:20:57 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-e4-485fa3399d6a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4DC64207D5; Mon, 23 Jun 2008 15:20:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 15:21:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 15:21:16 +0200 Message-ID: In-Reply-To: <200806231615.01075.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep thread-index: AcjVMzkbBuWUsAnkSlG1+diqUaay5AAACOYQ References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <200806231615.01075.remi.denis-courmont@nokia.com> From: "Christer Holmberg" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , X-OriginalArrivalTime: 23 Jun 2008 13:21:17.0421 (UTC) FILETIME=[04B781D0:01C8D534] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >>QUESTION 1 TO SIP WG: Are the use cases sufficiently important to >>proceed with this draft? The document states: >>(...) >> The Outbound mechanism is enabled during the UA registration phase. >> However, there are use-cases where the UA does not register itself, >> but still needs to be able to make calls and maintain NAT bindings >> open during the duration of that call. >> >> A typical example is emergency calls. > >I don't get this one. You don't need to send keep-alive packets to make an outbound call (be it urgent or not). I am not sure that is what I am saying. I am saying that you in these use-cases can't use outbound, with keep-alives, even if you support it. >> There are also cases where entities do not support >> the Outbound mechanism, but still want to be able to indicate support >> and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. > >I don't get this either. If you don't support Outbound, why not use plain SIP OPTIONS, which works _today_? An edge proxy does not know whether the UA is going to send OPTIONS, so it may use the short registration rerefresh mechanism. One of the purposes of the draft is for UAs to tell the edge proxy that it is willing to send keep-alives, so that the edge proxy doesn't need to use registration type of mechanisms. In addition, if OPTIONS is sent in-dialog it will be forwarded by the edge proxy towards the remote user, which is not needed. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c56c@c56c.com Mon Jun 23 06:55:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF903A67DA; Mon, 23 Jun 2008 06:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.298 X-Spam-Level: X-Spam-Status: No, score=-79.298 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, 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 oYtljYjQ1+M1; Mon, 23 Jun 2008 06:55:18 -0700 (PDT) Received: from pc-145-189-104-200.cm.vtr.net (pc-145-189-104-200.cm.vtr.net [200.104.189.145]) by core3.amsl.com (Postfix) with SMTP id B2E0E3A67FA; Mon, 23 Jun 2008 06:55:06 -0700 (PDT) X-Originating-IP: 177.9.88.176 by smtp.200.104.189.145; Mon, 23 Jun 2008 09:55:08 -0500 Message-ID: From: "Alvaro Feliciano" Reply-To: "Alvaro Feliciano" To: send-archive@ietf.org Subject: Impressive Glashutte timepieces Date: Mon, 23 Jun 2008 09:55:08 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://xusobacimoh00.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://xusobacimoh00.blogspot.com/ From ca6f18b4@glovebank.com Mon Jun 23 07:26:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E053A69DC; Mon, 23 Jun 2008 07:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.673 X-Spam-Level: X-Spam-Status: No, score=-54.673 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 tSO7PtTJ5LSM; Mon, 23 Jun 2008 07:26:27 -0700 (PDT) Received: from 79-126-20-229.dynamic.mts-nn.ru (79-126-20-229.dynamic.mts-nn.ru [79.126.20.229]) by core3.amsl.com (Postfix) with SMTP id A96723A69C0; Mon, 23 Jun 2008 07:26:17 -0700 (PDT) X-Originating-IP: 168.19.4.96 by smtp.79.126.20.229; Mon, 23 Jun 2008 10:26:19 -0500 Message-ID: From: "Georgina Noel" Reply-To: "Georgina Noel" To: send-archive@ietf.org Subject: Tag Heuer replicas better than originals Date: Mon, 23 Jun 2008 10:26:19 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://lokabyzinob08.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://lokabyzinob08.blogspot.com/ From sip-bounces@ietf.org Mon Jun 23 07:41:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4853A698A; Mon, 23 Jun 2008 07:41:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693A83A698A for ; Mon, 23 Jun 2008 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 bUKQq4-so7XY for ; Mon, 23 Jun 2008 07:41:10 -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 CA33C3A68FD for ; Mon, 23 Jun 2008 07:41:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,690,1204531200"; d="scan'208";a="43333286" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2008 07:41:11 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5NEfBJO025617; Mon, 23 Jun 2008 07:41:11 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m5NEfAUV022850; Mon, 23 Jun 2008 14:41:11 GMT From: Cullen Jennings To: Dean Willis In-Reply-To: <485D873E.1090100@softarmor.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <485D873E.1090100@softarmor.com> Message-Id: <5C339046-7A17-414A-99A6-7AF3FDAB8B94@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 23 Jun 2008 07:41:00 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1197; t=1214232071; x=1215096071; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=Th12UN8sodMsc+8ddXLgQr/i1F2dOvPDWH9RFJ7OEyI=; b=urIiYOqaUPnVK+Mo2vvSONq8TC2fLADl+Yxsf7tlImOt8DSTygfiqRo5TH N/plTGTI3j1JQ2ZDjDWwFgsi6HePSUVj0we9JBKT7xKevLg2HF2mubwfBCF6 2PXRIympTAR/jX4OcQugPiwj1C+iiDAtHe2aoEi4G2bmXtBordY3M=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 21, 2008, at 3:57 PM, Dean Willis wrote: > Cullen Jennings wrote: >> Personally, I'd like to see some coherent discussion around it in a >> WG meeting then try to get to consensus on it. The totally number >> of people bothering to follow the conversation at this point is >> extremely low. > > We tried to do that in the last meeting, but I seem to remember AD > intervention taking our agenda time away. Dean, a room full a 100+ people in the sipping meeting took a hum and decided much to my surprise to not add an evening meeting. I realize we wish there was more time but there is not and it is unlikely there will be more time in Dublin. The best we can do is carefully pick what topics we do choose to use the time we do have on. I will note there was not enough interest in this to get an interim meeting to happen. I would not exactly describe this as AD intervention. > > > So it's do it on the list, or don't do it at all, as far as I can > tell. > > To be honest, I'd say that we have the people who usually pat > attention to SIP work paying attention now, and the people who > usually don't aren't. > > -- > dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 08:44:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB713A69B2; Mon, 23 Jun 2008 08:44:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA813A69B2 for ; Mon, 23 Jun 2008 08:44:51 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ1Td8MSnq3b for ; Mon, 23 Jun 2008 08:44:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 29E753A698A for ; Mon, 23 Jun 2008 08:44:50 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 23 Jun 2008 11:44:02 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 23 Jun 2008 11:44:02 -0400 From: Hadriel Kaplan To: Cullen Jennings , Dean Willis Date: Mon, 23 Jun 2008 11:44:01 -0400 Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjVPxmo8SfK98d0TiGtHmkd8JdIbQAB8tKA Message-ID: References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <485D873E.1090100@softarmor.com> <5C339046-7A17-414A-99A6-7AF3FDAB8B94@cisco.com> In-Reply-To: <5C339046-7A17-414A-99A6-7AF3FDAB8B94@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Monday, June 23, 2008 10:41 AM > > Dean, a room full a 100+ people in the sipping meeting took a hum and > decided much to my surprise to not add an evening meeting. I wasn't there, but my impression from talking with others was that there was concern over having a late-night meeting given some WG's were going to be meeting early the following morning. > I realize > we wish there was more time but there is not and it is unlikely there > will be more time in Dublin. The best we can do is carefully pick what > topics we do choose to use the time we do have on. I will note there > was not enough interest in this to get an interim meeting to happen. > I would not exactly describe this as AD intervention. I doubt any single topic in the SIP/SIPPING/etc. working groups would by itself be sufficient to warrant an interim meeting, so that's hardly a fair litmus test. Personally I'd prefer an interim meeting specifically to get most of the current mostly-done WG items out of the way and off of the next full-meeting agenda, and just try to get consensus hums for the outcome of the interim at the full-meeting since they're not likely to be contentious; but my guess is you can't do that at an interim? -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 08:45:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E77C3A69B2; Mon, 23 Jun 2008 08:45:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96F43A69DC for ; Mon, 23 Jun 2008 08:45:31 -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 UpaaX62AyoQs for ; Mon, 23 Jun 2008 08:45:30 -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 38CF03A69E9 for ; Mon, 23 Jun 2008 08:45:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,690,1204520400"; d="scan'208";a="11931882" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Jun 2008 11:45:29 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5NFjTMA010158; Mon, 23 Jun 2008 11:45:29 -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.13.8) with ESMTP id m5NFjTPC006433; Mon, 23 Jun 2008 15:45:29 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.1830); Mon, 23 Jun 2008 11:45:29 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 11:45:29 -0400 Message-ID: <485FC547.1040904@cisco.com> Date: Mon, 23 Jun 2008 11:46:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ashish.hsaxena@wipro.com References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> In-Reply-To: <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> X-OriginalArrivalTime: 23 Jun 2008 15:45:29.0337 (UTC) FILETIME=[29A91E90:01C8D548] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2392; t=1214235929; x=1215099929; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20ashish.hsaxena@wipro.com; bh=Im1Ygj/EqvKC6eNpYnOrwU98oHjiMC8DImGW9UwHZ5I=; b=F9wHgw/2RjWz1WMW7PK/yj9BuESu4avDuMRAyuI+YHUKgBzVsP5egcbGdI L27YyQ3IGOPQS3iGx32vbPFNtNh+VxgAjqq1GeLvExEblDxDx4oWzqsSHIg6 uJTXI+23if; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, christer.holmberg@ericsson.com Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ashish.hsaxena@wipro.com wrote: > Probably everybody is busy. Any thoughts on this one. If the call has been forked, and provisional responses with multiple to-tags have been sent back to the UAC, then it is certain that the UAC has *some* resources tied up with each early dialog. The 199 will allow some of that to be released. Are you suggesting that the UAC indicate if it considers those resources to be sufficient to justify processing an extra message? Or maybe you are just concerned with the likelihood that the UAC doesn't support 199, so that the message will just be ignored in any case? I could go either way on this one. Paul > Best Regards, > Ashish Saxena > 877-5570 > > -----Original Message----- > From: Ashish Saxena (WT01 - Telecom Equipment) > Sent: Friday, June 20, 2008 10:56 AM > To: christer.holmberg@ericsson.com > Cc: sip@ietf.org > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > Hi Christer, > From Section 4 (Client Behaviour) part of this draft, I > understood that primary objective of this draft is to give indication to > UAC to release resources, if any. I am little worried about extra > messaging that will be seen because of 199 implementation. Can there be > a way to tell proxies and UAS downstream that UAC has some resources > reserved for this call and would be interested in receiving 199, if > possible? > > IMO, UAC (mostly) is in better understanding of the resources that it > has reserved for a particular call. So UAC can selectively add something > in INVITE to tell downstream proxies/ UAS' about its interest. > > IMO, we can have a package for 199 and UAC can use "Supported" header to > indicate entities downstream that it would be interested in getting 199 > for this *particular* call. Implicitly it would mean that UAC has > reserved some resources. I understand that we would changing the meaning > of "Supported" header on per call basis :-(. Something else may be? > > Comments please. > > Best Regards, > Ashish Saxena > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 08:49:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078943A69BB; Mon, 23 Jun 2008 08:49:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B323A6910 for ; Mon, 23 Jun 2008 08:49:31 -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 w6uCANdHpzSB for ; Mon, 23 Jun 2008 08:49:27 -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 790633A67CF for ; Mon, 23 Jun 2008 08:49:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,690,1204520400"; d="scan'208";a="11941098" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jun 2008 11:49:27 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5NFnRaU012620; Mon, 23 Jun 2008 11:49:27 -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.13.8) with ESMTP id m5NFnRTQ008200; Mon, 23 Jun 2008 15:49:27 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.1830); Mon, 23 Jun 2008 11:49:27 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 11:49:26 -0400 Message-ID: <485FC635.7070309@cisco.com> Date: Mon, 23 Jun 2008 11:50:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> In-Reply-To: X-OriginalArrivalTime: 23 Jun 2008 15:49:26.0615 (UTC) FILETIME=[B716DE70:01C8D548] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3213; t=1214236167; x=1215100167; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Christer=20Holmberg=20; bh=eHis7RxluaArv+qGY5phFWmx1JW7VNvRbMQHUjpwNQU=; b=wHVxx+tzawqc/CHSPll//bAoH91Ruc90cfs7l6W6QicZDjCsNKh9vpeu9c 0Kt8LQ+CV/ztImvhR7XTlNzTTdt632dBf2QU5xE1lWont+UTinbQPHt4/6Ik SJ2AnDGPwt; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Right - Require is inappropriate. Supported is certainly possible. I think it would simply mean that the UAC understands the significance of 199 and so is prepared to take advantage of it if received. I see no reason why you would change it on a call by call basis. The resources aren't committed at the time of the INVITE - rather at the time the provisional response is received, so doing on a per-call basis wouldn't make much sense. Paul Christer Holmberg wrote: > Hi, > >> Can we use Require:199 to indicate to proxy to send 199? > > No. The Require header is only applicaple to a UAS. > > You can use Proxy-Require for proxies, but the problem is that you would > require this from EVERY proxy in the path. > > Regards, > > Christer > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > ashish.hsaxena@wipro.com > Sent: Monday, June 23, 2008 10:24 AM > To: ashish.hsaxena@wipro.com; christer.holmberg@ericsson.com > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > > Probably everybody is busy. Any thoughts on this one. > > > Best Regards, > Ashish Saxena > 877-5570 > > -----Original Message----- > From: Ashish Saxena (WT01 - Telecom Equipment) > Sent: Friday, June 20, 2008 10:56 AM > To: christer.holmberg@ericsson.com > Cc: sip@ietf.org > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > Hi Christer, > From Section 4 (Client Behaviour) part of this draft, I > understood that primary objective of this draft is to give indication to > UAC to release resources, if any. I am little worried about extra > messaging that will be seen because of 199 implementation. Can there be > a way to tell proxies and UAS downstream that UAC has some resources > reserved for this call and would be interested in receiving 199, if > possible? > > IMO, UAC (mostly) is in better understanding of the resources that it > has reserved for a particular call. So UAC can selectively add something > in INVITE to tell downstream proxies/ UAS' about its interest. > > IMO, we can have a package for 199 and UAC can use "Supported" header to > indicate entities downstream that it would be interested in getting 199 > for this *particular* call. Implicitly it would mean that UAC has > reserved some resources. I understand that we would changing the meaning > of "Supported" header on per call basis :-(. Something else may be? > > Comments please. > > Best Regards, > Ashish Saxena > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 09:02:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8ED93A6A31; Mon, 23 Jun 2008 09:02:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000523A6A1A for ; Mon, 23 Jun 2008 09:02:18 -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 7cBKAzrpGO18 for ; Mon, 23 Jun 2008 09:02:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 024A93A69D9 for ; Mon, 23 Jun 2008 09:02:17 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5NG29FB008617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2008 11:02:10 -0500 Message-Id: <2E1197CD-B9D2-4061-85B8-88B8CB950698@softarmor.com> From: Dean Willis To: Cullen Jennings In-Reply-To: <5C339046-7A17-414A-99A6-7AF3FDAB8B94@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 11:02:03 -0500 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <485D873E.1090100@softarmor.com> <5C339046-7A17-414A-99A6-7AF3FDAB8B94@cisco.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org, Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 23, 2008, at 9:41 AM, Cullen Jennings wrote: > > On Jun 21, 2008, at 3:57 PM, Dean Willis wrote: > >> Cullen Jennings wrote: >>> Personally, I'd like to see some coherent discussion around it in >>> a WG meeting then try to get to consensus on it. The totally >>> number of people bothering to follow the conversation at this >>> point is extremely low. >> >> We tried to do that in the last meeting, but I seem to remember AD >> intervention taking our agenda time away. > > Dean, a room full a 100+ people in the sipping meeting took a hum > and decided much to my surprise to not add an evening meeting. I > realize we wish there was more time but there is not and it is > unlikely there will be more time in Dublin. The best we can do is > carefully pick what topics we do choose to use the time we do have > on. I will note there was not enough interest in this to get an > interim meeting to happen. I would not exactly describe this as AD > intervention. No, I was talking about the 4 hour agenda request that got cut to 2 hours along with the instruction to "focus only on chartered work". INFO is interesting, but it's not on our milestone list. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 09:18:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B9F3A69FA; Mon, 23 Jun 2008 09:18:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BF73A69FF for ; Mon, 23 Jun 2008 09:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmeyzBQs9VG7 for ; Mon, 23 Jun 2008 09:18:46 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7891A3A69FA for ; Mon, 23 Jun 2008 09:18:46 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5NGH9m08155; Mon, 23 Jun 2008 16:17:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 11:16:02 -0500 Message-ID: In-Reply-To: <2E1197CD-B9D2-4061-85B8-88B8CB950698@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjVSpTZk37nhPymR/C/uEG/pi2nMwAAGaIg References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <485D873E.1090100@softarmor.com> <5C339046-7A17-414A-99A6-7AF3FDAB8B94@cisco.com> <2E1197CD-B9D2-4061-85B8-88B8CB950698@softarmor.com> From: "Mary Barnes" To: "Dean Willis" , "Cullen Jennings" Cc: sip@ietf.org, Jon Peterson Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org FYI, we actually had the meeting targetted as a SIPPING WG adhoc: https://www3.ietf.org/proceedings/08mar/slides/sipping-0/sipping-0_files /frame.htm (Chart 16) Personally, I was in favor of an interim to discuss that topic as well as other critical WG items. In the past, interims have really helped in progressing key WG items. As I understand, one roadblock for some folks is travel approval (my proposal had been to hold the interim in Dallas before or after the GEOPRIV interim). It might be useful to plan earlier for interims to allow folks to consider this in travel budgets sooner (i.e., some of us do these quarterly and having it in the plan earlier allows it to be approved with all other travel and can be considered/prioritized with other travel requests, whereas if it comes later, it requires special approval and is often challenged given today's business environment). I will note that Keith did try to schedule a teleconference on this topic, however, the quorom of key people were not available. However, in general, I do think regular teleconferences for the WGs with authors to progress key topics would be useful. Recognizing that you can't get everyone all the time, rotating time slots might help. I don't think it's apathy or lack of interest in topics as much as many folks I've communicated with have increased day job workloads, so the amount of time focused on IETF has dramatically increased for some folks. Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, June 23, 2008 11:02 AM To: Cullen Jennings Cc: sip@ietf.org; Jon Peterson Subject: Re: [Sip] INFO and what to do about it? On Jun 23, 2008, at 9:41 AM, Cullen Jennings wrote: > > On Jun 21, 2008, at 3:57 PM, Dean Willis wrote: > >> Cullen Jennings wrote: >>> Personally, I'd like to see some coherent discussion around it in a >>> WG meeting then try to get to consensus on it. The totally number of >>> people bothering to follow the conversation at this point is >>> extremely low. >> >> We tried to do that in the last meeting, but I seem to remember AD >> intervention taking our agenda time away. > > Dean, a room full a 100+ people in the sipping meeting took a hum and > decided much to my surprise to not add an evening meeting. I realize > we wish there was more time but there is not and it is unlikely there > will be more time in Dublin. The best we can do is carefully pick what > topics we do choose to use the time we do have on. I will note there > was not enough interest in this to get an > interim meeting to happen. I would not exactly describe this as AD > intervention. No, I was talking about the 4 hour agenda request that got cut to 2 hours along with the instruction to "focus only on chartered work". INFO is interesting, but it's not on our milestone list. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 09:20:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE823A6A36; Mon, 23 Jun 2008 09:20:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240B03A6A47 for ; Mon, 23 Jun 2008 09:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSQtPU41sy9f for ; Mon, 23 Jun 2008 09:20:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 473633A6A31 for ; Mon, 23 Jun 2008 09:20:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 23 Jun 2008 12:20:06 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 23 Jun 2008 12:20:06 -0400 From: Hadriel Kaplan To: Dean Willis Date: Mon, 23 Jun 2008 12:20:04 -0400 Thread-Index: AcjVTP6kGKI5M6CLTButn/b1hpoBwA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: [Sip] (no subject) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Dean Willis > > The problem that I'm trying to solve is making the task space > manageable. > The first thing is to distribute the chair load. Obviously splitting/spawning WG's will do that, but I thought there was an AD resource contention issue - if we had more WG meeting slots then neither of our AD's could be in some meeting or other. Is that not one of the issues? It was the response I got when I and others suggested SIP Security topics (Identity/Privacy/SIPS/Certs/etc.) should be split into a separate WG a while back. There was also some concern over not having any more RAI time slots anyway, but I think that's a red herring and overlapping some RAI WG meeting times is reasonable for certain topics. > I think developing a SIP extension should be a Big Thing. If it's > important enough to develop a SIP extension for, it is probably > important enough to charter a working group to develop that extension. > It's a Really Bad Idea to have a standing working group that sits > around and develops SIP extensions. All that gets us is a whole lot of > extensions. It doesn't get us any closer to a draft standard. I agree with you in principle, but I doubt it's possible in practice. There's some fine line there, because if you don't address an issue/need multiple people have, then they just go solve it in a proprietary fashion independently and interop still sucks. One problem is we don't have a single cohesive "group" view and use of SIP, so we're left with the shotgun extensions approach, seeing which ones will stick. I can't recall another successful protocol this complicated that didn't have one or two dominant vendors, which is a huge disadvantage in some ways. It's both a blessing and a curse. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:02:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13F23A6838; Mon, 23 Jun 2008 10:02:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D643A6838 for ; Mon, 23 Jun 2008 10:02:45 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfzWJkblzeO3 for ; Mon, 23 Jun 2008 10:02:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 326513A63D2 for ; Mon, 23 Jun 2008 10:02:43 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5NH2XAk008934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2008 12:02:35 -0500 Message-Id: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 12:02:28 -0500 References: X-Mailer: Apple Mail (2.924) Cc: "sip@ietf.org" Subject: Re: [Sip] (no subject) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 23, 2008, at 11:20 AM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Dean Willis >> >> The problem that I'm trying to solve is making the task space >> manageable. >> The first thing is to distribute the chair load. > > Obviously splitting/spawning WG's will do that, but I thought there > was an AD resource contention issue - if we had more WG meeting > slots then neither of our AD's could be in some meeting or other. > Is that not one of the issues? It was the response I got when I and > others suggested SIP Security topics (Identity/Privacy/SIPS/Certs/ > etc.) should be split into a separate WG a while back. > There was also some concern over not having any more RAI time slots > anyway, but I think that's a red herring and overlapping some RAI WG > meeting times is reasonable for certain topics. > We can have four new working groups that meet for an hour each, or we can have one existing WG that meets for four hours. Same meeting time, same AD conflicts, but four times as many chairs to do the management work. What we can't have is four new working groups that meet for four hours each. This means scope creep (and scope inflation) must be rigorously controlled. Hence, each charter must be tightly constrained, and each WG narrowly focused. The fact is that our working groups are so big now that the chairs can't devote enough time to thoroughly manage individual subjects. So the chairs aren't offloading enough of the work from the ADs. Doubling the number of chairs might not cut the ADs load in half, but it could certainly reduce it, although this is true if and only if the focus of each WG (and chair) is precise. I can't stay on top of the status of 38 work items that go on for many years. I could probably manage four work items that last for no more than two years. > >> I think developing a SIP extension should be a Big Thing. If it's >> important enough to develop a SIP extension for, it is probably >> important enough to charter a working group to develop that >> extension. >> It's a Really Bad Idea to have a standing working group that sits >> around and develops SIP extensions. All that gets us is a whole lot >> of >> extensions. It doesn't get us any closer to a draft standard. > > I agree with you in principle, but I doubt it's possible in > practice. There's some fine line there, because if you don't > address an issue/need multiple people have, then they just go solve > it in a proprietary fashion independently and interop still sucks. > One problem is we don't have a single cohesive "group" view and use > of SIP, so we're left with the shotgun extensions approach, seeing > which ones will stick. I can't recall another successful protocol > this complicated that didn't have one or two dominant vendors, which > is a huge disadvantage in some ways. It's both a blessing and a > curse. I expect our "group mind" will continue to exist and evolve. But I'd like t have our "Do we need this sort of extension" discussions done as BOFs, with full cognizance of the fact that committing resources to a new extension is a non-trivial thing. It's far too easy for an eternal working group to just keep giving itself new tasks and never actually finish. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:05:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705383A6A26; Mon, 23 Jun 2008 10:05:48 -0700 (PDT) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 178A13A69D8; Mon, 23 Jun 2008 10:05:45 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080623170546.178A13A69D8@core3.amsl.com> Date: Mon, 23 Jun 2008 10:05:46 -0700 (PDT) Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe-02.txt Technical Summary This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE. Instead of having a subscriber send a SUBSCRIBE for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' state using a single SUBSCRIBE dialog. Working Group Summary The document was originally produced by the SIPPING working group, but was transferred to the SIP working group due to the need to define a new option tag, in conformance with RFC 3427. There is consensus in the WG to publish this document. Document Quality There is a strong requirement from OMA for a SIP solution in this area. Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is the responsible Area Director. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:07:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C863A6A36; Mon, 23 Jun 2008 10:07:08 -0700 (PDT) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7F3953A6A20; Mon, 23 Jun 2008 10:07:07 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080623170707.7F3953A6A20@core3.amsl.com> Date: Mon, 23 Jun 2008 10:07:07 -0700 (PDT) Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-conferencing-02.txt Technical Summary This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a client to provide a conference server with the initial list of participants using an INVITE-contained URI-list. Working Group Summary The document was originally produced by the SIPPING working group, but was transferred to the SIP working group due to the need to define a new option tag, in conformance with RFC 3427. Document Quality There is a strong requirement from OMA and 3GPP for a SIP solution in this area. Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is the responsible Area Director. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:28:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE133A69B6; Mon, 23 Jun 2008 10:28:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54253A69B6 for ; Mon, 23 Jun 2008 10:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTamBESCZOWe for ; Mon, 23 Jun 2008 10:28:04 -0700 (PDT) Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EC63F3A694C for ; Mon, 23 Jun 2008 10:28:03 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5NHRUaY081896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2008 12:27:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Paul Kyzivat In-Reply-To: <485D8B99.8070607@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 12:27:30 -0500 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.1/7541/Mon Jun 23 09:21:03 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul's two points resonate with me. Does anyone expect that if we _did_ build a usage framework for INFO, that we would somehow take the existing uses and retroactively declare them standard and part of that framework without change? If that were possible, what's the difference between that and just documenting them as is and declaring them standard without this framework. So I don't see how building this framework will solve the kind of problem that Martin was punctation-charactering about. As Paul points out, creating the framework might provide better interoperability for some _new_ use, but the level of effort someone would have to go through to get the usage standardized is not going to be easier than standardizing it on its own. So having its not going to do the person that wants a nifty new feature any real good. If we had a truckload of things that would use the framework bursting at the seams waiting for the framework, we'd all, I'm betting, happily work very quickly to create it. I don't see this truckload of things. The existing uses are out there and they're not going to change (so far when I've asked folks with features build on INFO if they'd change their code to use this framework once it existed, they've laughed). So if we do anything at all, I'd favor finishing the work Paul started. RjS On Jun 21, 2008, at 6:15 PM, Paul Kyzivat wrote: > I'm with Eric on this. I worked for awhile and the results seemed > futile, so I'm not overly motivated to start again. But if there is > some possibility of reaching a conclusion then I'll join in. > > Certainly I agree with Martin that there are lots of deployments and > support for INFO in some form. But most of them are non-standard in > one way or another. And I think this leaves us in a Catch-22 > situation: > > - we can just bless unrestricted use of INFO. But that would serve > no purpose, and wouldn't enhance interoperability. > > - or we can formalize rules for negotiating usages of INFO. That > will provide the potential of enhanced interop. But then all the > existing deployments will be incompatible with it. > > Paul > > DOLLY, MARTIN C, ATTLABS wrote: >> Deployments and support of INFO is a reality, unlike some of the >> other >> (@#$ in SIP. >> So either you believe it is real, or you hide your head under the >> covers >> and pretend that there are no ghosts in the closet. -----Original >> Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> eburger@standardstrack.com >> Sent: Saturday, June 21, 2008 3:11 PM >> To: SIP@ietf.org >> Subject: Re: [Sip] INFO and what to do about it? >> If people care, I'll work, but if nobody cares, I won't. >> Sent from my Verizon Wireless BlackBerry >> -----Original Message----- >> From: Cullen Jennings >> Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis > > >> Cc:sip@ietf.org, Jon Peterson >> Subject: Re: [Sip] INFO and what to do about it? >> Personally, I'd like to see some coherent discussion around it in a >> WG meeting then try to get to consensus on it. The totally number >> of people bothering to follow the conversation at this point is >> extremely low. >> On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: >>> I asked: >>> >>> >>>> We've been batting INFO around for many, many years now (like, 10 >>>> -- >>>> it predates the SIP working group). A couple of meetings back, we >>>> agreed that we would discuss use cases for INFO packages, and if we >>>> didn't find any consensus there, then we would go ahead and >>> publish an >>>> "INFO Considered Harmful" RFC. >>>> >>>> We tried having this discussion at the last IETF, but that just >>> didn't >>>> work out. >>>> >>>> Do we try again, or just give up and publish "INFO Considered >>>> Harmful"? >>>> >>>> Personally, I don't care anymore -- I just want to drive a stake >>> into >>>> the heart of this undead-thing, cut off its head, stuff the mouth >>> with >>>> holy wafers, and bury it at a crossroads somewhere. >>>> >>>> But this WG only slays by consensus, so what do you want? >>> Several people (Jonathan, Mary, Christer, Paul) have responded to >>> the >>> list with various things that added up to "Publish INFO packages >>> AND >>> document the extension models for SIP". So far, nobody has suggested >>> otherwise. >>> >>> Does anybody want to do anything else? Speak now or forever >>> visualize >>> whirled peas. >>> >>> -- >>> Dean >>> >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:33:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805143A698B; Mon, 23 Jun 2008 10:33:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6833A698B for ; Mon, 23 Jun 2008 10:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=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 ei0sFjvYQAcQ for ; Mon, 23 Jun 2008 10:33:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3F50B3A694C for ; Mon, 23 Jun 2008 10:33:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 371A7208B1; Mon, 23 Jun 2008 19:33:09 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-b4-485fde55d6f2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 04851208B0; Mon, 23 Jun 2008 19:33:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 19:33:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 19:33:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? thread-index: AcjVVpeNrmdqgEAXSkusR2TvgTEwHwAACv4Q References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> From: "Christer Holmberg" To: "Robert Sparks" , "Paul Kyzivat" X-OriginalArrivalTime: 23 Jun 2008 17:33:34.0245 (UTC) FILETIME=[42F78D50:01C8D557] X-Brightmail-Tracker: AAAAAA== Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Robert, INFO is out there, true, and I am not sure we can do much about that. I don= 't think the intention is to standardize the current usages. I think the idea of the framework is for FUTURE INFO usages. Because, I don= 't think we can assume there won't be more usages in the future than we cur= rently have - even if we would try to "forbid" INFO. Regards, Christer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rober= t Sparks Sent: 23. kes=E4kuuta 2008 20:28 To: Paul Kyzivat Cc: SIP@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: Re: [Sip] INFO and what to do about it? Paul's two points resonate with me. Does anyone expect that if we _did_ build a usage framework for INFO, that = we would somehow take the existing uses and retroactively declare them stan= dard and part of that framework without change? If that were possible, what's the difference between that and just document= ing them as is and declaring them standard without this framework. So I don't see how building this framework will solve the kind of problem t= hat Martin was punctation-charactering about. As Paul points out, creating the framework might provide better interoperab= ility for some _new_ use, but the level of effort someone would have to go = through to get the usage standardized is not going to be easier than standa= rdizing it on its own. So having its not going to do the person that wants = a nifty new feature any real good. If we had a truckload of things that would use the framework bursting at th= e seams waiting for the framework, we'd all, I'm betting, happily work very= quickly to create it. I don't see this truckload of things. The existing = uses are out there and they're not going to change (so far when I've asked = folks with features build on INFO if they'd change their code to use this f= ramework once it existed, they've laughed). So if we do anything at all, I'd favor finishing the work Paul started. RjS On Jun 21, 2008, at 6:15 PM, Paul Kyzivat wrote: > I'm with Eric on this. I worked for awhile and the results seemed = > futile, so I'm not overly motivated to start again. But if there is = > some possibility of reaching a conclusion then I'll join in. > > Certainly I agree with Martin that there are lots of deployments and = > support for INFO in some form. But most of them are non-standard in = > one way or another. And I think this leaves us in a Catch-22 > situation: > > - we can just bless unrestricted use of INFO. But that would serve no = > purpose, and wouldn't enhance interoperability. > > - or we can formalize rules for negotiating usages of INFO. That will = > provide the potential of enhanced interop. But then all the existing = > deployments will be incompatible with it. > > Paul > > DOLLY, MARTIN C, ATTLABS wrote: >> Deployments and support of INFO is a reality, unlike some of the = >> other (@#$ in SIP. >> So either you believe it is real, or you hide your head under the = >> covers and pretend that there are no ghosts in the closet. = >> -----Original >> Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = >> eburger@standardstrack.com >> Sent: Saturday, June 21, 2008 3:11 PM >> To: SIP@ietf.org >> Subject: Re: [Sip] INFO and what to do about it? >> If people care, I'll work, but if nobody cares, I won't. >> Sent from my Verizon Wireless BlackBerry -----Original Message----- >> From: Cullen Jennings >> Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis = >> > > >> Cc:sip@ietf.org, Jon Peterson >> Subject: Re: [Sip] INFO and what to do about it? >> Personally, I'd like to see some coherent discussion around it in a = >> WG meeting then try to get to consensus on it. The totally number of = >> people bothering to follow the conversation at this point is = >> extremely low. >> On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: >>> I asked: >>> >>> >>>> We've been batting INFO around for many, many years now (like, 10 >>>> -- >>>> it predates the SIP working group). A couple of meetings back, we = >>>> agreed that we would discuss use cases for INFO packages, and if we = >>>> didn't find any consensus there, then we would go ahead and >>> publish an >>>> "INFO Considered Harmful" RFC. >>>> >>>> We tried having this discussion at the last IETF, but that just >>> didn't >>>> work out. >>>> >>>> Do we try again, or just give up and publish "INFO Considered = >>>> Harmful"? >>>> >>>> Personally, I don't care anymore -- I just want to drive a stake >>> into >>>> the heart of this undead-thing, cut off its head, stuff the mouth >>> with >>>> holy wafers, and bury it at a crossroads somewhere. >>>> >>>> But this WG only slays by consensus, so what do you want? >>> Several people (Jonathan, Mary, Christer, Paul) have responded to = >>> the list with various things that added up to "Publish INFO = >>> packages AND document the extension models for SIP". So far, nobody = >>> has suggested otherwise. >>> >>> Does anybody want to do anything else? Speak now or forever = >>> visualize whirled peas. >>> >>> -- >>> Dean >>> >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip = >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip = >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:40:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8149B3A67CF; Mon, 23 Jun 2008 10:40:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DF93A6407 for ; Mon, 23 Jun 2008 10:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 ydW6EonT5VXv for ; Mon, 23 Jun 2008 10:40:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 456813A67CF for ; Mon, 23 Jun 2008 10:40:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 23 Jun 2008 13:39:13 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 23 Jun 2008 13:39:14 -0400 From: Hadriel Kaplan To: Robert Sparks , Paul Kyzivat Date: Mon, 23 Jun 2008 13:40:00 -0400 Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjVVmXzzU4yut64RviCw4U0MQKxCAAAVlnw Message-ID: References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "SIP@ietf.org" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org What was "the work Paul started"? You mean Eric's draft? -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Robert Sparks > Sent: Monday, June 23, 2008 1:28 PM > To: Paul Kyzivat > Cc: SIP@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] INFO and what to do about it? > > Paul's two points resonate with me. > > Does anyone expect that if we _did_ build a usage framework for INFO, > that we would somehow take the existing uses and retroactively declare > them standard and part of that framework without change? > > If that were possible, what's the difference between that and just > documenting them as is and declaring them standard without this > framework. > > So I don't see how building this framework will solve the kind of > problem that Martin was punctation-charactering about. > > As Paul points out, creating the framework might provide better > interoperability for some _new_ use, but the level of effort someone > would have to go through to get the usage standardized is not going to > be easier than standardizing it on its own. So having its not going to > do the person that wants a nifty new feature any real good. > > If we had a truckload of things that would use the framework bursting > at the seams waiting for the framework, we'd all, I'm betting, > happily work very quickly to create it. I don't see this truckload of > things. The existing uses are out there and they're not going to > change (so far when I've asked folks with features build on INFO if > they'd change their code to use this framework once it existed, > they've laughed). > > So if we do anything at all, I'd favor finishing the work Paul started. > > RjS _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:47:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5623A69D3; Mon, 23 Jun 2008 10:47:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C263A69D3 for ; Mon, 23 Jun 2008 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=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 dvcT3JzjjnDZ for ; Mon, 23 Jun 2008 10:47:25 -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 B60183A69AF for ; Mon, 23 Jun 2008 10:47:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,691,1204531200"; d="scan'208";a="59460271" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 23 Jun 2008 10:47:24 -0700 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 m5NHlOio022308; Mon, 23 Jun 2008 10:47:24 -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.13.8) with ESMTP id m5NHlNC4003881; Mon, 23 Jun 2008 17:47:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 13:47:23 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 13:47:23 -0400 Message-ID: <485FE1DA.8090302@cisco.com> Date: Mon, 23 Jun 2008 13:48:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Robert Sparks References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> In-Reply-To: X-OriginalArrivalTime: 23 Jun 2008 17:47:23.0452 (UTC) FILETIME=[31367FC0:01C8D559] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7507; t=1214243244; x=1215107244; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=SjVzBBSC61LulduzGhDAxbOn0OJzccZJsOT44wgc7sY=; b=iJVHOH3H3Q96aFVbjr6l6/a8svVfq4A2HmGPV1VBe9Kqhbycnqeisp3NUA A80BgR7B/WPNuAFkdSLufZ6qMm7+iojQI5BxLTziJL7tMFdyJIvt9g1kqoqw 3hSpwPXklD+EdwhD+bJx0zHMdLA261aa87Al1laOoL/rkF2PD/cIQ=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org How about this? Define the new INFO usage framework, for new uses of INFO, along the lines proposed by Hadriel and others. As part of that, establish a registry or registries. Incorporate into that a grandfather clause. If your usage of INFO predated some specified date then it will be permitted to be registered, but not standardized. Presumably the registration would have to be based on Content-Type, since AFAIK that is all that really works for existing usages. The registry for these grandfathered usages would have to point to *some* specification of the usage. It could be be an individual informational RFC, or a document by some other SDO. (What else would make sense?) Existing *standard* usages of INFO (the few there are) would also fall under this grandfather clause. In that case there is an RFC to refer to. *New* usages, after the specified date, would be ineligible for registration under the grandfather clause. They would be required to use the new formal usage mechanism. (Damn, I'm allowing myself to be sucked into this again.) Thanks, Paul Robert Sparks wrote: > Paul's two points resonate with me. > > Does anyone expect that if we _did_ build a usage framework for INFO, > that we would somehow take the existing uses and retroactively declare > them standard and part of that framework without change? > > If that were possible, what's the difference between that and just > documenting them as is and declaring them standard without this framework. > > So I don't see how building this framework will solve the kind of > problem that Martin was punctation-charactering about. > > As Paul points out, creating the framework might provide better > interoperability for some _new_ use, but the level of effort someone > would have to go through to get the usage standardized is not going to > be easier than standardizing it on its own. So having its not going to > do the person that wants a nifty new feature any real good. > > If we had a truckload of things that would use the framework bursting at > the seams waiting for the framework, we'd all, I'm betting, > happily work very quickly to create it. I don't see this truckload of > things. The existing uses are out there and they're not going to change > (so far when I've asked folks with features build on INFO if they'd > change their code to use this framework once it existed, they've laughed). > > So if we do anything at all, I'd favor finishing the work Paul started. > > RjS > > > > On Jun 21, 2008, at 6:15 PM, Paul Kyzivat wrote: > >> I'm with Eric on this. I worked for awhile and the results seemed >> futile, so I'm not overly motivated to start again. But if there is >> some possibility of reaching a conclusion then I'll join in. >> >> Certainly I agree with Martin that there are lots of deployments and >> support for INFO in some form. But most of them are non-standard in >> one way or another. And I think this leaves us in a Catch-22 situation: >> >> - we can just bless unrestricted use of INFO. But that would serve no >> purpose, and wouldn't enhance interoperability. >> >> - or we can formalize rules for negotiating usages of INFO. That will >> provide the potential of enhanced interop. But then all the existing >> deployments will be incompatible with it. >> >> Paul >> >> DOLLY, MARTIN C, ATTLABS wrote: >>> Deployments and support of INFO is a reality, unlike some of the other >>> (@#$ in SIP. >>> So either you believe it is real, or you hide your head under the covers >>> and pretend that there are no ghosts in the closet. -----Original >>> Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >>> eburger@standardstrack.com >>> Sent: Saturday, June 21, 2008 3:11 PM >>> To: SIP@ietf.org >>> Subject: Re: [Sip] INFO and what to do about it? >>> If people care, I'll work, but if nobody cares, I won't. >>> Sent from my Verizon Wireless BlackBerry >>> -----Original Message----- >>> From: Cullen Jennings >>> Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis >>> >>> Cc:sip@ietf.org, Jon Peterson >>> Subject: Re: [Sip] INFO and what to do about it? >>> Personally, I'd like to see some coherent discussion around it in a >>> WG meeting then try to get to consensus on it. The totally number >>> of people bothering to follow the conversation at this point is >>> extremely low. >>> On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: >>>> I asked: >>>> >>>> >>>>> We've been batting INFO around for many, many years now (like, 10 -- >>>>> it predates the SIP working group). A couple of meetings back, we >>>>> agreed that we would discuss use cases for INFO packages, and if we >>>>> didn't find any consensus there, then we would go ahead and >>>> publish an >>>>> "INFO Considered Harmful" RFC. >>>>> >>>>> We tried having this discussion at the last IETF, but that just >>>> didn't >>>>> work out. >>>>> >>>>> Do we try again, or just give up and publish "INFO Considered >>>>> Harmful"? >>>>> >>>>> Personally, I don't care anymore -- I just want to drive a stake >>>> into >>>>> the heart of this undead-thing, cut off its head, stuff the mouth >>>> with >>>>> holy wafers, and bury it at a crossroads somewhere. >>>>> >>>>> But this WG only slays by consensus, so what do you want? >>>> Several people (Jonathan, Mary, Christer, Paul) have responded to the >>>> list with various things that added up to "Publish INFO packages AND >>>> document the extension models for SIP". So far, nobody has suggested >>>> otherwise. >>>> >>>> Does anybody want to do anything else? Speak now or forever visualize >>>> whirled peas. >>>> >>>> -- >>>> Dean >>>> >>>> >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:48:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044533A6A80; Mon, 23 Jun 2008 10:48:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52913A6A80 for ; Mon, 23 Jun 2008 10:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 SwcqT-mtBYw8 for ; Mon, 23 Jun 2008 10:48:11 -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 77C6E3A6A7A for ; Mon, 23 Jun 2008 10:48:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,691,1204520400"; d="scan'208";a="11944875" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Jun 2008 13:48:11 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5NHmBSe005505; Mon, 23 Jun 2008 13:48:11 -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.13.8) with ESMTP id m5NHmBRe026256; Mon, 23 Jun 2008 17:48:11 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.1830); Mon, 23 Jun 2008 13:48:06 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 13:48:05 -0400 Message-ID: <485FE204.10603@cisco.com> Date: Mon, 23 Jun 2008 13:48:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hadriel Kaplan References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> In-Reply-To: X-OriginalArrivalTime: 23 Jun 2008 17:48:05.0894 (UTC) FILETIME=[4A82A260:01C8D559] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1914; t=1214243291; x=1215107291; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=lXlxomH+2rzPW5MM1Hv8Zq3IdqwqCXm60UU4z065VcE=; b=ASo9N2kbN5B8v731vi33S64UNcKmMhK5MPFOPxTK7f0ZrhlX7whneGKksm ns/z1fyNEPbn6dBAmReme4U3X4xAq3+9VubM54Biny636i4cvrfCC26keiXy 3BQwkBb71c; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "SIP@ietf.org" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I forget who the last proposal was from, but it wasn't me. Paul Hadriel Kaplan wrote: > What was "the work Paul started"? You mean Eric's draft? > > -hadriel > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Robert Sparks >> Sent: Monday, June 23, 2008 1:28 PM >> To: Paul Kyzivat >> Cc: SIP@ietf.org; DOLLY, MARTIN C, ATTLABS >> Subject: Re: [Sip] INFO and what to do about it? >> >> Paul's two points resonate with me. >> >> Does anyone expect that if we _did_ build a usage framework for INFO, >> that we would somehow take the existing uses and retroactively declare >> them standard and part of that framework without change? >> >> If that were possible, what's the difference between that and just >> documenting them as is and declaring them standard without this >> framework. >> >> So I don't see how building this framework will solve the kind of >> problem that Martin was punctation-charactering about. >> >> As Paul points out, creating the framework might provide better >> interoperability for some _new_ use, but the level of effort someone >> would have to go through to get the usage standardized is not going to >> be easier than standardizing it on its own. So having its not going to >> do the person that wants a nifty new feature any real good. >> >> If we had a truckload of things that would use the framework bursting >> at the seams waiting for the framework, we'd all, I'm betting, >> happily work very quickly to create it. I don't see this truckload of >> things. The existing uses are out there and they're not going to >> change (so far when I've asked folks with features build on INFO if >> they'd change their code to use this framework once it existed, >> they've laughed). >> >> So if we do anything at all, I'd favor finishing the work Paul started. >> >> RjS > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:49:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B918E3A6A93; Mon, 23 Jun 2008 10:49:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F7A3A6A7E for ; Mon, 23 Jun 2008 10:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, J_CHICKENPOX_24=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 GZfPBfI0zw6k for ; Mon, 23 Jun 2008 10:49:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5BBD03A6A7C for ; Mon, 23 Jun 2008 10:49:49 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5NHna100442; Mon, 23 Jun 2008 17:49:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 12:46:45 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjVVpeNrmdqgEAXSkusR2TvgTEwHwAACv4QAABs6tA= References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> From: "Mary Barnes" To: "Christer Holmberg" , "Robert Sparks" , "Paul Kyzivat" Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't believe we could ever forbid INFO. I initially did not think we cou= ld accomplish anything around INFO, but I believe some of the work that's o= n the table would be useful for working towards interoperabilty for the INF= O usages. I would be afraid to ask honestly for the identification of all t= he different uses of INFO that are out there right now. = Doing something is better than nothing at this point IMHO and I'm personall= y really tired of revisiting this issue every couple of years. AND, this wo= uld help us put a stake in the group on the future usages of INFO (whether = we ever get rid of the old usages or not), as I believe there are other SDO= s defining new uses of INFO right now to add to the mix of un-interoperabil= ity in this area. My two cents, Mary. = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris= ter Holmberg Sent: Monday, June 23, 2008 12:34 PM To: Robert Sparks; Paul Kyzivat Cc: SIP@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: Re: [Sip] INFO and what to do about it? Hi Robert, INFO is out there, true, and I am not sure we can do much about that. I don= 't think the intention is to standardize the current usages. I think the idea of the framework is for FUTURE INFO usages. Because, I don= 't think we can assume there won't be more usages in the future than we cur= rently have - even if we would try to "forbid" INFO. Regards, Christer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rober= t Sparks Sent: 23. kes=E4kuuta 2008 20:28 To: Paul Kyzivat Cc: SIP@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: Re: [Sip] INFO and what to do about it? Paul's two points resonate with me. Does anyone expect that if we _did_ build a usage framework for INFO, that = we would somehow take the existing uses and retroactively declare them stan= dard and part of that framework without change? If that were possible, what's the difference between that and just document= ing them as is and declaring them standard without this framework. So I don't see how building this framework will solve the kind of problem t= hat Martin was punctation-charactering about. As Paul points out, creating the framework might provide better interoperab= ility for some _new_ use, but the level of effort someone would have to go = through to get the usage standardized is not going to be easier than standa= rdizing it on its own. So having its not going to do the person that wants = a nifty new feature any real good. If we had a truckload of things that would use the framework bursting at th= e seams waiting for the framework, we'd all, I'm betting, happily work very= quickly to create it. I don't see this truckload of things. The existing = uses are out there and they're not going to change (so far when I've asked = folks with features build on INFO if they'd change their code to use this f= ramework once it existed, they've laughed). So if we do anything at all, I'd favor finishing the work Paul started. RjS On Jun 21, 2008, at 6:15 PM, Paul Kyzivat wrote: > I'm with Eric on this. I worked for awhile and the results seemed = > futile, so I'm not overly motivated to start again. But if there is = > some possibility of reaching a conclusion then I'll join in. > > Certainly I agree with Martin that there are lots of deployments and = > support for INFO in some form. But most of them are non-standard in = > one way or another. And I think this leaves us in a Catch-22 > situation: > > - we can just bless unrestricted use of INFO. But that would serve no = > purpose, and wouldn't enhance interoperability. > > - or we can formalize rules for negotiating usages of INFO. That will = > provide the potential of enhanced interop. But then all the existing = > deployments will be incompatible with it. > > Paul > > DOLLY, MARTIN C, ATTLABS wrote: >> Deployments and support of INFO is a reality, unlike some of the = >> other (@#$ in SIP. >> So either you believe it is real, or you hide your head under the = >> covers and pretend that there are no ghosts in the closet. >> -----Original >> Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = >> eburger@standardstrack.com >> Sent: Saturday, June 21, 2008 3:11 PM >> To: SIP@ietf.org >> Subject: Re: [Sip] INFO and what to do about it? >> If people care, I'll work, but if nobody cares, I won't. >> Sent from my Verizon Wireless BlackBerry -----Original Message----- >> From: Cullen Jennings >> Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis = >> > > >> Cc:sip@ietf.org, Jon Peterson >> Subject: Re: [Sip] INFO and what to do about it? >> Personally, I'd like to see some coherent discussion around it in a = >> WG meeting then try to get to consensus on it. The totally number of = >> people bothering to follow the conversation at this point is = >> extremely low. >> On Jun 18, 2008, at 10:08 PM, Dean Willis wrote: >>> I asked: >>> >>> >>>> We've been batting INFO around for many, many years now (like, 10 >>>> -- >>>> it predates the SIP working group). A couple of meetings back, we = >>>> agreed that we would discuss use cases for INFO packages, and if we = >>>> didn't find any consensus there, then we would go ahead and >>> publish an >>>> "INFO Considered Harmful" RFC. >>>> >>>> We tried having this discussion at the last IETF, but that just >>> didn't >>>> work out. >>>> >>>> Do we try again, or just give up and publish "INFO Considered = >>>> Harmful"? >>>> >>>> Personally, I don't care anymore -- I just want to drive a stake >>> into >>>> the heart of this undead-thing, cut off its head, stuff the mouth >>> with >>>> holy wafers, and bury it at a crossroads somewhere. >>>> >>>> But this WG only slays by consensus, so what do you want? >>> Several people (Jonathan, Mary, Christer, Paul) have responded to = >>> the list with various things that added up to "Publish INFO = >>> packages AND document the extension models for SIP". So far, nobody = >>> has suggested otherwise. >>> >>> Does anybody want to do anything else? Speak now or forever = >>> visualize whirled peas. >>> >>> -- >>> Dean >>> >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip = >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip = >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _________________________________= ______________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:52:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BDD3A69AF; Mon, 23 Jun 2008 10:52:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16BC53A69AF for ; Mon, 23 Jun 2008 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXG1LaoW+Bwd for ; Mon, 23 Jun 2008 10:52:18 -0700 (PDT) Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A8CC33A67CF for ; Mon, 23 Jun 2008 10:52:17 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5NHqCo8084571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2008 12:52:13 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Paul Kyzivat In-Reply-To: <485FE204.10603@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 12:52:12 -0500 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> <485FE204.10603@cisco.com> X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.1/7542/Mon Jun 23 11:42:14 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: "SIP@ietf.org" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org But you did do a lot of the early hard lifting and that's what I was nodding towards. On Jun 23, 2008, at 12:48 PM, Paul Kyzivat wrote: > I forget who the last proposal was from, but it wasn't me. > > Paul > > Hadriel Kaplan wrote: >> What was "the work Paul started"? You mean Eric's draft? >> -hadriel >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >>> Of >>> Robert Sparks >>> Sent: Monday, June 23, 2008 1:28 PM >>> To: Paul Kyzivat >>> Cc: SIP@ietf.org; DOLLY, MARTIN C, ATTLABS >>> Subject: Re: [Sip] INFO and what to do about it? >>> >>> Paul's two points resonate with me. >>> >>> Does anyone expect that if we _did_ build a usage framework for >>> INFO, >>> that we would somehow take the existing uses and retroactively >>> declare >>> them standard and part of that framework without change? >>> >>> If that were possible, what's the difference between that and just >>> documenting them as is and declaring them standard without this >>> framework. >>> >>> So I don't see how building this framework will solve the kind of >>> problem that Martin was punctation-charactering about. >>> >>> As Paul points out, creating the framework might provide better >>> interoperability for some _new_ use, but the level of effort someone >>> would have to go through to get the usage standardized is not >>> going to >>> be easier than standardizing it on its own. So having its not >>> going to >>> do the person that wants a nifty new feature any real good. >>> >>> If we had a truckload of things that would use the framework >>> bursting >>> at the seams waiting for the framework, we'd all, I'm betting, >>> happily work very quickly to create it. I don't see this truckload >>> of >>> things. The existing uses are out there and they're not going to >>> change (so far when I've asked folks with features build on INFO if >>> they'd change their code to use this framework once it existed, >>> they've laughed). >>> >>> So if we do anything at all, I'd favor finishing the work Paul >>> started. >>> >>> RjS _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 10:54:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED573A6A4B; Mon, 23 Jun 2008 10:54:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFE73A6A4B for ; Mon, 23 Jun 2008 10:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 qHh-PHmWYHB7 for ; Mon, 23 Jun 2008 10:54:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F1C763A6A2A for ; Mon, 23 Jun 2008 10:54:33 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 23 Jun 2008 13:53:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 23 Jun 2008 13:53:43 -0400 From: Hadriel Kaplan To: Dean Willis , Paul Kyzivat Date: Mon, 23 Jun 2008 13:54:27 -0400 Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjU6WjbFjWtuej1T36EnkIODV2UewAA8DnQ Message-ID: References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> <485F2382.20507@softarmor.com> In-Reply-To: <485F2382.20507@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "SIP@ietf.org" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Monday, June 23, 2008 12:16 AM > > > > Certainly I agree with Martin that there are lots of deployments and > > support for INFO in some form. But most of them are non-standard in one > > way or another. And I think this leaves us in a Catch-22 situation: > > > > - we can just bless unrestricted use of INFO. But that would serve no > > purpose, and wouldn't enhance interoperability. The EXACT same thing could be said for deprecating/outlawing info: "We can just restrict the use of INFO. But that would serve no purpose, and wouldn't enhance interoperability." > > - or we can formalize rules for negotiating usages of INFO. That will > > provide the potential of enhanced interop. But then all the existing > > deployments will be incompatible with it. > > That sounds like a vote for defaulting and publishing Eric's original > "Why you shouldn't use INFO for anything" draft. Ummm... I don't see how that solves the: "But then all existing deployments will be incompatible with it" concern. All existing deployments would _still_ be incompatible with such a "don't-use info" draft. Or is the argument: "there would be no way to make this backwards compatible"? I think it would be backwards compatible. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 11:23:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866413A69D5; Mon, 23 Jun 2008 11:23:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676C03A69E2 for ; Mon, 23 Jun 2008 11:23:30 -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 8Jf0lwndj5iJ for ; Mon, 23 Jun 2008 11:23:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 24F783A69CE for ; Mon, 23 Jun 2008 11:23:29 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5NINMMh009617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2008 13:23:24 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <485FE1DA.8090302@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 13:23:17 -0500 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> <485FE1DA.8090302@cisco.com> X-Mailer: Apple Mail (2.924) Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 23, 2008, at 12:48 PM, Paul Kyzivat wrote: > How about this? > > Define the new INFO usage framework, for new uses of INFO, along the > lines proposed by Hadriel and others. As part of that, establish a > registry or registries. > > Incorporate into that a grandfather clause. If your usage of INFO > predated some specified date then it will be permitted to be > registered, but not standardized. Presumably the registration would > have to be based on Content-Type, since AFAIK that is all that > really works for existing usages. The registry for these > grandfathered usages would have to point to *some* specification of > the usage. It could be be an individual informational RFC, or a > document by some other SDO. (What else would make sense?) > > Existing *standard* usages of INFO (the few there are) would also > fall under this grandfather clause. In that case there is an RFC to > refer to. > > *New* usages, after the specified date, would be ineligible for > registration under the grandfather clause. They would be required to > use the new formal usage mechanism. > That works for me. It's quite rational, given where we find ourselves, and fits with the goal of "reducing further damage." > (Damn, I'm allowing myself to be sucked into this again.) I'm so sorry ;-). -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 11:38:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254513A6991; Mon, 23 Jun 2008 11:38:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD713A697D for ; Mon, 23 Jun 2008 11:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 UgNMjE74Sv-8 for ; Mon, 23 Jun 2008 11:38:25 -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 641673A68DB for ; Mon, 23 Jun 2008 11:38:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,691,1204531200"; d="scan'208";a="43458825" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2008 11:38:04 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5NIc4rC016363; Mon, 23 Jun 2008 11:38:04 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m5NIc3FY029402; Mon, 23 Jun 2008 18:38:04 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.1830); Mon, 23 Jun 2008 14:38:03 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 14:38:03 -0400 Message-ID: <485FEDBA.9090304@cisco.com> Date: Mon, 23 Jun 2008 14:38:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dean Willis References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> In-Reply-To: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> X-OriginalArrivalTime: 23 Jun 2008 18:38:03.0397 (UTC) FILETIME=[45294B50:01C8D560] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4275; t=1214246284; x=1215110284; c=relaxed/simple; s=sjdkim2002; 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[Sip]=20(no=20subject) |Sender:=20; bh=13Akzu2ps3SsPOpW62UMZjNeEgXWaF7C7Qa/PdsEwP0=; b=TmsQH/bVq518NVrkMXDAPAtkyOfYAo4XfV1sENsskbzvDn3OoEPeFZ1pnm 7wDbfmrOYIBJobiXjKyplOjVUQZ4qy2of6W1fANapUVd/tFkE/yrhOJ5X9Cg LMTW87XhXr; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] (no subject) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Four 1hr meetings does not equal one four hour meeting. With the time it takes for a prior group to clear a room and another group to enter, achieve quorum, and cover clerical details, you have lost probably 20 minutes at a minimum. So your four one hour meetings provide 4*(60-20)=160 minutes of useful time. A four hour meeting has 4*60-20=220 minutes. You just lost an hour of working time. Paul Dean Willis wrote: > > On Jun 23, 2008, at 11:20 AM, Hadriel Kaplan wrote: > >> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >>> Dean Willis >>> >>> The problem that I'm trying to solve is making the task space >>> manageable. >>> The first thing is to distribute the chair load. >> >> Obviously splitting/spawning WG's will do that, but I thought there >> was an AD resource contention issue - if we had more WG meeting slots >> then neither of our AD's could be in some meeting or other. Is that >> not one of the issues? It was the response I got when I and others >> suggested SIP Security topics (Identity/Privacy/SIPS/Certs/etc.) >> should be split into a separate WG a while back. > >> There was also some concern over not having any more RAI time slots >> anyway, but I think that's a red herring and overlapping some RAI WG >> meeting times is reasonable for certain topics. >> > > > We can have four new working groups that meet for an hour each, or we > can have one existing WG that meets for four hours. Same meeting time, > same AD conflicts, but four times as many chairs to do the management work. > > What we can't have is four new working groups that meet for four hours > each. This means scope creep (and scope inflation) must be rigorously > controlled. Hence, each charter must be tightly constrained, and each WG > narrowly focused. > > The fact is that our working groups are so big now that the chairs can't > devote enough time to thoroughly manage individual subjects. So the > chairs aren't offloading enough of the work from the ADs. Doubling the > number of chairs might not cut the ADs load in half, but it could > certainly reduce it, although this is true if and only if the focus of > each WG (and chair) is precise. I can't stay on top of the status of 38 > work items that go on for many years. I could probably manage four work > items that last for no more than two years. > >> >>> I think developing a SIP extension should be a Big Thing. If it's >>> important enough to develop a SIP extension for, it is probably >>> important enough to charter a working group to develop that extension. >>> It's a Really Bad Idea to have a standing working group that sits >>> around and develops SIP extensions. All that gets us is a whole lot of >>> extensions. It doesn't get us any closer to a draft standard. >> >> I agree with you in principle, but I doubt it's possible in practice. >> There's some fine line there, because if you don't address an >> issue/need multiple people have, then they just go solve it in a >> proprietary fashion independently and interop still sucks. One >> problem is we don't have a single cohesive "group" view and use of >> SIP, so we're left with the shotgun extensions approach, seeing which >> ones will stick. I can't recall another successful protocol this >> complicated that didn't have one or two dominant vendors, which is a >> huge disadvantage in some ways. It's both a blessing and a curse. > > I expect our "group mind" will continue to exist and evolve. But I'd > like t have our "Do we need this sort of extension" discussions done as > BOFs, with full cognizance of the fact that committing resources to a > new extension is a non-trivial thing. It's far too easy for an eternal > working group to just keep giving itself new tasks and never actually > finish. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 12:27:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BE23A69FA; Mon, 23 Jun 2008 12:27:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D6F3A69FA for ; Mon, 23 Jun 2008 12:27:35 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqnN-3bSdFPP for ; Mon, 23 Jun 2008 12:27:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8B9B53A69E1 for ; Mon, 23 Jun 2008 12:27:34 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5NJR9io009910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2008 14:27:11 -0500 Message-Id: <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <485FEDBA.9090304@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 14:27:03 -0500 References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> X-Mailer: Apple Mail (2.924) Cc: "sip@ietf.org" Subject: Re: [Sip] (no subject) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 23, 2008, at 1:38 PM, Paul Kyzivat wrote: > Four 1hr meetings does not equal one four hour meeting. With the > time it takes for a prior group to clear a room and another group to > enter, achieve quorum, and cover clerical details, you have lost > probably 20 minutes at a minimum. So your four one hour meetings > provide 4*(60-20)=160 minutes of useful time. A four hour meeting > has 4*60-20=220 minutes. You just lost an hour of working time. Personally, I gained about 4 hours of working time . . . Seriously, I don't think the overhead is as high as you estimate, but it's certainly not "zero". However: If the 4 meetings were better run and better focused because they had clear scope, comprehensible agendas, and chairs with enough time to do the job right, I believe we'd still come out ahead over what we have now. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 13:11:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0F13A697B; Mon, 23 Jun 2008 13:11:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05A13A697B for ; Mon, 23 Jun 2008 13:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, FRT_PACKAGE=0.967] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THPbOhwlz51J for ; Mon, 23 Jun 2008 13:11:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A160A3A688D for ; Mon, 23 Jun 2008 13:11:51 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5NKBlGL010085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2008 15:11:49 -0500 Message-Id: <84A73E70-070A-4FBC-8148-BFE0776F9A28@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 15:11:42 -0500 X-Mailer: Apple Mail (2.924) Cc: Keith Drage Subject: [Sip] Draft Proto-Shepherd writeup for draft-ietf-sip-xcapevent-0 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I believe we're about ready to send the XCAP Event Package draft to the IESG. I believe I will be serving as the Document Shepherd. As shepherd, I get to do the writeup that accompanies the draft onto the iESG docket. Here's my working draft of that writeup. If you have anything to add, please do do. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd is SIP working group chair Dean Willis. He has personally reviewed this version of the document and believes it is ready for forwrding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been thoroughly reviewed in the working group. Further review was requested and received from the Open Mobile Alliance's Presence and Availability working group, which is expected to be a major user of the specification. Specialized event-package review was provided by Adam Roach, author of the SIP Events specification RFC 3325. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The shepherd has no concerns that the document requires additional or broader review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The shepherd has no specific concerns with this document, and is unaware of any IPR disclosure related to this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong working group consensus behind this document. It is the evolution of several years work related to use of XCAP for configuration delivery and for managing subscriber and buddy lists. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) The shepherd is not aware of any significant discontent related to this draft. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The shepherd verified that the draft satisfies all ID nits to the best of his ability. It does have one slightly stale reference to draft-ietf-simple-xcap-diff-08 which is now in -09, but this does not impact the draft. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are appropriately split. The draft does depend on draft-ietf-simple-xcap-diff and on draft-ietf-sip-subnot-etags, both of which should be ready for review in approximately the same time frame. There are no known downrefs. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations appear to be correct. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The shepherd verified the BNF and XML. Since the XML was verified with the author's own popular XML verifier, no errors were really expected. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The XCAP (XML Confgiration Access Protocol, RFC 4825) protocol provides for change control on structured data. This specification provides a SIP Event Paackage (RFC 3325) that can be used to monitor changes to an XCAP document. Change notifications may include differential changes expressed using the XCAP-Diff format described in draft-ietf-simple-xcap-diff. This specification also provides for initial synchronization between a stored version of an XCAP document and a remote copy being monitored using the protocol of thsi specification. Working Group Summary This specification developed out of the larger body of configuration management work related to SIP (RFC 3261). In particular, it relates to XCAP (RFC 4825) and the SIP Configuration Framework (draft-ietf-sipping-config-framework). The content of this specification was split off from the configuration framework document about two years ago, and has progressed indepdently. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Document Quality There are existing implementations of earlier versions of the protocol, and a significant number of vendors have committed to implementation of the specification in the context of the Open Mobile Alliances's Push-to-Talk Over Cellularspecification. Adam Roach provided specific guidance and review on the SIP Event Package aspects of this specification. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 13:23:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FA93A6A16; Mon, 23 Jun 2008 13:23:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1942E3A67B2 for ; Mon, 23 Jun 2008 13:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 u296j4pmQYPf for ; Mon, 23 Jun 2008 13:23:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E32323A6A16 for ; Mon, 23 Jun 2008 13:23:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 23 Jun 2008 16:22:24 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 23 Jun 2008 16:22:24 -0400 From: Hadriel Kaplan To: Dean Willis , Paul Kyzivat Date: Mon, 23 Jun 2008 16:23:10 -0400 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjVZxoGsHQkulsvTvyEvutvE550YgAAFaGg Message-ID: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> In-Reply-To: <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org [fixed subject title, since I apparently broke it] How about a compromise: 2 WG's of 2-hour meetings each (since today's SIP WG actually takes 2 of 2-hour meeting slots I think). One for the general SIP stuff as today, and one for "SIP Security". The new security group would take such things as: draft-ietf-sip-dtls-srtp-framework draft-ietf-sip-eku draft-ietf-sip-media-security-requirements draft-ietf-sip-ua-privacy draft-ietf-sip-domain-certs draft-ietf-sip-e2m-sec draft-ietf-sip-saml And it would be the venue for any new drafts/work related to Identity, Privacy, transport/media security as relates to SIP, etc. I think this is roughly half the work in the SIP WG. The people attending these two WG's would probably be nearly identical as today's SIP WG, and they would consume the same amount of meeting time as today's SIP WG, but it would cut your chair work in half. It *won't* solve your eternal WG issue, but I think that problem is orthogonal and separately debatable. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Monday, June 23, 2008 3:27 PM > To: Paul Kyzivat > Cc: sip@ietf.org > Subject: Re: [Sip] (no subject) > > > On Jun 23, 2008, at 1:38 PM, Paul Kyzivat wrote: > > > Four 1hr meetings does not equal one four hour meeting. With the > > time it takes for a prior group to clear a room and another group to > > enter, achieve quorum, and cover clerical details, you have lost > > probably 20 minutes at a minimum. So your four one hour meetings > > provide 4*(60-20)=160 minutes of useful time. A four hour meeting > > has 4*60-20=220 minutes. You just lost an hour of working time. > > Personally, I gained about 4 hours of working time . . . > > Seriously, I don't think the overhead is as high as you estimate, but > it's certainly not "zero". > > However: > > If the 4 meetings were better run and better focused because they had > clear scope, comprehensible agendas, and chairs with enough time to do > the job right, I believe we'd still come out ahead over what we have > now. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 14:22:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991863A6A15; Mon, 23 Jun 2008 14:22:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A043A69E5 for ; Mon, 23 Jun 2008 14:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 zXmA86vM-ETj for ; Mon, 23 Jun 2008 14:22:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 37D2C3A6A15 for ; Mon, 23 Jun 2008 14:22:38 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5NLMR1m010568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2008 16:22:29 -0500 Message-Id: <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 16:22:22 -0500 References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> X-Mailer: Apple Mail (2.924) Cc: "sip@ietf.org" , Paul Kyzivat Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 23, 2008, at 3:23 PM, Hadriel Kaplan wrote: > [fixed subject title, since I apparently broke it] > > How about a compromise: 2 WG's of 2-hour meetings each (since > today's SIP WG actually takes 2 of 2-hour meeting slots I think). > One for the general SIP stuff as today, and one for "SIP Security". Ah yes, two eternal working groups to replace one. > The new security group would take such things as: > draft-ietf-sip-dtls-srtp-framework -- This one is arguably done, depending on what we believe about RFC 4474 and gateways/b2buas. > > draft-ietf-sip-eku -- EKU is basically done. > > draft-ietf-sip-media-security-requirements -- This one is done > > draft-ietf-sip-ua-privacy -- This one is done, > > draft-ietf-sip-domain-certs -- This one is done > > draft-ietf-sip-e2m-sec -- This one is done > > draft-ietf-sip-saml -- I'm not sure this one is ever getting done. So I'm not sure there's enough there to justify a WG. How about an "Identity in SIP" working group that takes on fixing RFC 4474 for gateways/b2buas and possibly considers identity/role assertion using SAML? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 14:46:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D138D3A685A; Mon, 23 Jun 2008 14:46:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797273A685A for ; Mon, 23 Jun 2008 14:46:29 -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 XojXKHZbR4GQ for ; Mon, 23 Jun 2008 14:46:28 -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 0E4FE3A6805 for ; Mon, 23 Jun 2008 14:46:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,692,1204531200"; d="scan'208";a="43557819" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2008 14:46:28 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5NLkS1X001555; Mon, 23 Jun 2008 14:46:28 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5NLkRnW024784; Mon, 23 Jun 2008 21:46:28 GMT From: "Dan Wing" To: "'Dean Willis'" , References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> Date: Mon, 23 Jun 2008 14:46:27 -0700 Message-ID: <08d301c8d57a$9762f370$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjQCA01C3fb+uDtRcuzwV894WZjsAFcbNLw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8399; t=1214257588; x=1215121588; c=relaxed/simple; s=sjdkim4002; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=KXAIEZnG5nPLRe/KfkU4HLJCkV8zjeqXJDKjwRNtNZY=; b=lvdpeL88Z+MZ0JGB5pmUZmnSS5mELIfV9BHp4iNuHHR4zGyeSZ8uJHALjq 61UwHRQ9PKYwYjj9ksio+iOcRDNBo9/+jB/A1EAGxezPhrzlDA9YIZHHBdNI NPK3WsTxNc; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My two cents: I like the idea of splitting SIP into smaller working groups which have a defined deliverable and finite lifespan. Doing this does not reduce the work of the individual contributors, but provides a different benefit: it demonstrates interest in specific issues and problems (by the attendance and activity of the more-focused working group), and it allows working group chairs to be successful. In a standards organization, 'success' is defined as finishing something. Unfortunately with a never-end set of tasks in front of SIP (and SIPPPING, MMUSIC, AVT, and probably others), there is never a sense of completion. Nothing is 'done'. I know that we have had difficulty getting chairs for various RAI working groups. By creating working groups that have a narrower charter, clear deliverable, and achievable milestones, we can adopt a more normal structure -- a structure where an individual contributor can reasonably spend 2-3 years chairing a working group rather than taking on the significant task of spinning up to understand all of SIP, SIPPING, MMUSIC, or AVT, and having to resign after 5 (or 9 years) because they are burned out and no longer interested in chairing. -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Monday, June 16, 2008 4:23 PM > To: sip@ietf.org > Subject: [Sip] Toward the Evolution of SIP and Related Working Groups > > > The SIP working group spun off from the MMUSIC working group when we > realized that the SIP work was reasonably separable from the other > work going on in MMUSIC. > > The SIP working group first met officially at IETF 46 in November > 1999, although we did have an earlier interim meeting. > > This means that the fall 1999 meeting will be our 10th > anniversary. In > addition to having a big party, I'd also like to plan for this being > the last meeting of the SIP working group as it is now defined. Ten > years is long enough. It's time we restructured. > > There will probably still be people who want to change, revise, > extend, or otherwise manipulate the family of SIP > specifications after > 2009. > > So what should we do? How should we organize to get those > needs met? > Rest assured, we'll be having further discussions on this > topic in the > coming months. But I'd like to start the discussion now. > > By November 2009, I fully expect SIP to have completed the > majority of > currently chartered items. Between now and then, we'll probably also > take on and complete a bit of new work (although I plan to be very > resistant to new work). I also expect that there are a few items on > our charter now that we're not going to finish. It may well be that > some of those items need a different organizational structure to > progress than what we have. Or maybe they don't need doing. > > Further, I've come to believe that most working groups should be > shorter-lived and tightly constrained by their charters to produce a > single concise set of deliverables. There's still a need for > a longer- > lived thing that maintains architectural oversight. I've come to > believe that this is the "area", not the working group. > > Let's start the recap by looking at the current charter of > the SIP WG. > I've eliminated the WGLC milestones to shorten the list, as > each has a > following IESG milestone. Note that there's a Feb 2008 milestone for > "Revise Charter". You can consider this topic the first > installment on > that milestone, even though it is a bit late. > > 1) Jul 2007 Location Conveyance with SIP to IESG (PS) > > 2) Aug 2007 Connection reuse mechanism to IESG (PS) > > 3) Sep 2007 Session Policies to IESG as PS > > 4) Sep 2007 Example security flows to IESG (Informational) > > 5) Oct 2007 New resource priority namespaces for DISA to IESG (PS) > > 6) Nov 2007 Requirements for media keying to IESG (Informational) > > 7 )Dec 2007 Extensions to SIP UA Profile Delivery Change > Notification > Event Package for XCAP to IESG (PS) > > 8) Dec 2007 Roadmap for SIP to IESG (Informational) > > 9) Dec 2007 Using SAML for SIP to IESG (PS) > > 10) Dec 2007 Extension for use in etags in conditional > notification to > IESG (PS) > > 11) Feb 2008 Identify requirements for test matrix to move SIP to > Draft Standard > > 12) Feb 2008 Delivering request-URI and parameters to UAS via > proxy to > IESG (PS) > > 13) Feb 2008 Revise charter > > 14) Feb 2008 Establishment of secure media sessions using > DTLS-SRTP to > IESG (PS) > > 15) Apr 2008 MIME body handling in SIP to IESG (PS) > > 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to > IESG (PS) > > 17) Jul 2008 Mechanisms for UA initiated privacy to IESG (BCP) > > 18) Aug 2008 Guidelines for double route recording to IESG (BCP) > > 19) Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) > > 20) Sep 2008 X.509 extended key usage for SIP to IESG (PS) > > 21) Nov 2008 Termination of early dialog prior to final response to > IESG (PS) > > > Looking at this, we have a couple of discrete tasks that I > think might > make the basis for different narrowly-scoped working groups. We've > also got a lot of stuff that we're late on delivering! > > 1) SIP WG (to finish by end of 2009) gets the bulk of these items. > > 2) SIP Draft Standard WG: Takes the milestone of "Identify > requirements for test matrix to move SIP to Draft Standard" > and all of > the follow-on work needed to move SIP from Proposed to Draft on the > standards track. There's certainly enough work here for a dedicated > working group, with the last milestone being something like "Deliver > SIP as a Draft Standards Document to IESG". We may wish to consider > whether we really want to go this route or whether we should instead > be thinking of a "SIP 3.0" effort. My personal though is that > there's > just too much cruft in the RFC 3261 family to make Draft, but > I could > be proven wrong. I'd rather see us put SIP 2.0 into maintenance mode > at the end of 2009 and move the bulk of our resources into > developing > a SIP 3.0 family designed from the ground up to be Draft-Standard > achievable. > > 3) RAI Essential Corrections WG: Does this justify its own working > group? Remember, it would be not just RFC 3261, but the > entire family > of related RFCs that would need lock-step maintenance and > corrections. > Another approach might be to roll the corrections into the Draft > Standard version of SIP 2.0. > > 4) RAI Policies WG: We have these ongoing, not-quite-committed work > items like session policies, use of SAML, etc. that we've > never been > able to get fully wrapped up. I suspect they need their own > WG. Or we > need to decide that these things just aren't worth doing and stop > feeling guilty about not finishing. As it is, I don't have a good > feeling about SIP finishing them. > > 5) SIP Operations: I'd like to see SIPPING replaced with a "how to" > group possibly under the OPS banner. They could deal with all > the "how > do we do X with SIP" from other SDOs. When confronted by a need to > extend SIP to meet a given need, they could then BOF up a new WG to > deal with the required extension. > > We already have working groups looking at conferencing, peering, > telephony feature interop, provisioning, peer-to-peer, NAT traversal, > > Other things that might need WGs: SPIT? Identity and Reputation? > > I also suspect we need a couple of directorates that are not WGs to > act in an advisory capacity: > > 1) RAI Security Directorate: Focuses on security review and > architectural issues in RAI documents. > > 2) RAI Event Package Directorate: Reviews and approves new SIP event > packages > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 14:48:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FE23A6805; Mon, 23 Jun 2008 14:48:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F3C3A6805 for ; Mon, 23 Jun 2008 14:48:28 -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 1Q+zrfFsmoQk for ; Mon, 23 Jun 2008 14:48:27 -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 D785C3A6A66 for ; Mon, 23 Jun 2008 14:48:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,692,1204531200"; d="scan'208";a="117323267" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2008 14:48:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5NLmO7w005284; Mon, 23 Jun 2008 14:48:24 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5NLmN1U026940; Mon, 23 Jun 2008 21:48:23 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Hadriel Kaplan'" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> Date: Mon, 23 Jun 2008 14:48:23 -0700 Message-ID: <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjVd00Eu5N8KFfbSbWxzCG0QqfVhAAA2DSQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=416; t=1214257704; x=1215121704; c=relaxed/simple; s=sjdkim4002; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=KXuh0bA7fRkqlbxqhRcjzf5RhdpP7WgqXKa7qzeAPBk=; b=ZLO5UYfAHlIngytlqzQmpGg8umY+uGg7XdVlL/8T4HQsa4ZZIZGmFfK5YQ ZEEgS5kQdhLcJtJAkycEPSxTAPZrhH3/87NHa8ewWDY8aSB9slvQLDZICXrq 8FB1zmCQ+f; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > draft-ietf-sip-saml > -- I'm not sure this one is ever getting done. > > So I'm not sure there's enough there to justify a WG. > > How about an "Identity in SIP" working group that takes on > fixing RFC 4474 for gateways/b2buas and possibly considers > identity/role assertion using SAML? I agree we need that. I have tried, and so far failed, to initiate activity towards such an effort. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 18:56:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7167C3A67B2; Mon, 23 Jun 2008 18:56:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F913A67A7 for ; Mon, 23 Jun 2008 18:56:56 -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 i62-UB2jJVfb for ; Mon, 23 Jun 2008 18:56:55 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 168953A679C for ; Mon, 23 Jun 2008 18:56:54 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA04.westchester.pa.mail.comcast.net with comcast id hZP31Z02m0ldTLk540BS00; Tue, 24 Jun 2008 01:56:54 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA04.westchester.pa.mail.comcast.net with comcast id hdwl1Z00202AVH03QdwljT; Tue, 24 Jun 2008 01:56:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=WPCZQANMUbwA:10 a=-TzPRHrdgPoA:10 a=zcYrrREFRHKb7LJLf0QA:9 a=OQYRGHWJqWlafU8x_SAA:7 a=P5kj-NpdQCgNvMVyqtQq1OXTK4gA:4 a=f7GxY0FH8QIA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m5O1uiQh031842 for ; Mon, 23 Jun 2008 21:56:44 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m5O1ug5l031833; Mon, 23 Jun 2008 21:56:42 -0400 Date: Fri, 20 Jun 2008 18:37:38 -0400 Message-Id: <200806202237.m5KMbcuk008312@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (christer.holmberg@ericsson.com) References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Christer Holmberg" [CHH] Whether the text should be in the document at all depends on if we allow 199 to be sent reliably in the first place. Based on the comments received so far we should not mandate 199 to be sent reliably, even if 100rel is required by the UAC. But, the question if whether we want to FORBID sending it reliably. If we ever might allow 199 to be used for HERFP, we should admit the possibility of sending it reliably in the first draft. Otherwise, we'll be locked out of sending it reliably in the future. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 23 19:01:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F263A67A7; Mon, 23 Jun 2008 19:01:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1AF3A67A7 for ; Mon, 23 Jun 2008 19:01:12 -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 pbs0t7MqGum0 for ; Mon, 23 Jun 2008 19:01:11 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B1E233A679C for ; Mon, 23 Jun 2008 19:01:11 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5O20tiY011936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2008 21:00:56 -0500 Message-Id: From: Dean Willis To: Dan Wing In-Reply-To: <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 21:00:49 -0500 References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 23, 2008, at 4:48 PM, Dan Wing wrote: >>> draft-ietf-sip-saml >> -- I'm not sure this one is ever getting done. >> >> So I'm not sure there's enough there to justify a WG. >> >> How about an "Identity in SIP" working group that takes on >> fixing RFC 4474 for gateways/b2buas and possibly considers >> identity/role assertion using SAML? > > I agree we need that. I have tried, and so far failed, to > initiate activity towards such an effort. > What do you think of a charter of that size, instead of a "All of SIP security, forever and ever" as a charter? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.schulz@guldplace.de Mon Jun 23 19:17:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED173A676A; Mon, 23 Jun 2008 19:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.224 X-Spam-Level: X-Spam-Status: No, score=-56.224 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 mmsEUX+KXqOY; Mon, 23 Jun 2008 19:17:50 -0700 (PDT) Received: from 190-82-183-173.adsl.tie.cl (190-82-183-173.adsl.tie.cl [190.82.183.173]) by core3.amsl.com (Postfix) with SMTP id 73B7E3A67B2; Mon, 23 Jun 2008 19:17:41 -0700 (PDT) X-Originating-IP: 96.98.128.193 by smtp.190.82.183.173; Mon, 23 Jun 2008 22:17:43 -0500 Message-ID: From: "Irving Colbert" Reply-To: "Irving Colbert" To: send-archive@ietf.org Subject: Spring quality watches offer Date: Mon, 23 Jun 2008 22:17:43 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://gasupizykex03.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://gasupizykex03.blogspot.com/ From c.garratt@ukfelder.co.uk Mon Jun 23 19:28:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149883A679C; Mon, 23 Jun 2008 19:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.675 X-Spam-Level: X-Spam-Status: No, score=-80.675 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, 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 2YhxQO6t6HLW; Mon, 23 Jun 2008 19:28:12 -0700 (PDT) Received: from pc-55-116-44-190.cm.vtr.net (pc-55-116-44-190.cm.vtr.net [190.44.116.55]) by core3.amsl.com (Postfix) with SMTP id 812F03A68EF; Mon, 23 Jun 2008 19:27:56 -0700 (PDT) X-Originating-IP: 210.45.192.160 by smtp.190.44.116.55; Mon, 23 Jun 2008 22:27:58 -0500 Message-ID: From: "Francisco Sneed" Reply-To: "Francisco Sneed" To: send-archive@ietf.org Subject: Elegant watches for less than half Date: Mon, 23 Jun 2008 22:27:58 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://kihocububaw63.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://kihocububaw63.blogspot.com/ From sip-bounces@ietf.org Mon Jun 23 21:48:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5053A680E; Mon, 23 Jun 2008 21:48:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DC83A67D7 for ; Mon, 23 Jun 2008 21:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.195 X-Spam-Level: *** X-Spam-Status: No, score=3.195 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_STATIC=1.172, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, 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 6WQP8Bb16YtP for ; Mon, 23 Jun 2008 21:48:33 -0700 (PDT) Received: from mail.urlsoftware.net (b2.6.5d45.static.theplanet.com [69.93.6.178]) by core3.amsl.com (Postfix) with ESMTP id 3058F3A680E for ; Mon, 23 Jun 2008 21:48:32 -0700 (PDT) Received: from matrixindia ([220.226.174.66]) by mail.urlsoftware.net (Merak 8.0.3) with ASMTP id TT182176; Mon, 23 Jun 2008 23:48:35 -0500 Received: from 192.168.50.25 by matrixindia ([192.168.50.100] running VPOP3) with ESMTP for ; Tue, 24 Jun 2008 10:18:33 +0530 From: "Dharmesh desai" To: Date: Mon, 23 Jun 2008 21:48:23 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcjVtYhXrlJ9iulNTIusmKDr4Yq2sQ== Message-Id: X-Server: VPOP3 V1.4.0e - Registered to: Matrix India X-Cyberoam-Version: 9.5.0.29 X-Cyberoam-smtpxy-version: 0.0.2.8 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: None Subject: [Sip] outbound proxy working with ohter servers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195044104==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1195044104== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8D57A.DC395390" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C8D57A.DC395390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, Currently I am developing IP-pbx. Can any one suggest how out bound proxy works with different servers? How out bound proxy communicate with registrar server, b2bua? Any free outbound proxy available so, I get proper idea of its working. Regards, Dharmesh Desai ------=_NextPart_000_0005_01C8D57A.DC395390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Currently I am developing = IP-pbx.

Can any one suggest how out bound proxy works with = different servers?

How out bound proxy communicate with registrar = server, b2bua?

Any free outbound proxy available so, I get proper = idea of its working.

 

Regards,

Dharmesh Desai

------=_NextPart_000_0005_01C8D57A.DC395390-- --===============1195044104== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1195044104==-- From sip-bounces@ietf.org Mon Jun 23 22:47:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CB93A6836; Mon, 23 Jun 2008 22:47:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD203A6836 for ; Mon, 23 Jun 2008 22:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnroaGT5R8e6 for ; Mon, 23 Jun 2008 22:47:13 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id EE1973A63CB for ; Mon, 23 Jun 2008 22:47:12 -0700 (PDT) X-AuditID: cb5bdd57-a89c8bb000000d32-bf-48608a58b302 Received: from blr-ec-aa03.wipro.com (unknown [10.201.18.42]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id 501FB4E4002 for ; Tue, 24 Jun 2008 11:17:04 +0530 (IST) Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 11:16:37 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 11:16:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 11:16:33 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE070441BA@BLR-EC-MBX02.wipro.com> In-Reply-To: <485FC635.7070309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjVSLqEkCQsWVfKQjeX/sIcSLwNwgAbgFgQ References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> <485FC635.7070309@cisco.com> From: To: , X-OriginalArrivalTime: 24 Jun 2008 05:46:36.0870 (UTC) FILETIME=[AAA78660:01C8D5BD] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just combining both the discussions here. ----------------------------------------- pkyzivat@cisco.com wrote >If the call has been forked, and provisional responses with multiple to-tags have been sent back to the UAC, then it is certain that the UAC has >*some* resources tied up with each early dialog. The 199 will allow some of that to be released. >Are you suggesting that the UAC indicate if it considers those resources to be sufficient to justify processing an extra message? Or maybe you >are just concerned with the likelihood that the UAC doesn't support 199, so that the message will just be ignored in any case? > I could go either way on this one. > Paul pkyzivat@cisco.com wrote > Right - Require is inappropriate. Supported is certainly possible. I think it would simply mean that the UAC understands the significance of > 199 and so is prepared to take advantage of it if received. I see no reason why you would change it on a call by call basis. The resources aren't > committed at the time of the INVITE - rather at the time the provisional response is received, so doing on a per-call basis wouldn't make much > > sense. [Ashish Saxena] I am concerned about both (justify processing of an extra message & UAC does not support 199). I brought up this discussion with the assumption that UAC (mostly) is in better situation to understand about resources reserved at its end. But Christer pointed out that even intermediate entities may also be interested in releasing resources asap. So if an entity knows that it has reserved resources and would appreciate if they can be relinquished earlier, then it can simply put "Supported" header to indicate entities downstream that it can handle 199. This is why I was suggesting it to be call by call basis. But with Paul's reasoning, it will be good to have for all calls. It is easier to implement also. (otherwise UAC will have to put extra intelligence to calculate whether it needs 199 in this call). IMO, Supported header will > a) Will stop proxies sending 199 because they would already know that UAC does not understand it anyways. b) Reduce some 199s on network because of (a). Best Regards, Ashish Saxena -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, June 23, 2008 9:20 PM To: Christer Holmberg Cc: Avasarala Ranjit-A20990; Ashish Saxena (WT01 - Telecom Equipment); sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Right - Require is inappropriate. Supported is certainly possible. I think it would simply mean that the UAC understands the significance of 199 and so is prepared to take advantage of it if received. I see no reason why you would change it on a call by call basis. The resources aren't committed at the time of the INVITE - rather at the time the provisional response is received, so doing on a per-call basis wouldn't make much sense. Paul Christer Holmberg wrote: > Hi, > >> Can we use Require:199 to indicate to proxy to send 199? > > No. The Require header is only applicaple to a UAS. > > You can use Proxy-Require for proxies, but the problem is that you would > require this from EVERY proxy in the path. > > Regards, > > Christer > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > ashish.hsaxena@wipro.com > Sent: Monday, June 23, 2008 10:24 AM > To: ashish.hsaxena@wipro.com; christer.holmberg@ericsson.com > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > > Probably everybody is busy. Any thoughts on this one. > > > Best Regards, > Ashish Saxena > 877-5570 > > -----Original Message----- > From: Ashish Saxena (WT01 - Telecom Equipment) > Sent: Friday, June 20, 2008 10:56 AM > To: christer.holmberg@ericsson.com > Cc: sip@ietf.org > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > Hi Christer, > From Section 4 (Client Behaviour) part of this draft, I > understood that primary objective of this draft is to give indication to > UAC to release resources, if any. I am little worried about extra > messaging that will be seen because of 199 implementation. Can there be > a way to tell proxies and UAS downstream that UAC has some resources > reserved for this call and would be interested in receiving 199, if > possible? > > IMO, UAC (mostly) is in better understanding of the resources that it > has reserved for a particular call. So UAC can selectively add something > in INVITE to tell downstream proxies/ UAS' about its interest. > > IMO, we can have a package for 199 and UAC can use "Supported" header to > indicate entities downstream that it would be interested in getting 199 > for this *particular* call. Implicitly it would mean that UAC has > reserved some resources. I understand that we would changing the meaning > of "Supported" header on per call basis :-(. Something else may be? > > Comments please. > > Best Regards, > Ashish Saxena > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 00:12:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0DD3A68B0; Tue, 24 Jun 2008 00:12:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0583B3A6836 for ; Tue, 24 Jun 2008 00:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 lCUdkauiRBmK for ; Tue, 24 Jun 2008 00:12:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2EB473A68DC for ; Tue, 24 Jun 2008 00:12:31 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B8CCB20701; Tue, 24 Jun 2008 09:12:29 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-94-48609e5dd300 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8A79420422; Tue, 24 Jun 2008 09:12:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:12:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 09:12:54 +0200 Message-ID: In-Reply-To: <01949ABCDD38EF4A95B8C347C399D1CE070441BA@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjVSLqEkCQsWVfKQjeX/sIcSLwNwgAbgFgQAASahtA= References: <200806130255.m5D2t0gC031044@dragon.ariadne.com><200806182301.m5IN1Ofk022192@dragon.ariadne.com> <01949ABCDD38EF4A95B8C347C399D1CE07043962@BLR-EC-MBX02.wipro.com> <750BBC72E178114F9DC4872EBFF29A5B057BB8DD@ZMY16EXM66.ds.mot.com> <485FC635.7070309@cisco.com> <01949ABCDD38EF4A95B8C347C399D1CE070441BA@BLR-EC-MBX02.wipro.com> From: "Christer Holmberg" To: , X-OriginalArrivalTime: 24 Jun 2008 07:12:56.0074 (UTC) FILETIME=[B9B356A0:01C8D5C9] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >Just combining both the discussions here. >----------------------------------------- > >pkyzivat@cisco.com wrote >>If the call has been forked, and provisional responses with multiple >>to-tags have been sent back to the UAC, then it is certain that the UAC has *some* resources tied up with each early >>dialog. The 199 will allow some of that to be released. >> >>Are you suggesting that the UAC indicate if it considers those >>resources to be sufficient to justify processing an extra message? Or >>maybe you are just concerned with the likelihood that the UAC doesn't >>support 199, so that the message will just be ignored in any case? >> >> I could go either way on this one. >> >> Paul >> >pkyzivat@cisco.com wrote >>Right - Require is inappropriate. Supported is certainly possible. I >>think it would simply mean that the UAC understands the significance of >>199 and so is prepared to take advantage of it if received. I see no >>reason why you would change it on a call by call basis. The resources aren't committed at the time of the INVITE - >>rather at the time the provisional response is received, so doing on a per-call basis wouldn't make much > > sense. > > >[Ashish Saxena] I am concerned about both (justify processing of an extra message & UAC does not support 199). I brought >up this discussion with the assumption that UAC (mostly) is in better situation to understand about resources reserved at >its end. But Christer pointed out that even intermediate entities may also be interested in releasing resources asap. So >if an entity knows that it has reserved resources and would appreciate if they can be relinquished earlier, then it can >simply put "Supported" header to indicate entities downstream that it can handle 199. This is why I was suggesting it to >be call by call basis. [CHH] Sure, if it's ok to say that an intermediate can add an option-tag to the Supported header. >But with Paul's reasoning, it will be good to have for all calls. It is easier to implement also. (otherwise UAC will >have to put extra intelligence to calculate whether it needs 199 in this call). > > IMO, Supported header will > > a) Will stop proxies sending 199 because they would already know that UAC does not understand it anyways. If an intermediate inserts the option-tag in the Supported header the UAC would of course still get the 199. > b) Reduce some 199s on network because of (a). [CHH] I don't have any strong feelings whether we define an option-tag or not. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, June 23, 2008 9:20 PM To: Christer Holmberg Cc: Avasarala Ranjit-A20990; Ashish Saxena (WT01 - Telecom Equipment); sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Right - Require is inappropriate. Supported is certainly possible. I think it would simply mean that the UAC understands the significance of 199 and so is prepared to take advantage of it if received. I see no reason why you would change it on a call by call basis. The resources aren't committed at the time of the INVITE - rather at the time the provisional response is received, so doing on a per-call basis wouldn't make much sense. Paul Christer Holmberg wrote: > Hi, > >> Can we use Require:199 to indicate to proxy to send 199? > > No. The Require header is only applicaple to a UAS. > > You can use Proxy-Require for proxies, but the problem is that you would > require this from EVERY proxy in the path. > > Regards, > > Christer > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > ashish.hsaxena@wipro.com > Sent: Monday, June 23, 2008 10:24 AM > To: ashish.hsaxena@wipro.com; christer.holmberg@ericsson.com > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > > Probably everybody is busy. Any thoughts on this one. > > > Best Regards, > Ashish Saxena > 877-5570 > > -----Original Message----- > From: Ashish Saxena (WT01 - Telecom Equipment) > Sent: Friday, June 20, 2008 10:56 AM > To: christer.holmberg@ericsson.com > Cc: sip@ietf.org > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > Hi Christer, > From Section 4 (Client Behaviour) part of this draft, I understood > that primary objective of this draft is to give indication to > UAC to release resources, if any. I am little worried about extra > messaging that will be seen because of 199 implementation. Can there be > a way to tell proxies and UAS downstream that UAC has some resources > reserved for this call and would be interested in receiving 199, if > possible? > > IMO, UAC (mostly) is in better understanding of the resources that it > has reserved for a particular call. So UAC can selectively add something > in INVITE to tell downstream proxies/ UAS' about its interest. > > IMO, we can have a package for 199 and UAC can use "Supported" header to > indicate entities downstream that it would be interested in getting 199 > for this *particular* call. Implicitly it would mean that UAC has > reserved some resources. I understand that we would changing the meaning > of "Supported" header on per call basis :-(. Something else may be? > > Comments please. > > Best Regards, > Ashish Saxena > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 00:15:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2773A6959; Tue, 24 Jun 2008 00:15:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA243A6959 for ; Tue, 24 Jun 2008 00:15:15 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI-V1LhsFqq2 for ; Tue, 24 Jun 2008 00:15:14 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 78FC63A68E7 for ; Tue, 24 Jun 2008 00:15:14 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K2Y0061NHHEGY@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Jun 2008 08:15:14 +0100 (BST) Date: Tue, 24 Jun 2008 08:15:12 +0100 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , "DRAGE, Keith (Keith)" , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, Concerning your "PBX connections a la SIP trunks" use case, I am not convinced of this. ETSI TISPAN has specified two ways for an IPPBX to connect to a service provider. One is the so-called subscription-based approach, where the IPPBX registers with the SP and communicates via an edge proxy. In this case, why not use SIP-outbound? The other is the so-called peering-based approach, which is essentially the same as any SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway. SIP-outbound does not apply to these situations, and similarly the keep-alive mechanism is not specified for this cases. The requirements in SIP-keep do not cover these situations. Basically I am not sold on the idea of a separate SIP-keep spec - I don't think it would be the best use of WG time. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 20 June 2008 18:20 > To: DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > My 2 cents: it is a useful draft. Personally, I would like > to have it available for two reasons not cited: PBX > connections a la SIP trunks, and proxy-proxy connections. > Today I think a lot of people are using OPTIONS requests or > proprietary means to perform such keep-alives when > registration is not appropriate, but it has led to some > interop issues and performance concerns in some cases. > > Since the contentious issue of what form the keep-alives take > have already been agreed on for outbound, this seems like a > simple draft to get done. (famous last words, I know) > > -hadriel > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Thursday, June 19, 2008 5:31 AM > > To: sip@ietf.org > > Cc: Christer Holmberg > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > (As SIP WG cochair) > > > > We have been asked by the author of > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > Whether the SIP WG can progress this document. > > > > Because this draft arose as a result of the discussion of > outbound, and > > indeed seems to reuse the requirements from outbound, and these > > requirements never really got handled in the SIPPING WG, it has been > > agreed with the SIPPING chairs that we will handle this > entirely within > > SIP. > > > > Now in order to ask for charter milestones, and indeed when > we finally > > present this to IESG, we will be asked for the level of > support in the > > WG, which is also predicated on does this fix a real > problem, or is it > > just a corner case with limited application. So: > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to > > proceed with this draft? The document states: > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > > defines two keep-alive techniques. Even though the keep-alive > > techniques are separated from the Outbound mechanism > > [I-D.ietf-sip-outbound], it is currently not possible to indicate > > support of the keep-alive techniques without also > indicating support > > for the Outbound mechanism. > > > > The Outbound mechanism is enabled during the UA > registration phase. > > However, there are use-cases where the UA does not > register itself, > > but still needs to be able to make calls and maintain > NAT bindings > > open during the duration of that call. A typical example is > > emergency calls. There are also cases where entities do > not support > > the Outbound mechanism, but still want to be able to > indicate support > > and use the keep-alive techniques defined in > [I-D.ietf-sip-outbound]. > > > > At first sight this is not the most inspiring declaration > of the need > > for the document. Please respond indicating whether you > consider this a > > useful draft, and propose text that you think would be > useful in this > > section. Conversely, if you think this draft is not useful > and the WG > > has other more important things to work on first, please > also respond. > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for > > proceeding with this work? The document currently lists: > > > > REQ 1: It MUST be possible for a UA to indicate support > of the keep- > > alive techniques defined [I-D.ietf-sip-outbound] if the > UA supports > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > REQ 2: It MUST be possible for an edge proxy to indicate > support of > > the keep-alive techniques defined > [I-D.ietf-sip-outbound] if the edge > > poxy supports only the keep-alive part of > [I-D.ietf-sip-outbound]. > > > > It would be desirable to agree these at the outset, and not > revisit them > > if we continue with the work. So if you require clarification, > > modification, or addition to these two requirements, then > please also > > response with your questions and proposals. > > > > I suggest we would like responses by 30th June 2008 in > order to allow > > the author to revise the document before the deadlines. > Please note that > > we are looking to make this decision on the list within > this deadline > > based on responses received, not leave it until the Dublin meeting. > > > > Regards > > > > Keith > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 00:16:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078923A6929; Tue, 24 Jun 2008 00:16:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955003A6929 for ; Tue, 24 Jun 2008 00:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 vQk1XPbhxriZ for ; Tue, 24 Jun 2008 00:16:18 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A42B23A6836 for ; Tue, 24 Jun 2008 00:16:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 30CAA20C28; Tue, 24 Jun 2008 09:16:18 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-59-48609f414c99 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8ED8D20C16; Tue, 24 Jun 2008 09:16:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:16:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 09:16:37 +0200 Message-ID: In-Reply-To: <200806202237.m5KMbcuk008312@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjVnbJKnsNhES+5S0Cf5sumMB7huwALE1PA References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> From: "Christer Holmberg" To: , X-OriginalArrivalTime: 24 Jun 2008 07:16:38.0293 (UTC) FILETIME=[3E274450:01C8D5CA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I agree it may be a good idea to not forbid sending it reliably. I do think it would be good to have text, saying that it can be sent unreli= able even if reliable responses are required, though, so that proxies aren'= t forced to terminate PRACKs etc. Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dale.= Worley@comcast.net Sent: 21. kes=E4kuuta 2008 1:38 To: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 From: "Christer Holmberg" [CHH] Whether the text should be in the document at all depends on if we allow 199 to be sent reliably in the first place. Based on the comments received so far we should not mandate 199 to be sent reliably, even if 100rel is required by the UAC. But, the question if whether we want to FORBID sending it reliably. If we ever might allow 199 to be used for HERFP, we should admit the possib= ility of sending it reliably in the first draft. Otherwise, we'll be locke= d out of sending it reliably in the future. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 00:19:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B8E3A699A; Tue, 24 Jun 2008 00:19:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB8E3A699A for ; Tue, 24 Jun 2008 00:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 CmFePH3zLlL7 for ; Tue, 24 Jun 2008 00:19:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4DD7E3A6836 for ; Tue, 24 Jun 2008 00:19:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB31320C17; Tue, 24 Jun 2008 09:19:28 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-21-4860a0008168 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 93CA020AE1; Tue, 24 Jun 2008 09:19:28 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:19:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 09:19:54 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep thread-index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAAGxb4A== References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Hadriel Kaplan" , "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 24 Jun 2008 07:19:55.0097 (UTC) FILETIME=[B3752C90:01C8D5CA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi John, SIP-keep CAN be used proxy-to-proxy, B2BUA-to-B2BUA etc. ANY entity (e.g. a= proxy) can insert the keep parameter in its Via header, and if the next en= tity adds a "yes" value the "keep-alives" can be used between those entitie= s. Regards, Christer = -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] = Sent: 24. kes=E4kuuta 2008 10:15 To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org Cc: Christer Holmberg Subject: RE: [Sip] Progress draft-holmberg-sip-keep Hadriel, Concerning your "PBX connections a la SIP trunks" use case, I am not convin= ced of this. ETSI TISPAN has specified two ways for an IPPBX to connect to = a service provider. One is the so-called subscription-based approach, where= the IPPBX registers with the SP and communicates via an edge proxy. In thi= s case, why not use SIP-outbound? The other is the so-called peering-based = approach, which is essentially the same as any SIP "trunk", e.g., proxy-to-= proxy, B2BUA-to-B2BUA, proxy-to-gateway. SIP-outbound does not apply to these situations, and similarly the keep-ali= ve mechanism is not specified for this cases. The requirements in SIP-keep = do not cover these situations. Basically I am not sold on the idea of a separate SIP-keep spec - I don't t= hink it would be the best use of WG time. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = > Hadriel Kaplan > Sent: 20 June 2008 18:20 > To: DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > = > = > My 2 cents: it is a useful draft. Personally, I would like to have it = > available for two reasons not cited: PBX connections a la SIP trunks, = > and proxy-proxy connections. > Today I think a lot of people are using OPTIONS requests or = > proprietary means to perform such keep-alives when registration is not = > appropriate, but it has led to some interop issues and performance = > concerns in some cases. > = > Since the contentious issue of what form the keep-alives take have = > already been agreed on for outbound, this seems like a simple draft to = > get done. (famous last words, I know) > = > -hadriel > = > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Thursday, June 19, 2008 5:31 AM > > To: sip@ietf.org > > Cc: Christer Holmberg > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > (As SIP WG cochair) > > > > We have been asked by the author of > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > Whether the SIP WG can progress this document. > > > > Because this draft arose as a result of the discussion of > outbound, and > > indeed seems to reuse the requirements from outbound, and these = > > requirements never really got handled in the SIPPING WG, it has been = > > agreed with the SIPPING chairs that we will handle this > entirely within > > SIP. > > > > Now in order to ask for charter milestones, and indeed when > we finally > > present this to IESG, we will be asked for the level of > support in the > > WG, which is also predicated on does this fix a real > problem, or is it > > just a corner case with limited application. So: > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to = > > proceed with this draft? The document states: > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > > defines two keep-alive techniques. Even though the keep-alive > > techniques are separated from the Outbound mechanism > > [I-D.ietf-sip-outbound], it is currently not possible to indicate > > support of the keep-alive techniques without also > indicating support > > for the Outbound mechanism. > > > > The Outbound mechanism is enabled during the UA > registration phase. > > However, there are use-cases where the UA does not > register itself, > > but still needs to be able to make calls and maintain > NAT bindings > > open during the duration of that call. A typical example is > > emergency calls. There are also cases where entities do > not support > > the Outbound mechanism, but still want to be able to > indicate support > > and use the keep-alive techniques defined in > [I-D.ietf-sip-outbound]. > > > > At first sight this is not the most inspiring declaration > of the need > > for the document. Please respond indicating whether you > consider this a > > useful draft, and propose text that you think would be > useful in this > > section. Conversely, if you think this draft is not useful > and the WG > > has other more important things to work on first, please > also respond. > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for = > > proceeding with this work? The document currently lists: > > > > REQ 1: It MUST be possible for a UA to indicate support > of the keep- > > alive techniques defined [I-D.ietf-sip-outbound] if the > UA supports > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > REQ 2: It MUST be possible for an edge proxy to indicate > support of > > the keep-alive techniques defined > [I-D.ietf-sip-outbound] if the edge > > poxy supports only the keep-alive part of > [I-D.ietf-sip-outbound]. > > > > It would be desirable to agree these at the outset, and not > revisit them > > if we continue with the work. So if you require clarification, = > > modification, or addition to these two requirements, then > please also > > response with your questions and proposals. > > > > I suggest we would like responses by 30th June 2008 in > order to allow > > the author to revise the document before the deadlines. = > Please note that > > we are looking to make this decision on the list within > this deadline > > based on responses received, not leave it until the Dublin meeting. > > > > Regards > > > > Keith > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use = > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 00:38:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1CD3A68A8; Tue, 24 Jun 2008 00:38:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CCA3A6808 for ; Tue, 24 Jun 2008 00:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGRqinXYlCXd for ; Tue, 24 Jun 2008 00:38:10 -0700 (PDT) Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by core3.amsl.com (Postfix) with ESMTP id F1B243A68A8 for ; Tue, 24 Jun 2008 00:38:09 -0700 (PDT) Received: (qmail 21068 invoked by uid 0); 24 Jun 2008 07:38:08 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 Jun 2008 07:38:08 -0000 Message-ID: <4860A45F.9020001@zonnet.nl> Date: Tue, 24 Jun 2008 09:38:07 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> In-Reply-To: Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer, Should the 199 response contain a Contact header? And if yes, in case a = proxy sends it, should it contain the address of that proxy (since the = UAS already sent a final response)? Should we say that a proxy may only generate and send a 199 when it = receives a final error response on an INVITE client Transaction which = was in the PROCEEDING state? (i.e. 1xx response was received before, so = conceptually sending the 199 response is an action associated with the = transition from PROCEEDING to COMPLETED) Regards, Jeroen Christer Holmberg wrote: > Hi, > > I agree it may be a good idea to not forbid sending it reliably. > > I do think it would be good to have text, saying that it can be sent unre= liable even if reliable responses are required, though, so that proxies are= n't forced to terminate PRACKs etc. > > Regards, > > Christer > = > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dal= e.Worley@comcast.net > Sent: 21. kes=E4kuuta 2008 1:38 > To: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > From: "Christer Holmberg" > > [CHH] Whether the text should be in the document at all depends on if = we > allow 199 to be sent reliably in the first place. Based on the comments > received so far we should not mandate 199 to be sent reliably, even if > 100rel is required by the UAC. But, the question if whether we want to > FORBID sending it reliably. > > If we ever might allow 199 to be used for HERFP, we should admit the poss= ibility of sending it reliably in the first draft. Otherwise, we'll be loc= ked out of sending it reliably in the future. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use sip-impleme= ntors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for= new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 00:56:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A4B3A6836; Tue, 24 Jun 2008 00:56:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC153A6836 for ; Tue, 24 Jun 2008 00:56:26 -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 D5ecZUJtb-Qh for ; Tue, 24 Jun 2008 00:56:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7C4FE3A6813 for ; Tue, 24 Jun 2008 00:56:25 -0700 (PDT) Received: (qmail invoked by alias); 24 Jun 2008 07:56:25 -0000 Received: from unknown (EHLO [10.183.181.66]) [192.100.124.156] by mail.gmx.net (mp028) with SMTP; 24 Jun 2008 09:56:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+8oRcEXIO8qcMgn6NMlwARc/4MZ/mYCclaOZ9ow8 KjZPnQAc220mvi Message-ID: <4860A8A5.1010605@gmx.net> Date: Tue, 24 Jun 2008 10:56:21 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dan Wing References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com> <08d301c8d57a$9762f370$c2f0200a@cisco.com> In-Reply-To: <08d301c8d57a$9762f370$c2f0200a@cisco.com> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, 'Dean Willis' Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > In a standards organization, 'success' is defined as > finishing something. Maybe the success criteria should not just to produce documents but to produce something that actually sees deployment. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 01:04:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDEE28C0D9; Tue, 24 Jun 2008 01:04:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5743A69A9 for ; Tue, 24 Jun 2008 01:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 M9B3EGTsWkC0 for ; Tue, 24 Jun 2008 01:04:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C06F73A69B2 for ; Tue, 24 Jun 2008 01:04:40 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7763D20974; Tue, 24 Jun 2008 10:04:40 +0200 (CEST) X-AuditID: c1b4fb3c-ac898bb00000193b-0e-4860aa984f53 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4A3AA20598; Tue, 24 Jun 2008 10:04:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 10:05:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 10:05:05 +0200 Message-ID: In-Reply-To: <4860A45F.9020001@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjVzVAff/e6cu9eQtqKXuNvjemhiQAA0acA References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> <4860A45F.9020001@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" X-OriginalArrivalTime: 24 Jun 2008 08:05:06.0795 (UTC) FILETIME=[03C173B0:01C8D5D1] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, = >Should the 199 response contain a Contact header? And if yes, in case a pr= oxy sends it, should it contain the address of = >that proxy (since the UAS already sent a final response)? IF the 199 is sent reliably be the proxy must contain a Contact header cont= aining the address of the proxy, yes. >Should we say that a proxy may only generate and send a 199 when it receiv= es a final error response on an INVITE client = >Transaction which was in the PROCEEDING state? (i.e. 1xx response was rece= ived before, so conceptually sending the 199 = >response is an action associated with the transition from PROCEEDING to CO= MPLETED) I am not sure I understand. The idea IS to send 199 when a final error resp= onse is received by the forking proxy, if a 18x has previously been receive= d. Regards, Christer Christer Holmberg wrote: > Hi, > > I agree it may be a good idea to not forbid sending it reliably. > > I do think it would be good to have text, saying that it can be sent unre= liable even if reliable responses are required, though, so that proxies are= n't forced to terminate PRACKs etc. > > Regards, > > Christer > = > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = > Dale.Worley@comcast.net > Sent: 21. kes=E4kuuta 2008 1:38 > To: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > From: "Christer Holmberg" > > [CHH] Whether the text should be in the document at all depends on if = we > allow 199 to be sent reliably in the first place. Based on the comments > received so far we should not mandate 199 to be sent reliably, even if > 100rel is required by the UAC. But, the question if whether we want to > FORBID sending it reliably. > > If we ever might allow 199 to be used for HERFP, we should admit the poss= ibility of sending it reliably in the first draft. Otherwise, we'll be loc= ked out of sending it reliably in the future. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 01:17:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A379F3A6886; Tue, 24 Jun 2008 01:17:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661B63A68A2 for ; Tue, 24 Jun 2008 01:17:14 -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 hjpO+jfzME3I for ; Tue, 24 Jun 2008 01:17:13 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DF50E3A6886 for ; Tue, 24 Jun 2008 01:17:12 -0700 (PDT) Received: (qmail invoked by alias); 24 Jun 2008 08:17:11 -0000 Received: from unknown (EHLO [10.183.181.66]) [192.100.124.156] by mail.gmx.net (mp056) with SMTP; 24 Jun 2008 10:17:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+4UTU3Uvy4DRbIfpKAMyypU7NaVIrJ3g3ItZ7pBl 2KuHi0EwkQTwQs Message-ID: <4860AD84.60004@gmx.net> Date: Tue, 24 Jun 2008 11:17:08 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dan Wing References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> In-Reply-To: <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, 'Paul Kyzivat' , 'Dean Willis' Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Many of the SIP security mechanisms share the same fate: They are far ahead of the actual SIP deployment. This is true for SIP Identity, SIP CERT, SIP SAML, End-to-End Security, etc. When we started the SAML work we looked at what was going on at that time in the HTTP space. Without doubt the entire application layer identity management space found a lot of excitement. There is a lot of standardization being done and also a lot of deployment taking place. With the SIP space that was obviously a bit different and deployments today focus largely on voice (and there not even on end-to-end SIP-based communication). For example: Look at what is being used in XMPP. There is no equalivalent of SIP Identity -- folks are currently looking into providing certificates for server-to-server communication. Even though they are, from a deployment point of view, ahead they are not even close to where we are with our documents. Ciao Hannes PS: I also believe that the SIP Identity case isn't an easy one either. The guys that would make use of SIP Identity for a deployment where the two SIP proxies talk to each other there would not be a need for SIP Identity since you are essentially replicating what TLS provides you at a lower layer already. In cases where there many SIP proxies along the path SIP Identity would be useful since it provides protection against any one of them being malicious. However, the guys who favour such a deployment model are the onces that believe very much in the chain of trust (hop-by-hop security). They have no interest in using SIP Identity. Dan Wing wrote: >>> draft-ietf-sip-saml >>> >> -- I'm not sure this one is ever getting done. >> >> So I'm not sure there's enough there to justify a WG. >> >> How about an "Identity in SIP" working group that takes on >> fixing RFC 4474 for gateways/b2buas and possibly considers >> identity/role assertion using SAML? >> > > I agree we need that. I have tried, and so far failed, to > initiate activity towards such an effort. > > -d > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 03:05:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28A13A68CA; Tue, 24 Jun 2008 03:05:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789883A68CA for ; Tue, 24 Jun 2008 03:05:04 -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 ap-qahlNFjD8 for ; Tue, 24 Jun 2008 03:05:03 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id DB11D3A6896 for ; Tue, 24 Jun 2008 03:05:02 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K2Y00GC9PCC8J@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Jun 2008 11:05:00 +0100 (BST) Date: Tue, 24 Jun 2008 11:05:03 +0100 From: "Elwell, John" In-reply-to: A To: Christer Holmberg , Hadriel Kaplan , "DRAGE, Keith (Keith)" , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E039@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAAGxb4AAFgqpQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> A Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer, The majority of the specification talks about a UA as client and an edge pr= oxy as server. The only hint that it might be applied in other situations i= s in section 8 "Overlap with connection reuse", but there is no normative l= anguage there. So the scope clearly seems to be between a UA and an edge pr= oxy, and I don't see much value in that (i.e., might as well support sip-ou= tbound). If you wish to extend the scope so that it can operate between any two SIP = entities, and in particular between two proxies, then that is a different m= atter. There may be valid use cases, but I can't recall whether these have = been discussed. Will the same technical solution apply (e.g., in terms of w= hich side is the client, which side chooses the timer value, what is the de= fault timer value, etc.)? I think Keith's questions related to the present draft (01) and I interpret= the scope as UA to edge proxy only. If you wish to extend the scope, this = would require a revised draft before making any decision on adopting as a w= ork item. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] = > Sent: 24 June 2008 08:20 > To: Elwell, John; Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > = > = > Hi John, > = > SIP-keep CAN be used proxy-to-proxy, B2BUA-to-B2BUA etc. ANY = > entity (e.g. a proxy) can insert the keep parameter in its = > Via header, and if the next entity adds a "yes" value the = > "keep-alives" can be used between those entities. > = > Regards, > = > Christer > = > = > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] = > Sent: 24. kes=E4kuuta 2008 10:15 > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > = > Hadriel, > = > Concerning your "PBX connections a la SIP trunks" use case, I = > am not convinced of this. ETSI TISPAN has specified two ways = > for an IPPBX to connect to a service provider. One is the = > so-called subscription-based approach, where the IPPBX = > registers with the SP and communicates via an edge proxy. In = > this case, why not use SIP-outbound? The other is the = > so-called peering-based approach, which is essentially the = > same as any SIP "trunk", e.g., proxy-to-proxy, = > B2BUA-to-B2BUA, proxy-to-gateway. > SIP-outbound does not apply to these situations, and = > similarly the keep-alive mechanism is not specified for this = > cases. The requirements in SIP-keep do not cover these situations. > = > Basically I am not sold on the idea of a separate SIP-keep = > spec - I don't think it would be the best use of WG time. > = > John > = > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = > Behalf Of = > > Hadriel Kaplan > > Sent: 20 June 2008 18:20 > > To: DRAGE, Keith (Keith); sip@ietf.org > > Cc: Christer Holmberg > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > = > > = > > My 2 cents: it is a useful draft. Personally, I would like = > to have it = > > available for two reasons not cited: PBX connections a la = > SIP trunks, = > > and proxy-proxy connections. > > Today I think a lot of people are using OPTIONS requests or = > > proprietary means to perform such keep-alives when = > registration is not = > > appropriate, but it has led to some interop issues and performance = > > concerns in some cases. > > = > > Since the contentious issue of what form the keep-alives take have = > > already been agreed on for outbound, this seems like a = > simple draft to = > > get done. (famous last words, I know) > > = > > -hadriel > > = > > = > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > DRAGE, Keith (Keith) > > > Sent: Thursday, June 19, 2008 5:31 AM > > > To: sip@ietf.org > > > Cc: Christer Holmberg > > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > > > (As SIP WG cochair) > > > > > > We have been asked by the author of > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > Whether the SIP WG can progress this document. > > > > > > Because this draft arose as a result of the discussion of > > outbound, and > > > indeed seems to reuse the requirements from outbound, and these = > > > requirements never really got handled in the SIPPING WG, = > it has been = > > > agreed with the SIPPING chairs that we will handle this > > entirely within > > > SIP. > > > > > > Now in order to ask for charter milestones, and indeed when > > we finally > > > present this to IESG, we will be asked for the level of > > support in the > > > WG, which is also predicated on does this fix a real > > problem, or is it > > > just a corner case with limited application. So: > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to = > > > proceed with this draft? The document states: > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 = > [I-D.ietf-sip-outbound] > > > defines two keep-alive techniques. Even though the keep-alive > > > techniques are separated from the Outbound mechanism > > > [I-D.ietf-sip-outbound], it is currently not possible = > to indicate > > > support of the keep-alive techniques without also > > indicating support > > > for the Outbound mechanism. > > > > > > The Outbound mechanism is enabled during the UA > > registration phase. > > > However, there are use-cases where the UA does not > > register itself, > > > but still needs to be able to make calls and maintain > > NAT bindings > > > open during the duration of that call. A typical example is > > > emergency calls. There are also cases where entities do > > not support > > > the Outbound mechanism, but still want to be able to > > indicate support > > > and use the keep-alive techniques defined in > > [I-D.ietf-sip-outbound]. > > > > > > At first sight this is not the most inspiring declaration > > of the need > > > for the document. Please respond indicating whether you > > consider this a > > > useful draft, and propose text that you think would be > > useful in this > > > section. Conversely, if you think this draft is not useful > > and the WG > > > has other more important things to work on first, please > > also respond. > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for = > > > proceeding with this work? The document currently lists: > > > > > > REQ 1: It MUST be possible for a UA to indicate support > > of the keep- > > > alive techniques defined [I-D.ietf-sip-outbound] if the > > UA supports > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > REQ 2: It MUST be possible for an edge proxy to indicate > > support of > > > the keep-alive techniques defined > > [I-D.ietf-sip-outbound] if the edge > > > poxy supports only the keep-alive part of > > [I-D.ietf-sip-outbound]. > > > > > > It would be desirable to agree these at the outset, and not > > revisit them > > > if we continue with the work. So if you require clarification, = > > > modification, or addition to these two requirements, then > > please also > > > response with your questions and proposals. > > > > > > I suggest we would like responses by 30th June 2008 in > > order to allow > > > the author to revise the document before the deadlines. = > > Please note that > > > we are looking to make this decision on the list within > > this deadline > > > based on responses received, not leave it until the = > Dublin meeting. > > > > > > Regards > > > > > > Keith > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use = > > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use = > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > sipping@ietf.org for new developments on the application of sip > > = > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 03:14:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94563A69F4; Tue, 24 Jun 2008 03:14:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036D83A69F4 for ; Tue, 24 Jun 2008 03:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 KDehd9PMWJ0m for ; Tue, 24 Jun 2008 03:14:33 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1EC253A688A for ; Tue, 24 Jun 2008 03:14:33 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B8A9720CF2; Tue, 24 Jun 2008 12:14:32 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-5c-4860c908c7fb Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 930AB20C96; Tue, 24 Jun 2008 12:14:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 12:14:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 12:14:53 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E039@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep thread-index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAAGxb4AAFgqpQAAB+L4A= References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0D6E039@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Hadriel Kaplan" , "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 24 Jun 2008 10:14:54.0078 (UTC) FILETIME=[255689E0:01C8D5E3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, = >The majority of the specification talks about a UA as client and an edge p= roxy as server. The only hint that it might be = >applied in other situations is in section 8 "Overlap with connection reuse= ", but there is no normative language there. So = >the scope clearly seems to be between a UA and an edge proxy, and I don't = see much value in that (i.e., might as well = >support sip-outbound). Outbound can not always be used, as the draft says. It is true that initially the primary scope is between the UA and the edge = proxy. However, I am happy to add the proxy-to-proxy use-case, if people th= ink that is something we should do. >If you wish to extend the scope so that it can operate between any two SIP= entities, and in particular between two = >proxies, then that is a different matter. There may be valid use cases, bu= t I can't recall whether these have been = >discussed. Will the same technical solution apply (e.g., in terms of which= side is the client, which side chooses the = >timer value, what is the default timer value, etc.)? At the moment I see no reason why the same technical solution wouldn't appl= y. Regards, Christer I think Keith's questions related to the present draft (01) and I interpret= the scope as UA to edge proxy only. If you = wish to extend the scope, this would require a revised draft before making = any decision on adopting as a work item. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 24 June 2008 08:20 > To: Elwell, John; Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > = > = > Hi John, > = > SIP-keep CAN be used proxy-to-proxy, B2BUA-to-B2BUA etc. ANY entity = > (e.g. a proxy) can insert the keep parameter in its Via header, and if = > the next entity adds a "yes" value the "keep-alives" can be used = > between those entities. > = > Regards, > = > Christer > = > = > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 24. kes=E4kuuta 2008 10:15 > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > = > Hadriel, > = > Concerning your "PBX connections a la SIP trunks" use case, I am not = > convinced of this. ETSI TISPAN has specified two ways for an IPPBX to = > connect to a service provider. One is the so-called subscription-based = > approach, where the IPPBX registers with the SP and communicates via = > an edge proxy. In this case, why not use SIP-outbound? The other is = > the so-called peering-based approach, which is essentially the same as = > any SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, = > proxy-to-gateway. > SIP-outbound does not apply to these situations, and similarly the = > keep-alive mechanism is not specified for this cases. The requirements = > in SIP-keep do not cover these situations. > = > Basically I am not sold on the idea of a separate SIP-keep spec - I = > don't think it would be the best use of WG time. > = > John > = > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Hadriel Kaplan > > Sent: 20 June 2008 18:20 > > To: DRAGE, Keith (Keith); sip@ietf.org > > Cc: Christer Holmberg > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > = > > = > > My 2 cents: it is a useful draft. Personally, I would like > to have it > > available for two reasons not cited: PBX connections a la > SIP trunks, > > and proxy-proxy connections. > > Today I think a lot of people are using OPTIONS requests or = > > proprietary means to perform such keep-alives when > registration is not > > appropriate, but it has led to some interop issues and performance = > > concerns in some cases. > > = > > Since the contentious issue of what form the keep-alives take have = > > already been agreed on for outbound, this seems like a > simple draft to > > get done. (famous last words, I know) > > = > > -hadriel > > = > > = > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > DRAGE, Keith (Keith) > > > Sent: Thursday, June 19, 2008 5:31 AM > > > To: sip@ietf.org > > > Cc: Christer Holmberg > > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > > > (As SIP WG cochair) > > > > > > We have been asked by the author of > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > Whether the SIP WG can progress this document. > > > > > > Because this draft arose as a result of the discussion of > > outbound, and > > > indeed seems to reuse the requirements from outbound, and these = > > > requirements never really got handled in the SIPPING WG, > it has been > > > agreed with the SIPPING chairs that we will handle this > > entirely within > > > SIP. > > > > > > Now in order to ask for charter milestones, and indeed when > > we finally > > > present this to IESG, we will be asked for the level of > > support in the > > > WG, which is also predicated on does this fix a real > > problem, or is it > > > just a corner case with limited application. So: > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to = > > > proceed with this draft? The document states: > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 > [I-D.ietf-sip-outbound] > > > defines two keep-alive techniques. Even though the keep-alive > > > techniques are separated from the Outbound mechanism > > > [I-D.ietf-sip-outbound], it is currently not possible > to indicate > > > support of the keep-alive techniques without also > > indicating support > > > for the Outbound mechanism. > > > > > > The Outbound mechanism is enabled during the UA > > registration phase. > > > However, there are use-cases where the UA does not > > register itself, > > > but still needs to be able to make calls and maintain > > NAT bindings > > > open during the duration of that call. A typical example is > > > emergency calls. There are also cases where entities do > > not support > > > the Outbound mechanism, but still want to be able to > > indicate support > > > and use the keep-alive techniques defined in > > [I-D.ietf-sip-outbound]. > > > > > > At first sight this is not the most inspiring declaration > > of the need > > > for the document. Please respond indicating whether you > > consider this a > > > useful draft, and propose text that you think would be > > useful in this > > > section. Conversely, if you think this draft is not useful > > and the WG > > > has other more important things to work on first, please > > also respond. > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for = > > > proceeding with this work? The document currently lists: > > > > > > REQ 1: It MUST be possible for a UA to indicate support > > of the keep- > > > alive techniques defined [I-D.ietf-sip-outbound] if the > > UA supports > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > REQ 2: It MUST be possible for an edge proxy to indicate > > support of > > > the keep-alive techniques defined > > [I-D.ietf-sip-outbound] if the edge > > > poxy supports only the keep-alive part of > > [I-D.ietf-sip-outbound]. > > > > > > It would be desirable to agree these at the outset, and not > > revisit them > > > if we continue with the work. So if you require clarification, = > > > modification, or addition to these two requirements, then > > please also > > > response with your questions and proposals. > > > > > > I suggest we would like responses by 30th June 2008 in > > order to allow > > > the author to revise the document before the deadlines. = > > Please note that > > > we are looking to make this decision on the list within > > this deadline > > > based on responses received, not leave it until the > Dublin meeting. > > > > > > Regards > > > > > > Keith > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use = > > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use = > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > sipping@ietf.org for new developments on the application of sip > > = > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 03:23:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B753A68C5; Tue, 24 Jun 2008 03:23:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCB93A68F8 for ; Tue, 24 Jun 2008 03:23: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tmIVoiLvVBU for ; Tue, 24 Jun 2008 03:22:58 -0700 (PDT) Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id ED8353A688A for ; Tue, 24 Jun 2008 03:22:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,695,1204482600"; d="scan'208";a="9341008" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-2.cisco.com with ESMTP; 24 Jun 2008 15:52:53 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5OAMr3J016953; Tue, 24 Jun 2008 18:22:53 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5OAMrEK025014; Tue, 24 Jun 2008 10:22:53 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 18:22:52 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 18:23:01 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjVzVAff/e6cu9eQtqKXuNvjemhiQAA0acAAAStdIA= References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com><4860A45F.9020001@zonnet.nl> From: "Rockson Li (zhengyli)" To: "Christer Holmberg" , "Jeroen van Bemmel" X-OriginalArrivalTime: 24 Jun 2008 10:22:52.0947 (UTC) FILETIME=[42C42630:01C8D5E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3812; t=1214302973; x=1215166973; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20RE=3A=20[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20; bh=0FzVRblUl6vGQT77xhBIrd2UXkqgyBRYUZi1LmD1P7Q=; b=lRPMYSW6gDdej4bX41tpENTR2jQ2gCxuBrDHZeiZFieCHeZaKvozdK6OZN n1TM4RusoLpGOTJQIuYJbGNiItKwKtr7ZRVyvoVmFhHOobtmlEwArM84mcV/ 7IB5bjTl6C0Q2/AUk9luE64IBUvKRofqcT+VNN3063bHX9L6VRTBI=; Authentication-Results: hkg-dkim-1; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org = Comment in line -Rockson -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris= ter Holmberg Sent: Tuesday, June 24, 2008 4:05 PM To: Jeroen van Bemmel Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Hi, = >Should the 199 response contain a Contact header? And if yes, in case a = >proxy sends it, should it contain the address of that proxy (since the UAS= already sent a final response)? IF the 199 is sent reliably be the proxy must contain a Contact header cont= aining the address of the proxy, yes. >Should we say that a proxy may only generate and send a 199 when it = >receives a final error response on an INVITE client Transaction which = >was in the PROCEEDING state? (i.e. 1xx response was received before, so = >conceptually sending the 199 response is an action associated with the = >transition from PROCEEDING to COMPLETED) I am not sure I understand. The idea IS to send 199 when a final error resp= onse is received by the forking proxy, if a 18x has previously been receive= d. [Rockson] PROCEEDING does not mean early-dialog is established, 100 Trying = also move INVITE client Transaction to PROCEEDING state. Also, a forking proxy with multiple INVITE client Transacti= on may receive/forward 180 from one of them, and receive no provisional res= p and final resp directly from the other one, so INVITE client Transaction's state i= s not dependable. The decision making must be done in TU. Regards, Christer Christer Holmberg wrote: > Hi, > > I agree it may be a good idea to not forbid sending it reliably. > > I do think it would be good to have text, saying that it can be sent unre= liable even if reliable responses are required, though, so that proxies are= n't forced to terminate PRACKs etc. > > Regards, > > Christer > = > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = > Dale.Worley@comcast.net > Sent: 21. kes=E4kuuta 2008 1:38 > To: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > From: "Christer Holmberg" > > [CHH] Whether the text should be in the document at all depends on if = we > allow 199 to be sent reliably in the first place. Based on the comments > received so far we should not mandate 199 to be sent reliably, even if > 100rel is required by the UAC. But, the question if whether we want to > FORBID sending it reliably. > > If we ever might allow 199 to be used for HERFP, we should admit the poss= ibility of sending it reliably in the first draft. Otherwise, we'll be loc= ked out of sending it reliably in the future. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 03:31:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71113A68BA; Tue, 24 Jun 2008 03:31:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469A43A68BA for ; Tue, 24 Jun 2008 03:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Rg8cQVfmGany for ; Tue, 24 Jun 2008 03:31:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0310E3A6809 for ; Tue, 24 Jun 2008 03:31:12 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E6168211D0; Tue, 24 Jun 2008 12:31:11 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-51-4860ccefe94a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C7E04207B7; Tue, 24 Jun 2008 12:31:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 12:31:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 12:31:37 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjVzVAff/e6cu9eQtqKXuNvjemhiQAA0acAAAStdIAAAFt28A== References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com><4860A45F.9020001@zonnet.nl> From: "Christer Holmberg" To: "Rockson Li (zhengyli)" , "Jeroen van Bemmel" X-OriginalArrivalTime: 24 Jun 2008 10:31:38.0173 (UTC) FILETIME=[7BD346D0:01C8D5E5] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, = >>Should the 199 response contain a Contact header? And if yes, in case a = >>proxy sends it, should it contain the address of that proxy (since the UA= S already sent a final response)? > >IF the 199 is sent reliably be the proxy must contain a Contact header con= taining the address of the proxy, yes. > >>Should we say that a proxy may only generate and send a 199 when it = >>receives a final error response on an INVITE client Transaction which = >>was in the PROCEEDING state? (i.e. 1xx response was received before, so = >>conceptually sending the 199 response is an action associated with the = >>transition from PROCEEDING to COMPLETED) > >I am not sure I understand. The idea IS to send 199 when a final error res= ponse is received by the forking proxy, if a = >18x has previously been received. >[Rockson] PROCEEDING does not mean early-dialog is established, 100 Trying= also move INVITE client Transaction to = >PROCEEDING state. [Christer] 199 is only sent when an early dialog has been established. 100 = Trying does not establish an early dialog. Regards, Christer Also, a forking proxy with multiple INVITE client Transaction may receive/f= orward 180 from one of them, and receive no = provisional resp and final resp directly from the other one, so INVITE cli= ent Transaction's state is not dependable. The = decision making must be done in TU. Christer Holmberg wrote: > Hi, > > I agree it may be a good idea to not forbid sending it reliably. > > I do think it would be good to have text, saying that it can be sent unre= liable even if reliable responses are required, though, so that proxies are= n't forced to terminate PRACKs etc. > > Regards, > > Christer > = > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = > Dale.Worley@comcast.net > Sent: 21. kes=E4kuuta 2008 1:38 > To: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > From: "Christer Holmberg" > > [CHH] Whether the text should be in the document at all depends on if = we > allow 199 to be sent reliably in the first place. Based on the comments > received so far we should not mandate 199 to be sent reliably, even if > 100rel is required by the UAC. But, the question if whether we want to > FORBID sending it reliably. > > If we ever might allow 199 to be used for HERFP, we should admit the poss= ibility of sending it reliably in the first draft. Otherwise, we'll be loc= ked out of sending it reliably in the future. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 03:57:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2757F3A6838; Tue, 24 Jun 2008 03:57:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420F73A6838 for ; Tue, 24 Jun 2008 03:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP2T-ILRSSLT for ; Tue, 24 Jun 2008 03:57:05 -0700 (PDT) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 2F4083A67E7 for ; Tue, 24 Jun 2008 03:57:05 -0700 (PDT) Received: (qmail 83109 invoked by alias); 24 Jun 2008 10:57:05 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 24 Jun 2008 10:57:05 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m5OAv2Yl020332; Tue, 24 Jun 2008 19:57:02 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m5OAv2mE001660; Tue, 24 Jun 2008 19:57:02 +0900 (JST) (envelope-from mayumi.munakata@ntt-at.co.jp) Received: from [127.0.0.1] (center5217.cnh.ntt-at.co.jp [192.168.23.217]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 3F89B53F61; Tue, 24 Jun 2008 19:57:02 +0900 (JST) Message-ID: <4860D2E4.10109@ntt-at.co.jp> Date: Tue, 24 Jun 2008 19:56:36 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dean Willis References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> In-Reply-To: <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> Cc: "sip@ietf.org" , Paul Kyzivat Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, Dean Willis wrote: >> draft-ietf-sip-ua-privacy > > -- This one is done, You might misunderstand the situation of ua-privacy, but I am still working on that work, and will submit a new version in a week or so. An open issue regarding a From header (what kind of anonymous URI to be set) was solved in Philadelphia and now I am studying the treatment of other headers. Thanks, Mayumi _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 04:00:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63283A6994; Tue, 24 Jun 2008 04:00:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B663A6965 for ; Tue, 24 Jun 2008 04:00:26 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQhdpsVRv3vN for ; Tue, 24 Jun 2008 04:00:25 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 78A1E3A68D3 for ; Tue, 24 Jun 2008 04:00:25 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K2Y00J79RPQJH@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Jun 2008 12:00:26 +0100 (BST) Date: Tue, 24 Jun 2008 12:00:15 +0100 From: "Elwell, John" In-reply-to: <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> To: Dan Wing , Dean Willis , Hadriel Kaplan Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E0D1@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjVd00Eu5N8KFfbSbWxzCG0QqfVhAAA2DSQABujamA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: 23 June 2008 22:48 > To: 'Dean Willis'; 'Hadriel Kaplan' > Cc: sip@ietf.org; 'Paul Kyzivat' > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > > draft-ietf-sip-saml > > -- I'm not sure this one is ever getting done. > > > > So I'm not sure there's enough there to justify a WG. > > > > How about an "Identity in SIP" working group that takes on > > fixing RFC 4474 for gateways/b2buas and possibly considers > > identity/role assertion using SAML? > > I agree we need that. I have tried, and so far failed, to > initiate activity towards such an effort. I think there are enough issues in this area - and yes, they do need solving - to justify a separate WG, hopefully with a fairly short lifetime. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 05:23:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297443A6A01; Tue, 24 Jun 2008 05:23:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0273A6A10 for ; Tue, 24 Jun 2008 05:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 4i6kym+FC-KQ for ; Tue, 24 Jun 2008 05:23:49 -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 8AF723A6A01 for ; Tue, 24 Jun 2008 05:23:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204520400"; d="scan'208";a="12040438" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Jun 2008 08:23:50 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5OCNoPq022512; Tue, 24 Jun 2008 08:23:50 -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.13.8) with ESMTP id m5OCNoSS006366; Tue, 24 Jun 2008 12:23:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 08:23:50 -0400 Received: from [10.86.243.17] ([10.86.243.17]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 08:23:49 -0400 Message-ID: <4860E783.3070008@cisco.com> Date: Tue, 24 Jun 2008 08:24:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> In-Reply-To: <200806202237.m5KMbcuk008312@dragon.ariadne.com> X-OriginalArrivalTime: 24 Jun 2008 12:23:49.0636 (UTC) FILETIME=[28170440:01C8D5F5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2210; t=1214310230; x=1215174230; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=5lkj2epusiqJsD7MpULHgQq9IjOJs8m0aUIcXC1BSLg=; b=MRHW4luks/2nHH8pkOrF7mmaBCIpZX3qO+p6zndYuFavrXH9mW7qK4OlLp RmlpnjamEISo+r5r7JTGgkC+xY/Rkmalyapo8IWpxYGJ7nUH985iPCHzjnyA WbUmTHenTq; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There is a very messy slippery slope here with the reliable 199. I believe we have agreed that the 199 is to have the to-tag used by the UAS. So conceptually it is *from* the UAS. If you want the proxy to send the 199 reliably, then it will have to field the response. As others have mentioned, this seems to mean that it will have to use its own contact address, which will be a change from the contact used previously by the UAS for this early dialog. That gives me heartburn - it just seems wrong. Ignoring that, it puts the 199 into the middle of the open question about changing of contact addresses and how they take effect. This could be addressed by always sending the 199 with a To-tag assigned by the proxy. But that has its own problems. It actually makes the situation worse for UACs that don't support 199. We sidestep all these problems by not sending the 199 reliably. Maybe we we should say that the UAC must be prepared to handle both reliable and unreliable 199, but for now we don't specify any cases when a reliable 199 is sent. Another thought - there aren't any issues if the *UAS* sends the 199 reliably. But that isn't going to be the common case. Paul Dale.Worley@comcast.net wrote: > From: "Christer Holmberg" > > [CHH] Whether the text should be in the document at all depends on if we > allow 199 to be sent reliably in the first place. Based on the comments > received so far we should not mandate 199 to be sent reliably, even if > 100rel is required by the UAC. But, the question if whether we want to > FORBID sending it reliably. > > If we ever might allow 199 to be used for HERFP, we should admit the > possibility of sending it reliably in the first draft. Otherwise, > we'll be locked out of sending it reliably in the future. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 05:29:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697343A68FB; Tue, 24 Jun 2008 05:29:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A289C3A68E8 for ; Tue, 24 Jun 2008 05:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 wPwZ4xBq+Noi for ; Tue, 24 Jun 2008 05:29:55 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6CF9D3A68FB for ; Tue, 24 Jun 2008 05:29:55 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 46E1520B77; Tue, 24 Jun 2008 14:29:55 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-71-4860e8c3763c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1A32C20786; Tue, 24 Jun 2008 14:29:55 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 14:30:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 14:30:20 +0200 Message-ID: In-Reply-To: <4860E783.3070008@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjV9UdR2U+wa/nkSOmDznXjnzcrHwAAFX+A References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> <4860E783.3070008@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 24 Jun 2008 12:30:21.0969 (UTC) FILETIME=[11F04810:01C8D5F6] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, If the proxy assignes its own To-tag, we can't use the To-tag to indciate w= hich dialog was terminated. One option, as proposed by Paul, is to say that a UAC shall be able to RECE= IVE reliable 199 responses. One ugly solution would be to retransmit the UNRELIABLE 199 a few times - w= e already use that type of mechanism in ICE, so... ;) Regards, Christer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul = Kyzivat Sent: 24. kes=E4kuuta 2008 15:25 To: Dale.Worley@comcast.net Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 There is a very messy slippery slope here with the reliable 199. I believe we have agreed that the 199 is to have the to-tag used by the UAS= . So conceptually it is *from* the UAS. If you want the proxy to send the 1= 99 reliably, then it will have to field the response. As others have mentio= ned, this seems to mean that it will have to use its own contact address, w= hich will be a change from the contact used previously by the UAS for this = early dialog. That gives me heartburn - it just seems wrong. Ignoring that, it puts the 1= 99 into the middle of the open question about changing of contact addresses= and how they take effect. This could be addressed by always sending the 199 with a To-tag assigned by= the proxy. But that has its own problems. It actually makes the situation = worse for UACs that don't support 199. We sidestep all these problems by not sending the 199 reliably. Maybe we we should say that the UAC must be prepared to handle both reliabl= e and unreliable 199, but for now we don't specify any cases when a reliabl= e 199 is sent. Another thought - there aren't any issues if the *UAS* sends the 199 reliab= ly. But that isn't going to be the common case. Paul Dale.Worley@comcast.net wrote: > From: "Christer Holmberg" > = > [CHH] Whether the text should be in the document at all depends on if = we > allow 199 to be sent reliably in the first place. Based on the comments > received so far we should not mandate 199 to be sent reliably, even if > 100rel is required by the UAC. But, the question if whether we want to > FORBID sending it reliably. > = > If we ever might allow 199 to be used for HERFP, we should admit the = > possibility of sending it reliably in the first draft. Otherwise, = > we'll be locked out of sending it reliably in the future. > = > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 05:43:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4AA3A692A; Tue, 24 Jun 2008 05:43:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCBA3A6975 for ; Tue, 24 Jun 2008 05:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 goqQthyMtcqT for ; Tue, 24 Jun 2008 05:43:04 -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 290663A67FA for ; Tue, 24 Jun 2008 05:43:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204531200"; d="scan'208";a="43890571" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2008 05:43:05 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5OCh57C014339; Tue, 24 Jun 2008 05:43:05 -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.13.8) with ESMTP id m5OCh1ed004623; Tue, 24 Jun 2008 12:43:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 08:43:04 -0400 Received: from [10.86.243.17] ([10.86.243.17]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 08:43:04 -0400 Message-ID: <4860EC06.6080104@cisco.com> Date: Tue, 24 Jun 2008 08:43:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> <4860E783.3070008@cisco.com> In-Reply-To: X-OriginalArrivalTime: 24 Jun 2008 12:43:04.0307 (UTC) FILETIME=[D853D430:01C8D5F7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3890; t=1214311385; x=1215175385; c=relaxed/simple; s=sjdkim2002; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20; bh=PTLV50qlQKcc6Xy4uQyeoW8VHExz5sd4P0AlVOmvfQ8=; b=aRv7Nu+OK25TuTGq2XV4P08rTs0T+zjLV3Er3t5FNyGvH1oyWrIh9MNkb/ NrgCZsyyKRFf3s3cUrKF66fjGR/QM7zgvvqm8ju+BNnz3Ng7SnDuJUyzVIyy 2OrI4fgQ16; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > = > If the proxy assignes its own To-tag, we can't use the To-tag to indciate= which dialog was terminated. Right. That was part of my point. In addition, the to-tag it does use = creates *another* early dialog. And then, suppose we did allow the proxy to reuse the existing dialog = for the 199, with a new contact. Then the UAC, upon receipt of the 199, = will have to send the PRACK within the dialog. So the dialog can't be = immediately destroyed. When *does* it get destroyed??? When the 200 to = the PRACK is received? The extra state management and time required to handle this seems to run = contrary to the goal of the 199. > One option, as proposed by Paul, is to say that a UAC shall be able to RE= CEIVE reliable 199 responses. Based on my comments above, I am reconsidering the advisability of that. > One ugly solution would be to retransmit the UNRELIABLE 199 a few times -= we already use that type of mechanism in ICE, so... ;) Yes, that *is* ugly! Paul > Regards, > = > Christer > = > = > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Pau= l Kyzivat > Sent: 24. kes=E4kuuta 2008 15:25 > To: Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > = > There is a very messy slippery slope here with the reliable 199. > = > I believe we have agreed that the 199 is to have the to-tag used by the U= AS. So conceptually it is *from* the UAS. If you want the proxy to send the= 199 reliably, then it will have to field the response. As others have ment= ioned, this seems to mean that it will have to use its own contact address,= which will be a change from the contact used previously by the UAS for thi= s early dialog. > = > That gives me heartburn - it just seems wrong. Ignoring that, it puts the= 199 into the middle of the open question about changing of contact address= es and how they take effect. > = > This could be addressed by always sending the 199 with a To-tag assigned = by the proxy. But that has its own problems. It actually makes the situatio= n worse for UACs that don't support 199. > = > We sidestep all these problems by not sending the 199 reliably. > = > Maybe we we should say that the UAC must be prepared to handle both relia= ble and unreliable 199, but for now we don't specify any cases when a relia= ble 199 is sent. > = > Another thought - there aren't any issues if the *UAS* sends the 199 reli= ably. But that isn't going to be the common case. > = > Paul > = > Dale.Worley@comcast.net wrote: >> From: "Christer Holmberg" >> >> [CHH] Whether the text should be in the document at all depends on if= we >> allow 199 to be sent reliably in the first place. Based on the commen= ts >> received so far we should not mandate 199 to be sent reliably, even if >> 100rel is required by the UAC. But, the question if whether we want to >> FORBID sending it reliably. >> >> If we ever might allow 199 to be used for HERFP, we should admit the = >> possibility of sending it reliably in the first draft. Otherwise, = >> we'll be locked out of sending it reliably in the future. >> >> Dale >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use sip-impleme= ntors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for= new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 05:56:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BA23A68C9; Tue, 24 Jun 2008 05:56:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025A93A68C9 for ; Tue, 24 Jun 2008 05:56:49 -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 zQyDiSUdQ0eq for ; Tue, 24 Jun 2008 05:56:47 -0700 (PDT) Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id D746C3A684C for ; Tue, 24 Jun 2008 05:56:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204482600"; d="scan'208";a="9351358" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-2.cisco.com with ESMTP; 24 Jun 2008 18:26:45 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5OCuiKB032020; Tue, 24 Jun 2008 20:56:44 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5OCuiBv021943; Tue, 24 Jun 2008 12:56:44 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 20:53:11 +0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 20:53:16 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 Thread-Index: AcjVzVAff/e6cu9eQtqKXuNvjemhiQAA0acAAAStdIAAAFt28AAFHfwg References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com><4860A45F.9020001@zonnet.nl> From: "Rockson Li (zhengyli)" To: "Christer Holmberg" , "Jeroen van Bemmel" X-OriginalArrivalTime: 24 Jun 2008 12:53:11.0721 (UTC) FILETIME=[425FD990:01C8D5F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3973; t=1214312205; x=1215176205; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20RE=3A=20[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20; bh=h8sQeGodq/7l8bRQtsjSlVk4l1JHQLCYwVFBNkeX9KI=; b=Fl4jsH9RO9YwmzqyvlhM04fbBRvATUcMwfNPljBgkLvCrvjcaLJbuWhKD1 nrroNq6qUeHxx7NF2H9vXFudUqNLXUxHBSd5oAr10E4OKIQXhuCKdbH/FHBO VNKLmbORuEvG9XCcg3u94XONxNqgZUmBklqYS37/P6NcfVnSPGWMM=; Authentication-Results: hkg-dkim-1; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, it's a typo, 100 does not establish early-dialog. -Rockson = -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] = Sent: Tuesday, June 24, 2008 6:32 PM To: Rockson Li (zhengyli); Jeroen van Bemmel Cc: sip@ietf.org Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 Hi, = >>Should the 199 response contain a Contact header? And if yes, in case = >>a proxy sends it, should it contain the address of that proxy (since the = UAS already sent a final response)? > >IF the 199 is sent reliably be the proxy must contain a Contact header con= taining the address of the proxy, yes. > >>Should we say that a proxy may only generate and send a 199 when it = >>receives a final error response on an INVITE client Transaction which = >>was in the PROCEEDING state? (i.e. 1xx response was received before, = >>so conceptually sending the 199 response is an action associated with = >>the transition from PROCEEDING to COMPLETED) > >I am not sure I understand. The idea IS to send 199 when a final error = >response is received by the forking proxy, if a 18x has previously been re= ceived. >[Rockson] PROCEEDING does not mean early-dialog is established, 100 = >Trying also move INVITE client Transaction to PROCEEDING state. [Christer] 199 is only sent when an early dialog has been established. 100 = Trying does not establish an early dialog. Regards, Christer Also, a forking proxy with multiple INVITE client Transaction may receive/f= orward 180 from one of them, and receive no provisional resp and final resp= directly from the other one, so INVITE client Transaction's state is not = dependable. The decision making must be done in TU. Christer Holmberg wrote: > Hi, > > I agree it may be a good idea to not forbid sending it reliably. > > I do think it would be good to have text, saying that it can be sent unre= liable even if reliable responses are required, though, so that proxies are= n't forced to terminate PRACKs etc. > > Regards, > > Christer > = > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = > Dale.Worley@comcast.net > Sent: 21. kes=E4kuuta 2008 1:38 > To: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > From: "Christer Holmberg" > > [CHH] Whether the text should be in the document at all depends on if = we > allow 199 to be sent reliably in the first place. Based on the comments > received so far we should not mandate 199 to be sent reliably, even if > 100rel is required by the UAC. But, the question if whether we want to > FORBID sending it reliably. > > If we ever might allow 199 to be used for HERFP, we should admit the poss= ibility of sending it reliably in the first draft. Otherwise, we'll be loc= ked out of sending it reliably in the future. > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 06:25:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAAF43A6861; Tue, 24 Jun 2008 06:25:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1533A6861 for ; Tue, 24 Jun 2008 06:25:09 -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 MsrNhCadDA4U for ; Tue, 24 Jun 2008 06:25:06 -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 8D3673A6824 for ; Tue, 24 Jun 2008 06:25:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204531200"; d="scan'208";a="82912473" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2008 06:25:07 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5ODP3KR002941; Tue, 24 Jun 2008 06:25:04 -0700 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.13.8) with ESMTP id m5ODP3u9003310; Tue, 24 Jun 2008 13:25:03 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.1830); Tue, 24 Jun 2008 09:25:03 -0400 Received: from [10.82.249.105] ([10.82.249.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:25:03 -0400 Message-ID: <4860F5B6.2060307@cisco.com> Date: Tue, 24 Jun 2008 09:25:10 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mary Barnes References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> In-Reply-To: X-OriginalArrivalTime: 24 Jun 2008 13:25:03.0183 (UTC) FILETIME=[B5B1CDF0:01C8D5FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1670; t=1214313907; x=1215177907; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=ID33t+4rfHtaVesQHDKRLywHZc++DVOKGz5iqp0fTkM=; b=VGhSWOSE3WCPKj0l2tYk+PV9Ug6CQVHRiFOuRnnokaoOjYNtwAlRkzTg/w RX5uR4tdKSMfSqIdJu3NJ+c60CJ/BpH9MCe+GbwfEVHzXGrgfyM05ZFC127Y 0AcL3FkPFUSRdlUA0OrdMyvyKgK5TTAxFOfktCyWPWEwx6LWMgeCs=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Paul Kyzivat , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mary Barnes wrote: > I don't believe we could ever forbid INFO. I initially did not think > we could accomplish anything around INFO, but I believe some of the > work that's on the table would be useful for working towards > interoperabilty for the INFO usages. I would be afraid to ask > honestly for the identification of all the different uses of INFO > that are out there right now. I don't think we should be afraid of this at all. There are (sometimes/often) good reasons why folks resort to these solutions. Our job here at IETF is to ensure interoperability for the SIP protocol. If we don't listen to our customers - the people who have deployed and are actually using it - what purpose does our work serve? > > Doing something is better than nothing at this point IMHO and I'm > personally really tired of revisiting this issue every couple of > years. AND, this would help us put a stake in the group on the future > usages of INFO (whether we ever get rid of the old usages or not), as > I believe there are other SDOs defining new uses of INFO right now to > add to the mix of un-interoperability in this area. As long as SIP usage continues to rise, I suspect we will continue to see more INFO usages. Just because we cannot fix what is broken in the past, doesn't mean we should let it remain broken for the future. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 06:48:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176CD3A6829; Tue, 24 Jun 2008 06:48:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEC53A6829 for ; Tue, 24 Jun 2008 06:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 rxzbb3PTgEww for ; Tue, 24 Jun 2008 06:48:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B1F573A6819 for ; Tue, 24 Jun 2008 06:48:27 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5ODkWQ12267; Tue, 24 Jun 2008 13:46:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 08:45:23 -0500 Message-ID: In-Reply-To: <4860F5B6.2060307@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjV/b78SRWJBUg+ST2241KSxL9HbAAAC7TA References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> From: "Mary Barnes" To: "Jonathan Rosenberg" Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Paul Kyzivat , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just a couple more points of clarification on my view embedded below [MB]. Mary -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Tuesday, June 24, 2008 8:25 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; SIP@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: Re: [Sip] INFO and what to do about it? Mary Barnes wrote: > I don't believe we could ever forbid INFO. I initially did not think > we could accomplish anything around INFO, but I believe some of the > work that's on the table would be useful for working towards > interoperabilty for the INFO usages. I would be afraid to ask honestly > for the identification of all the different uses of INFO that are out > there right now. I don't think we should be afraid of this at all. [MB] My guess (based on what I've seen) is that a lot of vendors would have around a half dozen (+- 2). Now, some of those might overlap given there is some level of interop between various vendors. [/MB] There are (sometimes/often) good reasons why folks resort to these solutions. Our job here at IETF is to ensure interoperability for the SIP protocol. If we don't listen to our customers - the people who have deployed and are actually using it - what purpose does our work serve? [MB] My experience is that at least half the uses of INFO were in place when the protocol was quite immature (i.e., well before RFC 3261). And, we indeed should listen to our customers by providing a flexible platform for them to do the things they need to do. IMHO, it's been loud and clear in the past that they want to use INFO and in the past, docs like "Info considered harmful" weren't helpful towards this end. [/MB] > > Doing something is better than nothing at this point IMHO and I'm > personally really tired of revisiting this issue every couple of > years. AND, this would help us put a stake in the group on the future > usages of INFO (whether we ever get rid of the old usages or not), as > I believe there are other SDOs defining new uses of INFO right now to > add to the mix of un-interoperability in this area. As long as SIP usage continues to rise, I suspect we will continue to see more INFO usages. Just because we cannot fix what is broken in the past, doesn't mean we should let it remain broken for the future. [MB] I'm not at all disagreeing on this point. Optimistically, I'd like to see the current implementations evolve to support this new approach as it will improve interoperability. If the WG can complete this work in a timely manner (perhaps the biggest issue given past performance), then the potential for uptake for a standardized implementation is INFO is far higher IMHO. If we can get this work chartered, then we're far more likely to get uptake by the other SDOs far sooner than if we continue to dillydally. And, it's important to remember that this isn't the only area where there are interoperability issues. And, actually, per SFSIW-1 the use of INFO was not a common theme - either because it was a given or it's not as big an issue as some of us are assuming - in a quick scan I only found one document discussing the use of INFO. [/MB] -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 06:59:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D563A68F5; Tue, 24 Jun 2008 06:59:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DEC3A68F5 for ; Tue, 24 Jun 2008 06:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 3EDUI93yzFJg for ; Tue, 24 Jun 2008 06:59:46 -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 A05023A6899 for ; Tue, 24 Jun 2008 06:59:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204531200"; d="scan'208";a="59802060" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2008 06:59:47 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5ODxlN3005120; Tue, 24 Jun 2008 06:59:47 -0700 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.13.8) with ESMTP id m5ODxlMh019862; Tue, 24 Jun 2008 13:59:47 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.1830); Tue, 24 Jun 2008 09:59:46 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:59:46 -0400 Message-ID: <4860FE00.7030601@cisco.com> Date: Tue, 24 Jun 2008 10:00:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Mary Barnes References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> In-Reply-To: X-OriginalArrivalTime: 24 Jun 2008 13:59:46.0757 (UTC) FILETIME=[8F99F750:01C8D602] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3928; t=1214315987; x=1215179987; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=GAoebtLFmf51lzUixorlxeDh8gSONL77UmnLEuBzxaE=; b=PpVe28KW/hGF4X/AXFHXztQJoT6YxxgVtDlMhyrHDKOGRyQNNYeI/TYYPy iMyEso7eFRWJIdE8Xmu3jzM4LJepq2FwHdbhp87+HgzPphf88diCZzGDMo7Q cC8Xx7+Ixm; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mary, My latest thought is that we should "grandfather" existing uses of INFO. We would provide a registry of them, without blessing them or standardizing their specifications. That would at least shine some light in the dark corners. At the same time, we would define the new INFO usage framework (still TBD) and ban *new* INFO usages that don't follow it. I think that would be better than the current situation, and about as good as we can expect to achieve. Thanks, Paul Mary Barnes wrote: > Just a couple more points of clarification on my view embedded below > [MB]. > > Mary > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, June 24, 2008 8:25 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; SIP@ietf.org; DOLLY, > MARTIN C, ATTLABS > Subject: Re: [Sip] INFO and what to do about it? > > > > Mary Barnes wrote: >> I don't believe we could ever forbid INFO. I initially did not think >> we could accomplish anything around INFO, but I believe some of the >> work that's on the table would be useful for working towards >> interoperabilty for the INFO usages. I would be afraid to ask honestly > >> for the identification of all the different uses of INFO that are out >> there right now. > > I don't think we should be afraid of this at all. > [MB] My guess (based on what I've seen) is that a lot of vendors would > have around a half dozen (+- 2). Now, some of those might overlap given > there is some level of interop between various vendors. [/MB] > > There are (sometimes/often) good reasons why folks resort to these > solutions. Our job here at IETF is to ensure interoperability for the > SIP protocol. If we don't listen to our customers - the people who have > deployed and are actually using it - what purpose does our work serve? > > [MB] My experience is that at least half the uses of INFO were in place > when the protocol was quite immature (i.e., well before RFC 3261). And, > we indeed should listen to our customers by providing a flexible > platform for them to do the things they need to do. IMHO, it's been loud > and clear in the past that they want to use INFO and in the past, docs > like "Info considered harmful" weren't helpful towards this end. [/MB] > >> Doing something is better than nothing at this point IMHO and I'm >> personally really tired of revisiting this issue every couple of >> years. AND, this would help us put a stake in the group on the future >> usages of INFO (whether we ever get rid of the old usages or not), as >> I believe there are other SDOs defining new uses of INFO right now to >> add to the mix of un-interoperability in this area. > > As long as SIP usage continues to rise, I suspect we will continue to > see more INFO usages. Just because we cannot fix what is broken in the > past, doesn't mean we should let it remain broken for the future. > > [MB] I'm not at all disagreeing on this point. Optimistically, I'd like > to see the current implementations evolve to support this new approach > as it will improve interoperability. If the WG can complete this work in > a timely manner (perhaps the biggest issue given past performance), then > the potential for uptake for a standardized implementation is INFO is > far higher IMHO. If we can get this work chartered, then we're far more > likely to get uptake by the other SDOs far sooner than if we continue to > dillydally. And, it's important to remember that this isn't the only > area where there are interoperability issues. And, actually, per SFSIW-1 > the use of INFO was not a common theme - either because it was a given > or it's not as big an issue as some of us are assuming - in a quick scan > I only found one document discussing the use of INFO. [/MB] > > -Jonathan R. > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 07:04:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869453A68B4; Tue, 24 Jun 2008 07:04:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C183A68B4 for ; Tue, 24 Jun 2008 07:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 gT6on0gTsKBK for ; Tue, 24 Jun 2008 07:04:06 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id E40B63A684C for ; Tue, 24 Jun 2008 07:04:05 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5OE3kL08835; Tue, 24 Jun 2008 14:03:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 09:00:58 -0500 Message-ID: In-Reply-To: <4860FE00.7030601@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjWApNl36Mi3zFaS9y9KtxcGI9m5gAADdHQ References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> From: "Mary Barnes" To: "Paul Kyzivat" Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, The grandfathering is aa good suggestion and likely far more pragmatic than my optimistic approach that they'll evolve. I will go ahead and ping our folks and see how they feel about this. If others will do the same, I think we'll have some very interesting results. Thanks, Mary -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, June 24, 2008 9:01 AM To: Barnes, Mary (RICH2:AR00) Cc: Jonathan Rosenberg; Christer Holmberg; Robert Sparks; SIP@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: Re: [Sip] INFO and what to do about it? Mary, My latest thought is that we should "grandfather" existing uses of INFO. We would provide a registry of them, without blessing them or standardizing their specifications. That would at least shine some light in the dark corners. At the same time, we would define the new INFO usage framework (still TBD) and ban *new* INFO usages that don't follow it. I think that would be better than the current situation, and about as good as we can expect to achieve. Thanks, Paul Mary Barnes wrote: > Just a couple more points of clarification on my view embedded below > [MB]. > > Mary > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, June 24, 2008 8:25 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; SIP@ietf.org; > DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] INFO and what to do about it? > > > > Mary Barnes wrote: >> I don't believe we could ever forbid INFO. I initially did not think >> we could accomplish anything around INFO, but I believe some of the >> work that's on the table would be useful for working towards >> interoperabilty for the INFO usages. I would be afraid to ask >> honestly > >> for the identification of all the different uses of INFO that are out >> there right now. > > I don't think we should be afraid of this at all. > [MB] My guess (based on what I've seen) is that a lot of vendors would > have around a half dozen (+- 2). Now, some of those might overlap > given there is some level of interop between various vendors. [/MB] > > There are (sometimes/often) good reasons why folks resort to these > solutions. Our job here at IETF is to ensure interoperability for the > SIP protocol. If we don't listen to our customers - the people who > have deployed and are actually using it - what purpose does our work serve? > > [MB] My experience is that at least half the uses of INFO were in > place when the protocol was quite immature (i.e., well before RFC > 3261). And, we indeed should listen to our customers by providing a > flexible platform for them to do the things they need to do. IMHO, > it's been loud and clear in the past that they want to use INFO and in > the past, docs like "Info considered harmful" weren't helpful towards > this end. [/MB] > >> Doing something is better than nothing at this point IMHO and I'm >> personally really tired of revisiting this issue every couple of >> years. AND, this would help us put a stake in the group on the future >> usages of INFO (whether we ever get rid of the old usages or not), as >> I believe there are other SDOs defining new uses of INFO right now to >> add to the mix of un-interoperability in this area. > > As long as SIP usage continues to rise, I suspect we will continue to > see more INFO usages. Just because we cannot fix what is broken in the > past, doesn't mean we should let it remain broken for the future. > > [MB] I'm not at all disagreeing on this point. Optimistically, I'd > like to see the current implementations evolve to support this new > approach as it will improve interoperability. If the WG can complete > this work in a timely manner (perhaps the biggest issue given past > performance), then the potential for uptake for a standardized > implementation is INFO is far higher IMHO. If we can get this work > chartered, then we're far more likely to get uptake by the other SDOs > far sooner than if we continue to dillydally. And, it's important to > remember that this isn't the only area where there are > interoperability issues. And, actually, per SFSIW-1 the use of INFO > was not a common theme - either because it was a given or it's not as > big an issue as some of us are assuming - in a quick scan I only found > one document discussing the use of INFO. [/MB] > > -Jonathan R. > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 08:07:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353193A6821; Tue, 24 Jun 2008 08:07:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB1C3A6982 for ; Tue, 24 Jun 2008 08:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjemz2yW7s32 for ; Tue, 24 Jun 2008 08:07:22 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id DE97E3A694A for ; Tue, 24 Jun 2008 08:07:16 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP for sip@ietf.org; Tue, 24 Jun 2008 17:07:17 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 17:07:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 17:07:21 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD402CA8686@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft: draft-holmberg-sip-keep-00.txt Thread-Index: AcjWCvVfgmZ9lposQZCWhZDCFsspkQ== From: "Jesske, R" To: X-OriginalArrivalTime: 24 Jun 2008 15:07:15.0963 (UTC) FILETIME=[FD1DC4B0:01C8D60B] Subject: [Sip] Draft: draft-holmberg-sip-keep-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0389120237==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0389120237== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D60B.FCCDFA88" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D60B.FCCDFA88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, what is the status of this draft? Will there be some consideration of this proposal of defining a keep = parameter? will this possibly incorporated into draft-ietf-sip-outbound? =20 Thanks and Best Regards =20 Roland =20 Deutsche Telekom AG=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:=20 Deutsche Telekom AG Aufsichtsrat: Prof. Dr Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Karl-Gerhard Eick (stellvertretender Vorsit-zender), Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794,=20 Sitz der Gesellschaft: Bonn=20 WEEE-Reg.-Nr.: DE50478376=20 ***************************************************************=20 Deutsche Telekom AG=20 Supervisory Board: Prof. Dr Ulrich Lehner (Chairman)=20 Board of Management: Ren=E9 Obermann (Chairman),=20 Dr. Karl-Gerhard Eick (Deputy Chairman),=20 Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Commercial register: Amtsgericht Bonn HRB 6794,=20 corporate seat: Bonn=20 WEEEreg.no: DE50478376=20 =20 ------_=_NextPart_001_01C8D60B.FCCDFA88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
what = is the status=20 of this draft?
Will = there be some=20 consideration of this proposal of defining a keep = parameter?
will = this possibly=20 incorporated into draft-ietf-sip-outbound?
 
Thanks = and Best=20 Regards
 
Roland
 

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

http://www.telekom.de=20

Registerrechtliche Unternehmensangaben:=20
Deutsche Telekom=20 AG
Aufsichtsrat: Prof. Dr Ulrich Lehner=20 (Vorsitzender)
Vorstand: René Obermann = (Vorsitzender),
Dr.=20 Karl-Gerhard Eick (stellvertretender Vorsit-zender),
Hamid Akhavan, = Reinhard=20 Clemens, Timotheus Höttges, Thomas Sattelberger
Handelsregister: Amtsgericht Bonn HRB 6794,
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.:=20 DE50478376
***************************************************************= =20
Deutsche Telekom AG
Supervisory=20 Board: Prof. Dr Ulrich Lehner=20 (Chairman)
Board of Management: = René Obermann=20 (Chairman),
Dr. Karl-Gerhard Eick (Deputy=20 Chairman),
Hamid Akhavan, Reinhard = Clemens,=20 Timotheus Höttges,  Thomas = Sattelberger
Commercial=20 register: Amtsgericht Bonn HRB 6794,
corporate seat:=20 Bonn
WEEEreg.no: = DE50478376

 
------_=_NextPart_001_01C8D60B.FCCDFA88-- --===============0389120237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0389120237==-- From sip-bounces@ietf.org Tue Jun 24 08:15:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5463A6A12; Tue, 24 Jun 2008 08:15:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E853A689B for ; Tue, 24 Jun 2008 08:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.040, 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 pmU3NhMahpdT for ; Tue, 24 Jun 2008 08:15:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 466B63A696F for ; Tue, 24 Jun 2008 08:15:44 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 007BA20F25; Tue, 24 Jun 2008 17:15:43 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-be-48610f9f18b1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C8C4420559; Tue, 24 Jun 2008 17:15:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 17:16:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 17:16:09 +0200 Message-ID: In-Reply-To: <9886E5FCA6D76549A3011068483A4BD402CA8686@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft: draft-holmberg-sip-keep-00.txt thread-index: AcjWCvVfgmZ9lposQZCWhZDCFsspkQAAXrrg References: <9886E5FCA6D76549A3011068483A4BD402CA8686@S4DE8PSAAQB.mitte.t-com.de> From: "Christer Holmberg" To: "Jesske, R" , X-OriginalArrivalTime: 24 Jun 2008 15:16:10.0174 (UTC) FILETIME=[3B87E5E0:01C8D60D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1805475990==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1805475990== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D60D.3BB2C99E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D60D.3BB2C99E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roland, =20 The latest version of the draft is -01. =20 http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt = =20 =20 Keith sent out an e-mail (Subject: Progress draft-holmberg-sip-keep) = last week (thursday 19th), with some questions for people to answer, in = order to figure out whether there is interest to progress work with the = draft. Please take a look.=20 =20 Whatever happens, I am pretty sure it will NOT be incorporated into the = Outbound spec :) =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Jesske, R Sent: 24. kes=E4kuuta 2008 18:07 To: sip@ietf.org Subject: [Sip] Draft: draft-holmberg-sip-keep-00.txt Dear all, what is the status of this draft? Will there be some consideration of this proposal of defining a keep = parameter? will this possibly incorporated into draft-ietf-sip-outbound? =20 Thanks and Best Regards =20 Roland =20 Deutsche Telekom AG=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:=20 Deutsche Telekom AG Aufsichtsrat: Prof. Dr Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Karl-Gerhard Eick (stellvertretender Vorsit-zender), Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794,=20 Sitz der Gesellschaft: Bonn=20 WEEE-Reg.-Nr.: DE50478376=20 ***************************************************************=20 Deutsche Telekom AG=20 Supervisory Board: Prof. Dr Ulrich Lehner (Chairman)=20 Board of Management: Ren=E9 Obermann (Chairman),=20 Dr. Karl-Gerhard Eick (Deputy Chairman),=20 Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Commercial register: Amtsgericht Bonn HRB 6794,=20 corporate seat: Bonn=20 WEEEreg.no: DE50478376=20 =20 ------_=_NextPart_001_01C8D60D.3BB2C99E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Roland,
 
The=20 latest version of the draft is -01.
 
http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.t= xt
 
Keith=20 sent out an e-mail (Subject: Progress draft-holmberg-sip-keep) last = week=20 (thursday 19th), with some questions for people to answer, in order = to=20 figure out whether there is interest to progress work with the = draft.=20 Please take a look.
 
Whatever happens, I am pretty sure it will NOT be incorporated = into the=20 Outbound spec :)
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Jesske, = R
Sent: 24.=20 kes=E4kuuta 2008 18:07
To: sip@ietf.org
Subject: = [Sip] Draft:=20 draft-holmberg-sip-keep-00.txt

Dear=20 all,
what = is the status=20 of this draft?
Will = there be some=20 consideration of this proposal of defining a keep = parameter?
will = this possibly=20 incorporated into draft-ietf-sip-outbound?
 
Thanks = and Best=20 Regards
 
Roland
 

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

http://www.telekom.de=20

Registerrechtliche Unternehmensangaben:=20
Deutsche Telekom=20 AG
Aufsichtsrat: Prof. Dr Ulrich Lehner=20 (Vorsitzender)
Vorstand: Ren=E9 Obermann=20 (Vorsitzender),
Dr.=20 Karl-Gerhard Eick (stellvertretender Vorsit-zender),
Hamid Akhavan, = Reinhard=20 Clemens, Timotheus H=F6ttges, Thomas Sattelberger
Handelsregister: Amtsgericht Bonn HRB 6794,
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.:=20 DE50478376
***************************************************************= =20
Deutsche Telekom AG
Supervisory=20 Board: Prof. Dr Ulrich Lehner=20 (Chairman)
Board of Management: = Ren=E9 Obermann=20 (Chairman),
Dr. Karl-Gerhard Eick (Deputy=20 Chairman),
Hamid Akhavan, Reinhard = Clemens,=20 Timotheus H=F6ttges,  Thomas = Sattelberger
Commercial=20 register: Amtsgericht Bonn HRB 6794,
corporate seat:=20 Bonn
WEEEreg.no: = DE50478376

 
------_=_NextPart_001_01C8D60D.3BB2C99E-- --===============1805475990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1805475990==-- From sip-bounces@ietf.org Tue Jun 24 08:18:35 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0AD23A6866; Tue, 24 Jun 2008 08:18:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BEE73A6821 for ; Tue, 24 Jun 2008 08:18:34 -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 S292Ffw7gRsU for ; Tue, 24 Jun 2008 08:18:30 -0700 (PDT) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by core3.amsl.com (Postfix) with ESMTP id E768E3A6866 for ; Tue, 24 Jun 2008 08:18:29 -0700 (PDT) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20080624152312.NAQT7070.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Tue, 24 Jun 2008 16:23:12 +0100 Received: from darjeeling.procter.org.uk ([81.104.240.101]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20080624152143.UQOQ29365.aamtaout02-winn.ispmail.ntl.com@darjeeling.procter.org.uk>; Tue, 24 Jun 2008 16:21:43 +0100 Received: from localhost ([127.0.0.1] helo=webmail.procter.org.uk ident=www-data) by darjeeling.procter.org.uk with esmtp (Exim 4.50) id 1KBAHr-0001bp-DR; Tue, 24 Jun 2008 16:18:27 +0100 Received: from 87.194.179.229 (SquirrelMail authenticated user michael) by webmail.procter.org.uk with HTTP; Tue, 24 Jun 2008 16:18:27 +0100 (BST) Message-ID: <3470.87.194.179.229.1214320707.squirrel@webmail.procter.org.uk> In-Reply-To: <4860FE00.7030601@cisco.com> References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> Date: Tue, 24 Jun 2008 16:18:27 +0100 (BST) From: "Michael Procter" To: "Paul Kyzivat" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, June 24, 2008 3:00 pm, Paul Kyzivat wrote: > My latest thought is that we should "grandfather" existing uses of INFO. > We would provide a registry of them, without blessing them or > standardizing their specifications. That would at least shine some light > in the dark corners. > > At the same time, we would define the new INFO usage framework (still > TBD) and ban *new* INFO usages that don't follow it. I agree. The framework proposed in draft-kaplan-sip-info-events-01 seems like a step in the right direction. And I agree with registering existing uses. Even if existing uses aren't updated to use the negotiation mechanism suggested (or whatever solution the WG converges on), I think there is value in strongly encouraging the adoption of the 'Info-Package' header (or similar). This shouldn't noticeably affect interop of legacy devices, but marking the requests like this would allow more recent devices to act appropriately in the presence of multiple incompatible non-standard extensions. Not that such things exist, of course! Regards, Michael _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 08:22:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48103A6861; Tue, 24 Jun 2008 08:22:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503C73A6821 for ; Tue, 24 Jun 2008 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, 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 WlIn478bBayn for ; Tue, 24 Jun 2008 08:22:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9539E3A68F5 for ; Tue, 24 Jun 2008 08:22:35 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 78A1B2081F; Tue, 24 Jun 2008 17:22:35 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-cb-4861113b02f8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 594672051F; Tue, 24 Jun 2008 17:22:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 17:23:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 17:23:00 +0200 Message-ID: In-Reply-To: <4860EC06.6080104@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjV9+tCVOxRLYQlS2ufyiCQOM/b8wAFa5cQ References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> <4860E783.3070008@cisco.com> <4860EC06.6080104@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 24 Jun 2008 15:23:02.0198 (UTC) FILETIME=[311DC560:01C8D60E] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, = >>If the proxy assignes its own To-tag, we can't use the To-tag to indciate= which dialog was terminated. > >Right. That was part of my point. In addition, the to-tag it does use crea= tes *another* early dialog. > >>And then, suppose we did allow the proxy to reuse the existing dialog for= the 199, with a new contact. Then the UAC, = >>upon receipt of the 199, will have to send the PRACK within the dialog. S= o the dialog can't be immediately destroyed. = >>When *does* it get destroyed??? When the 200 to the PRACK is received? > >The extra state management and time required to handle this seems to run c= ontrary to the goal of the 199. Correct. >>One option, as proposed by Paul, is to say that a UAC shall be able to RE= CEIVE reliable 199 responses. > >Based on my comments above, I am reconsidering the advisability of that. Well, I guess it wouldn't affect the complexness in the UAC, since it will = have to be able to handle reliable provisional responses anyway (if it indi= cates support of it, that is). And, if the sender of the 199 is a B2BUA, I guess it COULD send it reliably. But, I have no strong feelings regarding this. Regards, Christer > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = > Paul Kyzivat > Sent: 24. kes=E4kuuta 2008 15:25 > To: Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > = > There is a very messy slippery slope here with the reliable 199. > = > I believe we have agreed that the 199 is to have the to-tag used by the U= AS. So conceptually it is *from* the UAS. If you want the proxy to send the= 199 reliably, then it will have to field the response. As others have ment= ioned, this seems to mean that it will have to use its own contact address,= which will be a change from the contact used previously by the UAS for thi= s early dialog. > = > That gives me heartburn - it just seems wrong. Ignoring that, it puts the= 199 into the middle of the open question about changing of contact address= es and how they take effect. > = > This could be addressed by always sending the 199 with a To-tag assigned = by the proxy. But that has its own problems. It actually makes the situatio= n worse for UACs that don't support 199. > = > We sidestep all these problems by not sending the 199 reliably. > = > Maybe we we should say that the UAC must be prepared to handle both relia= ble and unreliable 199, but for now we don't specify any cases when a relia= ble 199 is sent. > = > Another thought - there aren't any issues if the *UAS* sends the 199 reli= ably. But that isn't going to be the common case. > = > Paul > = > Dale.Worley@comcast.net wrote: >> From: "Christer Holmberg" >> >> [CHH] Whether the text should be in the document at all depends on if= we >> allow 199 to be sent reliably in the first place. Based on the commen= ts >> received so far we should not mandate 199 to be sent reliably, even if >> 100rel is required by the UAC. But, the question if whether we want to >> FORBID sending it reliably. >> >> If we ever might allow 199 to be used for HERFP, we should admit the = >> possibility of sending it reliably in the first draft. Otherwise, = >> we'll be locked out of sending it reliably in the future. >> >> Dale >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 08:24:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB093A6861; Tue, 24 Jun 2008 08:24:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E126D3A6824 for ; Tue, 24 Jun 2008 08:24: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 Kc3WUoQ8vECz for ; Tue, 24 Jun 2008 08:24:55 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id 9B63B3A6861 for ; Tue, 24 Jun 2008 08:24:53 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=ijcGZJ22omkDqFHsudxF7K5AgZx4UQWPXGhULWnBX6Fm+mNYTrHMpLb6 tBQbrVRTyURXB2DBr/1EsJmBbB7z/g==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 167989154:10.224.36.65:24 Jun 2008 15:24:52 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.27,695,1204502400"; d="scan'208";a="167989154" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 24 Jun 2008 15:24:15 +0000 Received: from [10.240.32.174] (Forwarded-For: 134.80.13.193, [10.240.32.174]) by mail5.int.ps1.us.army.mil (mshttpd); Tue, 24 Jun 2008 11:24:14 -0400 To: Mary Barnes Message-ID: Date: Tue, 24 Jun 2008 11:24:14 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com> <3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry> <14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com> <485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> Content-Disposition: inline Cc: SIP@ietf.org, Paul Kyzivat Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, all: It appears that we are almost close to have an agreement on this topic. The basic analysis needs to be made why people like to use INFO for so many purposes in SIP. If the WG can abstract those requirements for usages of INFO and can prepare the INFO spec to meet those requirements, there will be no need for "proprietary" usages by vendors. If the WG fails to meet the above requirements, no matter what is done now or in the future will NOT stop the usage of INFO using proprietary schemes. If the past history provide any lessons, it will be a total failure. The bottom line is this: The future INFO spec MUST meet the basic requirements for which people are tempted to sue this in the first place. Best regards, Radhika ----- Original Message ----- From: Mary Barnes Date: Tuesday, June 24, 2008 10:04 Subject: Re: [Sip] INFO and what to do about it? To: Paul Kyzivat Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg > Paul, > > The grandfathering is aa good suggestion and likely far more > pragmaticthan my optimistic approach that they'll evolve. I will > go ahead and > ping our folks and see how they feel about this. If others will > do the > same, I think we'll have some very interesting results. > > Thanks, > Mary > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, June 24, 2008 9:01 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Jonathan Rosenberg; Christer Holmberg; Robert Sparks; > SIP@ietf.org;DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] INFO and what to do about it? > > Mary, > > My latest thought is that we should "grandfather" existing uses of > INFO. > We would provide a registry of them, without blessing them or > standardizing their specifications. That would at least shine some > lightin the dark corners. > > At the same time, we would define the new INFO usage framework (still > TBD) and ban *new* INFO usages that don't follow it. > > I think that would be better than the current situation, and about as > good as we can expect to achieve. > > Thanks, > Paul > > Mary Barnes wrote: > > Just a couple more points of clarification on my view embedded > below > > [MB]. > > > > Mary > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Tuesday, June 24, 2008 8:25 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; > SIP@ietf.org; > > DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] INFO and what to do about it? > > > > > > > > Mary Barnes wrote: > >> I don't believe we could ever forbid INFO. I initially did not > think > >> we could accomplish anything around INFO, but I believe some of > the > >> work that's on the table would be useful for working towards > >> interoperabilty for the INFO usages. I would be afraid to ask > >> honestly > > > >> for the identification of all the different uses of INFO that > are out > > >> there right now. > > > > I don't think we should be afraid of this at all. > > [MB] My guess (based on what I've seen) is that a lot of vendors > would > > have around a half dozen (+- 2). Now, some of those might > overlap > > given there is some level of interop between various vendors. [/MB] > > > > There are (sometimes/often) good reasons why folks resort to > these > > solutions. Our job here at IETF is to ensure interoperability > for the > > SIP protocol. If we don't listen to our customers - the people > who > > have deployed and are actually using it - what purpose does our work > serve? > > > > [MB] My experience is that at least half the uses of INFO were > in > > place when the protocol was quite immature (i.e., well before > RFC > > 3261). And, we indeed should listen to our customers by > providing a > > flexible platform for them to do the things they need to do. > IMHO, > > it's been loud and clear in the past that they want to use INFO > and in > > > the past, docs like "Info considered harmful" weren't helpful > towards > > this end. [/MB] > > > >> Doing something is better than nothing at this point IMHO and > I'm > >> personally really tired of revisiting this issue every couple > of > >> years. AND, this would help us put a stake in the group on the > future > >> usages of INFO (whether we ever get rid of the old usages or > not), as > > >> I believe there are other SDOs defining new uses of INFO right > now to > > >> add to the mix of un-interoperability in this area. > > > > As long as SIP usage continues to rise, I suspect we will > continue to > > see more INFO usages. Just because we cannot fix what is broken > in the > > > past, doesn't mean we should let it remain broken for the future. > > > > [MB] I'm not at all disagreeing on this point. Optimistically, > I'd > > like to see the current implementations evolve to support this > new > > approach as it will improve interoperability. If the WG can > complete > > this work in a timely manner (perhaps the biggest issue given > past > > performance), then the potential for uptake for a standardized > > implementation is INFO is far higher IMHO. If we can get this > work > > chartered, then we're far more likely to get uptake by the other > SDOs > > far sooner than if we continue to dillydally. And, it's > important to > > remember that this isn't the only area where there are > > interoperability issues. And, actually, per SFSIW-1 the use of > INFO > > was not a common theme - either because it was a given or it's > not as > > big an issue as some of us are assuming - in a quick scan I only > found > > one document discussing the use of INFO. [/MB] > > > > -Jonathan R. > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 08:33:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A62E3A69ED; Tue, 24 Jun 2008 08:33:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014883A6866 for ; Tue, 24 Jun 2008 08:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 8AJkcPxOr0fl for ; Tue, 24 Jun 2008 08:33:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 79CE83A69ED for ; Tue, 24 Jun 2008 08:33:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 24 Jun 2008 11:35:00 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 24 Jun 2008 11:32:25 -0400 From: Hadriel Kaplan To: "Elwell, John" , "DRAGE, Keith (Keith)" , "sip@ietf.org" Date: Tue, 24 Jun 2008 11:32:00 -0400 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAETNKsA== Message-ID: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hey John, For the case where the IP-PBX registers into the SP, outbound can be used. But it's the other case I was talking about: where the IP-PBX does NOT register into the SP, but it instead is a trunk. -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, June 24, 2008 3:15 AM > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > Hadriel, > > Concerning your "PBX connections a la SIP trunks" use case, I am not > convinced of this. ETSI TISPAN has specified two ways for an IPPBX to > connect to a service provider. One is the so-called subscription-based > approach, where the IPPBX registers with the SP and communicates via an > edge proxy. In this case, why not use SIP-outbound? The other is the > so-called peering-based approach, which is essentially the same as any > SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway. > SIP-outbound does not apply to these situations, and similarly the > keep-alive mechanism is not specified for this cases. The requirements > in SIP-keep do not cover these situations. > > Basically I am not sold on the idea of a separate SIP-keep spec - I > don't think it would be the best use of WG time. > > John > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Hadriel Kaplan > > Sent: 20 June 2008 18:20 > > To: DRAGE, Keith (Keith); sip@ietf.org > > Cc: Christer Holmberg > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > > > > My 2 cents: it is a useful draft. Personally, I would like > > to have it available for two reasons not cited: PBX > > connections a la SIP trunks, and proxy-proxy connections. > > Today I think a lot of people are using OPTIONS requests or > > proprietary means to perform such keep-alives when > > registration is not appropriate, but it has led to some > > interop issues and performance concerns in some cases. > > > > Since the contentious issue of what form the keep-alives take > > have already been agreed on for outbound, this seems like a > > simple draft to get done. (famous last words, I know) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > DRAGE, Keith (Keith) > > > Sent: Thursday, June 19, 2008 5:31 AM > > > To: sip@ietf.org > > > Cc: Christer Holmberg > > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > > > (As SIP WG cochair) > > > > > > We have been asked by the author of > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > Whether the SIP WG can progress this document. > > > > > > Because this draft arose as a result of the discussion of > > outbound, and > > > indeed seems to reuse the requirements from outbound, and these > > > requirements never really got handled in the SIPPING WG, it has been > > > agreed with the SIPPING chairs that we will handle this > > entirely within > > > SIP. > > > > > > Now in order to ask for charter milestones, and indeed when > > we finally > > > present this to IESG, we will be asked for the level of > > support in the > > > WG, which is also predicated on does this fix a real > > problem, or is it > > > just a corner case with limited application. So: > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to > > > proceed with this draft? The document states: > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > > > defines two keep-alive techniques. Even though the keep-alive > > > techniques are separated from the Outbound mechanism > > > [I-D.ietf-sip-outbound], it is currently not possible to indicate > > > support of the keep-alive techniques without also > > indicating support > > > for the Outbound mechanism. > > > > > > The Outbound mechanism is enabled during the UA > > registration phase. > > > However, there are use-cases where the UA does not > > register itself, > > > but still needs to be able to make calls and maintain > > NAT bindings > > > open during the duration of that call. A typical example is > > > emergency calls. There are also cases where entities do > > not support > > > the Outbound mechanism, but still want to be able to > > indicate support > > > and use the keep-alive techniques defined in > > [I-D.ietf-sip-outbound]. > > > > > > At first sight this is not the most inspiring declaration > > of the need > > > for the document. Please respond indicating whether you > > consider this a > > > useful draft, and propose text that you think would be > > useful in this > > > section. Conversely, if you think this draft is not useful > > and the WG > > > has other more important things to work on first, please > > also respond. > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for > > > proceeding with this work? The document currently lists: > > > > > > REQ 1: It MUST be possible for a UA to indicate support > > of the keep- > > > alive techniques defined [I-D.ietf-sip-outbound] if the > > UA supports > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > REQ 2: It MUST be possible for an edge proxy to indicate > > support of > > > the keep-alive techniques defined > > [I-D.ietf-sip-outbound] if the edge > > > poxy supports only the keep-alive part of > > [I-D.ietf-sip-outbound]. > > > > > > It would be desirable to agree these at the outset, and not > > revisit them > > > if we continue with the work. So if you require clarification, > > > modification, or addition to these two requirements, then > > please also > > > response with your questions and proposals. > > > > > > I suggest we would like responses by 30th June 2008 in > > order to allow > > > the author to revise the document before the deadlines. > > Please note that > > > we are looking to make this decision on the list within > > this deadline > > > based on responses received, not leave it until the Dublin meeting. > > > > > > Regards > > > > > > Keith > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 08:48:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3EDA3A69A9; Tue, 24 Jun 2008 08:48:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C6C3A6866 for ; Tue, 24 Jun 2008 08:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 G1u5gnxWyqyc for ; Tue, 24 Jun 2008 08:48:31 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2FF2E3A6852 for ; Tue, 24 Jun 2008 08:48:31 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K2Z00D5658VV9@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Jun 2008 16:48:31 +0100 (BST) Date: Tue, 24 Jun 2008 16:48:29 +0100 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , "DRAGE, Keith (Keith)" , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E384@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAETNKsAAA+WlQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, That trunking case is no different from other trunking cases, e.g., proxy-to-proxy, and I have already suggested to Christer that he might extend the scope of the draft to cover that. It would be good to have some discussion on whether keep-alive on "trunking" interfaces would be beneficial - I have an open mind on that at present. John > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 24 June 2008 16:32 > To: Elwell, John; DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > Hey John, > For the case where the IP-PBX registers into the SP, outbound > can be used. But it's the other case I was talking about: > where the IP-PBX does NOT register into the SP, but it > instead is a trunk. > > -hadriel > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Tuesday, June 24, 2008 3:15 AM > > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > > Cc: Christer Holmberg > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > Hadriel, > > > > Concerning your "PBX connections a la SIP trunks" use case, I am not > > convinced of this. ETSI TISPAN has specified two ways for > an IPPBX to > > connect to a service provider. One is the so-called > subscription-based > > approach, where the IPPBX registers with the SP and > communicates via an > > edge proxy. In this case, why not use SIP-outbound? The other is the > > so-called peering-based approach, which is essentially the > same as any > > SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway. > > SIP-outbound does not apply to these situations, and similarly the > > keep-alive mechanism is not specified for this cases. The > requirements > > in SIP-keep do not cover these situations. > > > > Basically I am not sold on the idea of a separate SIP-keep spec - I > > don't think it would be the best use of WG time. > > > > John > > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of Hadriel Kaplan > > > Sent: 20 June 2008 18:20 > > > To: DRAGE, Keith (Keith); sip@ietf.org > > > Cc: Christer Holmberg > > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > > My 2 cents: it is a useful draft. Personally, I would like > > > to have it available for two reasons not cited: PBX > > > connections a la SIP trunks, and proxy-proxy connections. > > > Today I think a lot of people are using OPTIONS requests or > > > proprietary means to perform such keep-alives when > > > registration is not appropriate, but it has led to some > > > interop issues and performance concerns in some cases. > > > > > > Since the contentious issue of what form the keep-alives take > > > have already been agreed on for outbound, this seems like a > > > simple draft to get done. (famous last words, I know) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of > > > > DRAGE, Keith (Keith) > > > > Sent: Thursday, June 19, 2008 5:31 AM > > > > To: sip@ietf.org > > > > Cc: Christer Holmberg > > > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > (As SIP WG cochair) > > > > > > > > We have been asked by the author of > > > > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > > > Whether the SIP WG can progress this document. > > > > > > > > Because this draft arose as a result of the discussion of > > > outbound, and > > > > indeed seems to reuse the requirements from outbound, and these > > > > requirements never really got handled in the SIPPING > WG, it has been > > > > agreed with the SIPPING chairs that we will handle this > > > entirely within > > > > SIP. > > > > > > > > Now in order to ask for charter milestones, and indeed when > > > we finally > > > > present this to IESG, we will be asked for the level of > > > support in the > > > > WG, which is also predicated on does this fix a real > > > problem, or is it > > > > just a corner case with limited application. So: > > > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > important to > > > > proceed with this draft? The document states: > > > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 > [I-D.ietf-sip-outbound] > > > > defines two keep-alive techniques. Even though the > keep-alive > > > > techniques are separated from the Outbound mechanism > > > > [I-D.ietf-sip-outbound], it is currently not > possible to indicate > > > > support of the keep-alive techniques without also > > > indicating support > > > > for the Outbound mechanism. > > > > > > > > The Outbound mechanism is enabled during the UA > > > registration phase. > > > > However, there are use-cases where the UA does not > > > register itself, > > > > but still needs to be able to make calls and maintain > > > NAT bindings > > > > open during the duration of that call. A typical example is > > > > emergency calls. There are also cases where entities do > > > not support > > > > the Outbound mechanism, but still want to be able to > > > indicate support > > > > and use the keep-alive techniques defined in > > > [I-D.ietf-sip-outbound]. > > > > > > > > At first sight this is not the most inspiring declaration > > > of the need > > > > for the document. Please respond indicating whether you > > > consider this a > > > > useful draft, and propose text that you think would be > > > useful in this > > > > section. Conversely, if you think this draft is not useful > > > and the WG > > > > has other more important things to work on first, please > > > also respond. > > > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of > requirements for > > > > proceeding with this work? The document currently lists: > > > > > > > > REQ 1: It MUST be possible for a UA to indicate support > > > of the keep- > > > > alive techniques defined [I-D.ietf-sip-outbound] if the > > > UA supports > > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > > > REQ 2: It MUST be possible for an edge proxy to indicate > > > support of > > > > the keep-alive techniques defined > > > [I-D.ietf-sip-outbound] if the edge > > > > poxy supports only the keep-alive part of > > > [I-D.ietf-sip-outbound]. > > > > > > > > It would be desirable to agree these at the outset, and not > > > revisit them > > > > if we continue with the work. So if you require clarification, > > > > modification, or addition to these two requirements, then > > > please also > > > > response with your questions and proposals. > > > > > > > > I suggest we would like responses by 30th June 2008 in > > > order to allow > > > > the author to revise the document before the deadlines. > > > Please note that > > > > we are looking to make this decision on the list within > > > this deadline > > > > based on responses received, not leave it until the > Dublin meeting. > > > > > > > > Regards > > > > > > > > Keith > > > > _______________________________________________ > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > application of sip > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 09:07:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C673A6951; Tue, 24 Jun 2008 09:07:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A011E3A6951 for ; Tue, 24 Jun 2008 09:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0AbhplD3Tjs for ; Tue, 24 Jun 2008 09:07:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 66F6D3A68E4 for ; Tue, 24 Jun 2008 09:07:48 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OG7lni017260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 11:07:49 -0500 Message-Id: From: Dean Willis To: Mayumi Munakata In-Reply-To: <4860D2E4.10109@ntt-at.co.jp> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 11:07:42 -0500 References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <4860D2E4.10109@ntt-at.co.jp> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 5:56 AM, Mayumi Munakata wrote: > Dean, > > Dean Willis wrote: > >> draft-ietf-sip-ua-privacy > > > > -- This one is done, > > You might misunderstand the situation of ua-privacy, > but I am still working on that work, and will submit > a new version in a week or so. > > An open issue regarding a From header > (what kind of anonymous URI to be set) > was solved in Philadelphia and now I am > studying the treatment of other headers. > Ah. I had in fact thought that the From header issue was the main issue remaining, and that we had resolved it. Some sort of incremental discussion of the remaining open issues to the mailing list would be very helpful in building us towards a consensus. There's no need to wait for a meeting to discuss most technical issues. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 09:11:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4513A69ED; Tue, 24 Jun 2008 09:11:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4116E3A69ED for ; Tue, 24 Jun 2008 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 PgKLJLt0Hn7V for ; Tue, 24 Jun 2008 09:11:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C74D83A682A for ; Tue, 24 Jun 2008 09:11:37 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 24 Jun 2008 12:13:26 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 24 Jun 2008 12:10:35 -0400 From: Hadriel Kaplan To: "Elwell, John" , "DRAGE, Keith (Keith)" , "sip@ietf.org" Date: Tue, 24 Jun 2008 12:11:21 -0400 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAETNKsAAA+WlQAACwqdA= Message-ID: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E384@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E384@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Those cases are the ones I said would be useful in my original email far below. I.e., when I said "two reasons not cited: PBX connections a la SIP trunks, and proxy-proxy connections." They are not identical, in the sense that an IP-PBX can be a b2bua/UA/whatever, but also in the sense of their example use-case, for example an IP-PBX could be behind a NAT and thus want this keep-alive for more reasons than a proxy-proxy. -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, June 24, 2008 11:48 AM > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > Hadriel, > > That trunking case is no different from other trunking cases, e.g., > proxy-to-proxy, and I have already suggested to Christer that he might > extend the scope of the draft to cover that. It would be good to have > some discussion on whether keep-alive on "trunking" interfaces would be > beneficial - I have an open mind on that at present. > > John > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: 24 June 2008 16:32 > > To: Elwell, John; DRAGE, Keith (Keith); sip@ietf.org > > Cc: Christer Holmberg > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > Hey John, > > For the case where the IP-PBX registers into the SP, outbound > > can be used. But it's the other case I was talking about: > > where the IP-PBX does NOT register into the SP, but it > > instead is a trunk. > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Tuesday, June 24, 2008 3:15 AM > > > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > > > Cc: Christer Holmberg > > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > > > Hadriel, > > > > > > Concerning your "PBX connections a la SIP trunks" use case, I am not > > > convinced of this. ETSI TISPAN has specified two ways for > > an IPPBX to > > > connect to a service provider. One is the so-called > > subscription-based > > > approach, where the IPPBX registers with the SP and > > communicates via an > > > edge proxy. In this case, why not use SIP-outbound? The other is the > > > so-called peering-based approach, which is essentially the > > same as any > > > SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway. > > > SIP-outbound does not apply to these situations, and similarly the > > > keep-alive mechanism is not specified for this cases. The > > requirements > > > in SIP-keep do not cover these situations. > > > > > > Basically I am not sold on the idea of a separate SIP-keep spec - I > > > don't think it would be the best use of WG time. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > > Behalf Of Hadriel Kaplan > > > > Sent: 20 June 2008 18:20 > > > > To: DRAGE, Keith (Keith); sip@ietf.org > > > > Cc: Christer Holmberg > > > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > > > > > My 2 cents: it is a useful draft. Personally, I would like > > > > to have it available for two reasons not cited: PBX > > > > connections a la SIP trunks, and proxy-proxy connections. > > > > Today I think a lot of people are using OPTIONS requests or > > > > proprietary means to perform such keep-alives when > > > > registration is not appropriate, but it has led to some > > > > interop issues and performance concerns in some cases. > > > > > > > > Since the contentious issue of what form the keep-alives take > > > > have already been agreed on for outbound, this seems like a > > > > simple draft to get done. (famous last words, I know) > > > > > > > > -hadriel > > > > > > > > > > > > > -----Original Message----- > > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > > Behalf Of > > > > > DRAGE, Keith (Keith) > > > > > Sent: Thursday, June 19, 2008 5:31 AM > > > > > To: sip@ietf.org > > > > > Cc: Christer Holmberg > > > > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > > > (As SIP WG cochair) > > > > > > > > > > We have been asked by the author of > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > > > > > Whether the SIP WG can progress this document. > > > > > > > > > > Because this draft arose as a result of the discussion of > > > > outbound, and > > > > > indeed seems to reuse the requirements from outbound, and these > > > > > requirements never really got handled in the SIPPING > > WG, it has been > > > > > agreed with the SIPPING chairs that we will handle this > > > > entirely within > > > > > SIP. > > > > > > > > > > Now in order to ask for charter milestones, and indeed when > > > > we finally > > > > > present this to IESG, we will be asked for the level of > > > > support in the > > > > > WG, which is also predicated on does this fix a real > > > > problem, or is it > > > > > just a corner case with limited application. So: > > > > > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > > important to > > > > > proceed with this draft? The document states: > > > > > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 > > [I-D.ietf-sip-outbound] > > > > > defines two keep-alive techniques. Even though the > > keep-alive > > > > > techniques are separated from the Outbound mechanism > > > > > [I-D.ietf-sip-outbound], it is currently not > > possible to indicate > > > > > support of the keep-alive techniques without also > > > > indicating support > > > > > for the Outbound mechanism. > > > > > > > > > > The Outbound mechanism is enabled during the UA > > > > registration phase. > > > > > However, there are use-cases where the UA does not > > > > register itself, > > > > > but still needs to be able to make calls and maintain > > > > NAT bindings > > > > > open during the duration of that call. A typical example is > > > > > emergency calls. There are also cases where entities do > > > > not support > > > > > the Outbound mechanism, but still want to be able to > > > > indicate support > > > > > and use the keep-alive techniques defined in > > > > [I-D.ietf-sip-outbound]. > > > > > > > > > > At first sight this is not the most inspiring declaration > > > > of the need > > > > > for the document. Please respond indicating whether you > > > > consider this a > > > > > useful draft, and propose text that you think would be > > > > useful in this > > > > > section. Conversely, if you think this draft is not useful > > > > and the WG > > > > > has other more important things to work on first, please > > > > also respond. > > > > > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of > > requirements for > > > > > proceeding with this work? The document currently lists: > > > > > > > > > > REQ 1: It MUST be possible for a UA to indicate support > > > > of the keep- > > > > > alive techniques defined [I-D.ietf-sip-outbound] if the > > > > UA supports > > > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > > > > > REQ 2: It MUST be possible for an edge proxy to indicate > > > > support of > > > > > the keep-alive techniques defined > > > > [I-D.ietf-sip-outbound] if the edge > > > > > poxy supports only the keep-alive part of > > > > [I-D.ietf-sip-outbound]. > > > > > > > > > > It would be desirable to agree these at the outset, and not > > > > revisit them > > > > > if we continue with the work. So if you require clarification, > > > > > modification, or addition to these two requirements, then > > > > please also > > > > > response with your questions and proposals. > > > > > > > > > > I suggest we would like responses by 30th June 2008 in > > > > order to allow > > > > > the author to revise the document before the deadlines. > > > > Please note that > > > > > we are looking to make this decision on the list within > > > > this deadline > > > > > based on responses received, not leave it until the > > Dublin meeting. > > > > > > > > > > Regards > > > > > > > > > > Keith > > > > > _______________________________________________ > > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > _______________________________________________ > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 09:11:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A2028C119; Tue, 24 Jun 2008 09:11:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C19028C119 for ; Tue, 24 Jun 2008 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 Jwqu4ubsI8eB for ; Tue, 24 Jun 2008 09:11:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2989D28C10F for ; Tue, 24 Jun 2008 09:11:45 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OGBcIn017294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 11:11:40 -0500 Message-Id: <7237141A-1E4D-4F39-8B76-AC6D9D267505@softarmor.com> From: Dean Willis To: "Jesske, R" In-Reply-To: <9886E5FCA6D76549A3011068483A4BD402CA8686@S4DE8PSAAQB.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 11:11:33 -0500 References: <9886E5FCA6D76549A3011068483A4BD402CA8686@S4DE8PSAAQB.mitte.t-com.de> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 10:07 AM, Jesske, R wrote: > Dear all, > what is the status of this draft? We are trying to determine whether there is a constituency for the draft that justifies further WG effort in advancing it. > Will there be some consideration of this proposal of defining a keep > parameter? Yes, that's one of the conversations we're having now. > will this possibly incorporated into draft-ietf-sip-outbound? > No. It's more or less been split off from "outbound". Were I to do this all over again, I would have separated out the keepalive function from outbound early on. But we didn't, and outbound is pretty much done. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 09:52:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6133A6961; Tue, 24 Jun 2008 09:52:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8D83A68E5 for ; Tue, 24 Jun 2008 09:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgGfFIiLfwA4 for ; Tue, 24 Jun 2008 09:52:43 -0700 (PDT) Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id BAC843A6894 for ; Tue, 24 Jun 2008 09:52:42 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5OGqRFK014088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2008 11:52:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> From: Robert Sparks To: Paul Kyzivat In-Reply-To: <4860FE00.7030601@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 11:52:26 -0500 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.1/7550/Tue Jun 24 09:52:37 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline On Jun 24, 2008, at 9:00 AM, Paul Kyzivat wrote: > Mary, > > My latest thought is that we should "grandfather" existing uses of > INFO. We would provide a registry of them, without blessing them or > standardizing their specifications. That would at least shine some > light in the dark corners. > > At the same time, we would define the new INFO usage framework > (still TBD) and ban *new* INFO usages that don't follow it. Well, if we don't think banning INFO as a whole would be listened to, why do we think banning INFO that doesn't use this new framework would be listened to? That's where I'm having difficulty with the question. I can see the bite of work it would take to make the framework. I'm still trying to see what would actually use it if we did? Can somebody list the packages that we've already identified that we would put out with this framework? > > > I think that would be better than the current situation, and about > as good as we can expect to achieve. I'm still not convinced it makes it better. One outcome I can see from following this path is two years from now finding ourselves with no actual packages using the framework and a set of _new_ INFO based applications in the field that _don't_ use the framework. Will we continue to put those in this proposed registry above? Or do we just have another set of practices that we have to treat the current non-standardized INFO uses with now? The bet we would be placing by putting the work into creating this framework is that it actually takes some motivation away from using a non-standard bare INFO to realize some new application (and that there are new applications out there where this would be a really good tool to have to realize them). Is this framework really lowering a barrier to entry or relieving some other pain so that the people who would otherwise make a new non-standard use of INFO come use it? I'm having a really hard time seeing that. If we end up on the wrong side of that bet, we've arguably made things _worse_ taking work away from other things, creating mechanics that have to be implemented, tested and will ultimately be abused, and not solving the actual problem in the first place. So, I'll continue to look for some evidence this will actually get used and relieves some pressure to just go use INFO in a proprietary way and skip all this standards pain (hopefully folks here can help me with this). Without it, I think the better path would be to create the registry you describe, publish an informational document pointing out the pitfalls of the approaches they take, and get on with other work. I'll also, of course, accept a community decision to just do this work and take the risk of losing the bet and help make sure we build the best framework possible if that's where we really want to go. I just hope somebody can convince me we're not trading off other work we could be benefiting from more to find ourselves in effectively the same position two years from now. RjS > > > Thanks, > Paul > > Mary Barnes wrote: >> Just a couple more points of clarification on my view embedded below >> [MB]. >> Mary >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Tuesday, >> June 24, 2008 8:25 AM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; SIP@ietf.org; >> DOLLY, >> MARTIN C, ATTLABS >> Subject: Re: [Sip] INFO and what to do about it? >> Mary Barnes wrote: >>> I don't believe we could ever forbid INFO. I initially did not >>> think we could accomplish anything around INFO, but I believe some >>> of the work that's on the table would be useful for working >>> towards interoperabilty for the INFO usages. I would be afraid to >>> ask honestly >>> for the identification of all the different uses of INFO that are >>> out there right now. >> I don't think we should be afraid of this at all. >> [MB] My guess (based on what I've seen) is that a lot of vendors >> would >> have around a half dozen (+- 2). Now, some of those might overlap >> given >> there is some level of interop between various vendors. [/MB] >> There are (sometimes/often) good reasons why folks resort to these >> solutions. Our job here at IETF is to ensure interoperability for the >> SIP protocol. If we don't listen to our customers - the people who >> have >> deployed and are actually using it - what purpose does our work >> serve? >> [MB] My experience is that at least half the uses of INFO were in >> place >> when the protocol was quite immature (i.e., well before RFC 3261). >> And, >> we indeed should listen to our customers by providing a flexible >> platform for them to do the things they need to do. IMHO, it's been >> loud >> and clear in the past that they want to use INFO and in the past, >> docs >> like "Info considered harmful" weren't helpful towards this end. [/ >> MB] >>> Doing something is better than nothing at this point IMHO and I'm >>> personally really tired of revisiting this issue every couple of >>> years. AND, this would help us put a stake in the group on the >>> future usages of INFO (whether we ever get rid of the old usages >>> or not), as I believe there are other SDOs defining new uses of >>> INFO right now to add to the mix of un-interoperability in this >>> area. >> As long as SIP usage continues to rise, I suspect we will continue to >> see more INFO usages. Just because we cannot fix what is broken in >> the >> past, doesn't mean we should let it remain broken for the future. >> [MB] I'm not at all disagreeing on this point. Optimistically, I'd >> like >> to see the current implementations evolve to support this new >> approach >> as it will improve interoperability. If the WG can complete this >> work in >> a timely manner (perhaps the biggest issue given past performance), >> then >> the potential for uptake for a standardized implementation is INFO is >> far higher IMHO. If we can get this work chartered, then we're far >> more >> likely to get uptake by the other SDOs far sooner than if we >> continue to >> dillydally. And, it's important to remember that this isn't the only >> area where there are interoperability issues. And, actually, per >> SFSIW-1 >> the use of INFO was not a common theme - either because it was a >> given >> or it's not as big an issue as some of us are assuming - in a quick >> scan >> I only found one document discussing the use of INFO. [/MB] >> -Jonathan R. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 10:11:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A033A6945; Tue, 24 Jun 2008 10:11:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000AA3A6972 for ; Tue, 24 Jun 2008 10:11:24 -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 QlHncIQ5Ti1A for ; Tue, 24 Jun 2008 10:11:24 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by core3.amsl.com (Postfix) with ESMTP id C5DE33A68EA for ; Tue, 24 Jun 2008 10:11:21 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP; Tue, 24 Jun 2008 10:11:20 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m5OH7sG3000308; Tue, 24 Jun 2008 10:07:55 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m5OHBDqJ011067; Tue, 24 Jun 2008 10:11:14 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 10:11:13 -0700 Received: from 10.58.20.192 ([10.58.20.192]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 17:11:12 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 10:11:11 -0700 From: Henry Sinnreich To: Jonathan Rosenberg , Mary Barnes Message-ID: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjWHUy+28G+LymB1Uu2XoX0i15l6w== In-Reply-To: <4860F5B6.2060307@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 17:11:13.0392 (UTC) FILETIME=[4E2B5F00:01C8D61D] Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Paul Kyzivat , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >If we don't listen to our customers - the people who have > deployed and are actually using it - what purpose does our work serve? This is what the managers of the typewriter business must have said when the word processors appeared: "Our customers ask for a white-out ribbon and for a price under $500." A PC at that time cost $5,000 and the additional laser printer was another $5,000. Some companies opted for the PC business nevertheless and did NOT listen to their customers. Does anyone care for simple SIP that can be understood by developers with limited time on their hands? Henry On 6/24/08 6:25 AM, "Jonathan Rosenberg" wrote: > > > Mary Barnes wrote: >> I don't believe we could ever forbid INFO. I initially did not think >> we could accomplish anything around INFO, but I believe some of the >> work that's on the table would be useful for working towards >> interoperabilty for the INFO usages. I would be afraid to ask >> honestly for the identification of all the different uses of INFO >> that are out there right now. > > I don't think we should be afraid of this at all. > > There are (sometimes/often) good reasons why folks resort to these > solutions. Our job here at IETF is to ensure interoperability for the > SIP protocol. If we don't listen to our customers - the people who have > deployed and are actually using it - what purpose does our work serve? > > >> >> Doing something is better than nothing at this point IMHO and I'm >> personally really tired of revisiting this issue every couple of >> years. AND, this would help us put a stake in the group on the future >> usages of INFO (whether we ever get rid of the old usages or not), as >> I believe there are other SDOs defining new uses of INFO right now to >> add to the mix of un-interoperability in this area. > > As long as SIP usage continues to rise, I suspect we will continue to > see more INFO usages. Just because we cannot fix what is broken in the > past, doesn't mean we should let it remain broken for the future. > > -Jonathan R. > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 10:22:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E043A67E7; Tue, 24 Jun 2008 10:22:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8E33A67E7 for ; Tue, 24 Jun 2008 10:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 N0prQmDSWgBA for ; Tue, 24 Jun 2008 10:22:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 021753A6783 for ; Tue, 24 Jun 2008 10:22:06 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OHLlFh017754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 12:21:49 -0500 Message-Id: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> From: Dean Willis To: sip@ietf.org, Eric Rescorla , Jason Fischl Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 12:21:41 -0500 X-Mailer: Apple Mail (2.924) Cc: Cullen Jennings , Keith Drage Subject: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gateway deadlock X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We've gotten stuck on a fine point in DTLS-SRTP. The current draft-ietf-sip-dtls-srtp-framework-01 uses an RFC 4474 Identity header to preserve the integrity of the media key's fingerprint, thereby detecting a certain class of MITM attack. However, RFC 4474 Identity headers are of questionable validity when used with protocol gateways or B2BUAs. More or less, they're capable of asserting the identity of the gateway, not the identity of the calling party. But the recipient has no real way to figure out which is which. We've debated at some length, and with no good result, about whether we should try and fix RFC 4474. We've had some suggestions that may work for B2BUAs, and some other suggestions that may work for gateways, but we certainly don't have a consensus. That leaves our chartered deliverable of DTLS-SRTP hanging, and the milestone has gone past months ago. Here's a proposal: We add a caveat about the limitation of RFC 4474 to draft-ietf-sip- dtls-srtp-framework and go ahead and advance that specification. If somebody later decides to fix RFC 4474, they can do so, and if necessary update DTLS-SRTP if needed. Does that work for everybody? If we agree to it, I suggest that we move the date for WGLC of draft- ietf-sip-dtls-srtp-framework to July 2008, and move the milestone for delivery of that doc to the IESG into September. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 10:34:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8286D3A683C; Tue, 24 Jun 2008 10:34:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB743A68C3 for ; Tue, 24 Jun 2008 10:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN52gX--XnP8 for ; Tue, 24 Jun 2008 10:34:30 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A19433A6829 for ; Tue, 24 Jun 2008 10:34:30 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m5OHYRG4017224; Tue, 24 Jun 2008 11:34:27 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 24 Jun 2008 11:34:27 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 11:33:44 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6012168E4@srvxchg3.cablelabs.com> In-Reply-To: <1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjWGsp8hAfWtG3JTZu9gFNht6S2hAAAd9fg References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com><807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com><4860F5B6.2060307@cisco.com><4860FE00.7030601@cisco.com> <1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> From: "Jean-Francois Mule" To: "Robert Sparks" , "Paul Kyzivat" X-Approved: ondar Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've been reading this thread and so far, it seems that folks are recommending one or more of the following approaches: 1) do nothing 2) document what's out there in some ways (as informational or a new class of WCP RFCs, worst-current-practices) 3) define new framework for info (as part of the standard track) Eric's info draft-02 intended to obsolete 2976 and still showing intended status as standard track. The intended audience is both implementers and users (end-users, enterprise, operators). --- implementers I believe implementers are faced with a basic problem when deciding what to implement: what other vendor products is my implementation supposed to interoperate with? Is that other implementation in my customer's hands. If so, what is that other vendor implementing for this pseudo-info functionality. Correct me if I'm wrong but I think this often leads to the INFO path for all the uses Eric documented. Even if an implementer argues that KPML should be used to pass digits on the signaling path, if the customer has a box that has INFO for that, they will likely do info and argue later because there is often little room for a user/operator to ask for an upgrade of the already deployed box for a new entrant. => implementers' vote count and what would they choose? Likely: 1 (because they don't care, those hacks get driven by customers to interwork with existing gears or they build products in between UAs...) 2 (because they'd like to avoid defining yet a new hack and would rather code an INFO mechanism to address the maximum number of implementations out there) Other Opinions? --- users While some architects push for pure standard solutions, the reality is often darker. Users have often a service or application goal and if it takes an INFO to get the job done given a box in the field, so be it. They will try to ask for better solutions in upcoming releases (some of which never address the INFO hacks which is the problem). => users' opinion count and what would they choose? Likely: 2 (because they'd like to point to a document and say: I use this as my UA on my PC/network, and it supports INFO as defined by that doc section X.Y). Other Opinions? 2 seems at a first sight to be the best worst thing to do. But doing 2 is a slippery slope for the IETF though: is INFO worth it? What about the call diversion headers we can't seem to get rid of in favor of the their alternative standard-track mechanisms? It would be good to see a more detailed draft documenting the uses of INFO (with actual snippets) and some rational numbers indicating how many implementers (& releases of their code) support those, and how many users have those. That could be beneficial to just discuss what to do, if anything. Jean-Francois. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf > Of Robert Sparks > Sent: Tuesday, June 24, 2008 10:52 AM > To: Paul Kyzivat > Cc: SIP@ietf.org; DOLLY, MARTIN C, ATTLABS; Mary Barnes; Christer > Holmberg > Subject: Re: [Sip] INFO and what to do about it? > > inline > > On Jun 24, 2008, at 9:00 AM, Paul Kyzivat wrote: > > > Mary, > > > > My latest thought is that we should "grandfather" existing uses > of > > INFO. We would provide a registry of them, without blessing them > or > > standardizing their specifications. That would at least shine > some > > light in the dark corners. > > > > At the same time, we would define the new INFO usage framework > > (still TBD) and ban *new* INFO usages that don't follow it. > > Well, if we don't think banning INFO as a whole would be listened > to, > why do we think banning INFO that doesn't use this new framework > would > be listened to? > > That's where I'm having difficulty with the question. I can see the > bite of work it would take to make the framework. > I'm still trying to see what would actually use it if we did? > Can somebody list the packages that we've already identified that > we > would put out with this framework? > > > > > > > I think that would be better than the current situation, and > about > > as good as we can expect to achieve. > > I'm still not convinced it makes it better. One outcome I can see > from > following this path is two years from now finding ourselves with no > actual packages using the framework and a set of _new_ INFO based > applications in the field that _don't_ use the framework. > > Will we continue to put those in this proposed registry above? Or > do > we just have another set of practices that we have to treat the > current non-standardized INFO uses with now? > > The bet we would be placing by putting the work into creating this > framework is that it actually takes some motivation away from using > a > non-standard bare INFO to realize some new application (and that > there > are new applications out there where this would be a really good > tool > to have to realize them). Is this framework really lowering a > barrier > to entry or relieving some other pain so that the people who would > otherwise make a new non-standard use of INFO come use it? I'm > having > a really hard time seeing that. > > If we end up on the wrong side of that bet, we've arguably made > things > _worse_ taking work away from other things, creating mechanics that > have to be implemented, tested and will ultimately be abused, and > not > solving the actual problem in the first place. > > So, I'll continue to look for some evidence this will actually get > used and relieves some pressure to just go use INFO in a > proprietary > way and skip all this standards pain (hopefully folks here can help > me > with this). > > Without it, I think the better path would be to create the registry > you describe, publish an informational document pointing out the > pitfalls of the approaches they take, and get on with other work. > > I'll also, of course, accept a community decision to just do this > work > and take the risk of losing the bet and help make sure we build the > best framework possible if that's where we really want to go. I > just > hope somebody can convince me we're not trading off other work we > could be benefiting from more to find ourselves in effectively the > same position two years from now. > > RjS > > > > > > > > Thanks, > > Paul > > > > Mary Barnes wrote: > >> Just a couple more points of clarification on my view embedded > below > >> [MB]. > >> Mary > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: > Tuesday, > >> June 24, 2008 8:25 AM > >> To: Barnes, Mary (RICH2:AR00) > >> Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; > SIP@ietf.org; > >> DOLLY, > >> MARTIN C, ATTLABS > >> Subject: Re: [Sip] INFO and what to do about it? > >> Mary Barnes wrote: > >>> I don't believe we could ever forbid INFO. I initially did not > >>> think we could accomplish anything around INFO, but I believe > some > >>> of the work that's on the table would be useful for working > >>> towards interoperabilty for the INFO usages. I would be afraid > to > >>> ask honestly > >>> for the identification of all the different uses of INFO that > are > >>> out there right now. > >> I don't think we should be afraid of this at all. > >> [MB] My guess (based on what I've seen) is that a lot of vendors > >> would > >> have around a half dozen (+- 2). Now, some of those might > overlap > >> given > >> there is some level of interop between various vendors. [/MB] > >> There are (sometimes/often) good reasons why folks resort to > these > >> solutions. Our job here at IETF is to ensure interoperability > for the > >> SIP protocol. If we don't listen to our customers - the people > who > >> have > >> deployed and are actually using it - what purpose does our work > >> serve? > >> [MB] My experience is that at least half the uses of INFO were > in > >> place > >> when the protocol was quite immature (i.e., well before RFC > 3261). > >> And, > >> we indeed should listen to our customers by providing a flexible > >> platform for them to do the things they need to do. IMHO, it's > been > >> loud > >> and clear in the past that they want to use INFO and in the > past, > >> docs > >> like "Info considered harmful" weren't helpful towards this end. > [/ > >> MB] > >>> Doing something is better than nothing at this point IMHO and > I'm > >>> personally really tired of revisiting this issue every couple > of > >>> years. AND, this would help us put a stake in the group on the > >>> future usages of INFO (whether we ever get rid of the old > usages > >>> or not), as I believe there are other SDOs defining new uses of > >>> INFO right now to add to the mix of un-interoperability in this > >>> area. > >> As long as SIP usage continues to rise, I suspect we will > continue to > >> see more INFO usages. Just because we cannot fix what is broken > in > >> the > >> past, doesn't mean we should let it remain broken for the > future. > >> [MB] I'm not at all disagreeing on this point. Optimistically, > I'd > >> like > >> to see the current implementations evolve to support this new > >> approach > >> as it will improve interoperability. If the WG can complete this > >> work in > >> a timely manner (perhaps the biggest issue given past > performance), > >> then > >> the potential for uptake for a standardized implementation is > INFO is > >> far higher IMHO. If we can get this work chartered, then we're > far > >> more > >> likely to get uptake by the other SDOs far sooner than if we > >> continue to > >> dillydally. And, it's important to remember that this isn't the > only > >> area where there are interoperability issues. And, actually, per > >> SFSIW-1 > >> the use of INFO was not a common theme - either because it was a > >> given > >> or it's not as big an issue as some of us are assuming - in a > quick > >> scan > >> I only found one document discussing the use of INFO. [/MB] > >> -Jonathan R. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 10:47:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CDF3A6912; Tue, 24 Jun 2008 10:47:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B24E3A6912 for ; Tue, 24 Jun 2008 10:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.677 X-Spam-Level: X-Spam-Status: No, score=-6.677 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 JKnOYXyA6BzL for ; Tue, 24 Jun 2008 10:46:59 -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 A653F3A6842 for ; Tue, 24 Jun 2008 10:46:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,697,1204520400"; d="scan'208";a="12070610" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Jun 2008 13:47:00 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5OHl0Km004382; Tue, 24 Jun 2008 13:47:00 -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.13.8) with ESMTP id m5OHl0DG008883; Tue, 24 Jun 2008 17:47:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 13:47:00 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 13:46:59 -0400 Message-ID: <48613342.3050504@cisco.com> Date: Tue, 24 Jun 2008 13:47:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Michael Procter References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> <3470.87.194.179.229.1214320707.squirrel@webmail.procter.org.uk> In-Reply-To: <3470.87.194.179.229.1214320707.squirrel@webmail.procter.org.uk> X-OriginalArrivalTime: 24 Jun 2008 17:46:59.0786 (UTC) FILETIME=[4D851AA0:01C8D622] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1708; t=1214329620; x=1215193620; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20 |To:=20Michael=20Procter=20; bh=28F2LICsextC8oa0Vm9X4iGAeoS/S+feonULKTMxrCM=; b=VDSWjn1XBk/j5clPi5sh3usGxqIcArvKiQ8Yfa/LdaLGUdB3Pb9JdAZrmE 386f8lRJBbEB+hUcLX2Z0Yw9wQjbRGPvuopGYX74jGJzZrlpAA+j8MZeboXW AhCJj8M7sp; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Let me be clear: for the grandfathering part, I am suggesting that we develop a registry of *existing* usage, not that those existing usages change in any way. I want to get them written down, so at least there is a place to look to find out about something unknown to you, and to ensure nothing new gets defined that is in conflict with something old. If those existing usages can be updated to use the new framework that would be better yet. But I'm not going to hold my breath waiting for that to happen. Paul Michael Procter wrote: > On Tue, June 24, 2008 3:00 pm, Paul Kyzivat wrote: >> My latest thought is that we should "grandfather" existing uses of INFO. >> We would provide a registry of them, without blessing them or >> standardizing their specifications. That would at least shine some light >> in the dark corners. >> >> At the same time, we would define the new INFO usage framework (still >> TBD) and ban *new* INFO usages that don't follow it. > > I agree. The framework proposed in draft-kaplan-sip-info-events-01 seems > like a step in the right direction. > > And I agree with registering existing uses. Even if existing uses aren't > updated to use the negotiation mechanism suggested (or whatever solution > the WG converges on), I think there is value in strongly encouraging the > adoption of the 'Info-Package' header (or similar). This shouldn't > noticeably affect interop of legacy devices, but marking the requests like > this would allow more recent devices to act appropriately in the presence > of multiple incompatible non-standard extensions. Not that such things > exist, of course! > > Regards, > > Michael > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 10:52:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB713A67E2; Tue, 24 Jun 2008 10:52:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699F13A67E2 for ; Tue, 24 Jun 2008 10:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.669 X-Spam-Level: X-Spam-Status: No, score=-6.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 AXVMkCgHim3v for ; Tue, 24 Jun 2008 10:52:14 -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 6C18A3A67CE for ; Tue, 24 Jun 2008 10:52:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,697,1204520400"; d="scan'208";a="12080249" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Jun 2008 13:52:15 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5OHqE3V008014; Tue, 24 Jun 2008 13:52:14 -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.13.8) with ESMTP id m5OHqEkS011622; Tue, 24 Jun 2008 17:52:14 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 13:52:14 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 13:52:14 -0400 Message-ID: <4861347C.8020100@cisco.com> Date: Tue, 24 Jun 2008 13:53:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> <4860E783.3070008@cisco.com> <4860EC06.6080104@cisco.com> In-Reply-To: X-OriginalArrivalTime: 24 Jun 2008 17:52:14.0525 (UTC) FILETIME=[091E76D0:01C8D623] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1197; t=1214329934; x=1215193934; 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[Sip]=20Draft=20submission=3A=20draft-i etf-sip-199-00 |Sender:=20 |To:=20Christer=20Holmberg=20; bh=3OrHqIlYtCo3wCGkDd3zIPcjuOzLxFyDQe/2bLLr3S4=; b=q5gLihI2NiNPwnR+gWeWmDYWthT9MQ5Jxl90ooq91D5uT7MIh4+xJoecKt GrkP6uaL4aHniCDYurVpdvpE+OcrlIJ8SD99LjQTFobAFXep25uxKg7l1awJ bK7BEfh/n5; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: >>> One option, as proposed by Paul, is to say that a UAC shall be able to RECEIVE reliable 199 responses. >> Based on my comments above, I am reconsidering the advisability of that. > > Well, I guess it wouldn't affect the complexness in the UAC, since it will have to be able to handle reliable provisional responses anyway (if it indicates support of it, that is). Yes, I think it does increase the complexity in the implementation of 199 handling. You are right that the PRACK itself would be handled by the standard machinery for reliable provisionals. But then tearing down the dialog, which is what the 199 is supposed to trigger, can't be done upon receipt of a reliable 199. Rather it must wait until the after the PRACK is at least send, and perhaps until the 200 for the prack is received. And this is different than for the unreliable 199. This isn't rocket science, but it is more complexity. And of course it requires something that sends reliable 199s in order to test the UAC. Paul > And, if the sender of the 199 is a B2BUA, I guess it COULD send it reliably. > > But, I have no strong feelings regarding this. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 11:03:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC17B3A6860; Tue, 24 Jun 2008 11:03:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1F23A6860 for ; Tue, 24 Jun 2008 11:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.663 X-Spam-Level: X-Spam-Status: No, score=-6.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 eZKEe3LcLpCd for ; Tue, 24 Jun 2008 11:03:05 -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 302323A6829 for ; Tue, 24 Jun 2008 11:03:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,697,1204531200"; d="scan'208";a="59899099" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2008 11:03:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5OI34a6004797; Tue, 24 Jun 2008 11:03:04 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5OI2sXL023340; Tue, 24 Jun 2008 18:03:04 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.1830); Tue, 24 Jun 2008 14:02:56 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 14:02:56 -0400 Message-ID: <486136FF.20608@cisco.com> Date: Tue, 24 Jun 2008 14:03:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Robert Sparks References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> <1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> In-Reply-To: <1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> X-OriginalArrivalTime: 24 Jun 2008 18:02:56.0500 (UTC) FILETIME=[87C41340:01C8D624] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7304; t=1214330584; x=1215194584; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=TVCRwYH+kYKNuafXwtDTP6Ns8VOvirR1YzQ9ST5Yo7I=; b=kHOnaawgp82faVMMW5YM1ygLCAordbO+AbkOkODNK/Tce0mmX6J8H/zlSB aSpWY1+I/g01elhtW7vBpl0g2Bud97XLaC035Bk7tclrSosAvdTX7dRoaw8/ mkkQJ8UVWe; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Robert, I will agree that the scenario you pose is a possibility. And if it seems probable then we should do nothing. The carrot we could offer would be the registry. New usages would get into the registry, but new usages of INFO without the framework would not be eligible for the registry. Whether that is perceived as a carrot is an open question. It may be that most existing usages that haven't come through ietf don't *wish* to be public. If not, then there is nothing we can do. Paul Robert Sparks wrote: > inline > > On Jun 24, 2008, at 9:00 AM, Paul Kyzivat wrote: > >> Mary, >> >> My latest thought is that we should "grandfather" existing uses of >> INFO. We would provide a registry of them, without blessing them or >> standardizing their specifications. That would at least shine some >> light in the dark corners. >> >> At the same time, we would define the new INFO usage framework (still >> TBD) and ban *new* INFO usages that don't follow it. > > Well, if we don't think banning INFO as a whole would be listened to, > why do we think banning INFO that doesn't use this new framework would > be listened to? > > That's where I'm having difficulty with the question. I can see the bite > of work it would take to make the framework. > I'm still trying to see what would actually use it if we did? > Can somebody list the packages that we've already identified that we > would put out with this framework? > >> >> >> I think that would be better than the current situation, and about as >> good as we can expect to achieve. > > I'm still not convinced it makes it better. One outcome I can see from > following this path is two years from now finding ourselves with no > actual packages using the framework and a set of _new_ INFO based > applications in the field that _don't_ use the framework. > > Will we continue to put those in this proposed registry above? Or do we > just have another set of practices that we have to treat the current > non-standardized INFO uses with now? > > The bet we would be placing by putting the work into creating this > framework is that it actually takes some motivation away from using a > non-standard bare INFO to realize some new application (and that there > are new applications out there where this would be a really good tool to > have to realize them). Is this framework really lowering a barrier to > entry or relieving some other pain so that the people who would > otherwise make a new non-standard use of INFO come use it? I'm having a > really hard time seeing that. > > If we end up on the wrong side of that bet, we've arguably made things > _worse_ taking work away from other things, creating mechanics that have > to be implemented, tested and will ultimately be abused, and not solving > the actual problem in the first place. > > So, I'll continue to look for some evidence this will actually get used > and relieves some pressure to just go use INFO in a proprietary way and > skip all this standards pain (hopefully folks here can help me with this). > > Without it, I think the better path would be to create the registry you > describe, publish an informational document pointing out the pitfalls of > the approaches they take, and get on with other work. > > I'll also, of course, accept a community decision to just do this work > and take the risk of losing the bet and help make sure we build the best > framework possible if that's where we really want to go. I just hope > somebody can convince me we're not trading off other work we could be > benefiting from more to find ourselves in effectively the same position > two years from now. > > RjS > > >> >> >> Thanks, >> Paul >> >> Mary Barnes wrote: >>> Just a couple more points of clarification on my view embedded below >>> [MB]. >>> Mary >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Tuesday, >>> June 24, 2008 8:25 AM >>> To: Barnes, Mary (RICH2:AR00) >>> Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; SIP@ietf.org; DOLLY, >>> MARTIN C, ATTLABS >>> Subject: Re: [Sip] INFO and what to do about it? >>> Mary Barnes wrote: >>>> I don't believe we could ever forbid INFO. I initially did not think >>>> we could accomplish anything around INFO, but I believe some of the >>>> work that's on the table would be useful for working towards >>>> interoperabilty for the INFO usages. I would be afraid to ask honestly >>>> for the identification of all the different uses of INFO that are >>>> out there right now. >>> I don't think we should be afraid of this at all. >>> [MB] My guess (based on what I've seen) is that a lot of vendors would >>> have around a half dozen (+- 2). Now, some of those might overlap given >>> there is some level of interop between various vendors. [/MB] >>> There are (sometimes/often) good reasons why folks resort to these >>> solutions. Our job here at IETF is to ensure interoperability for the >>> SIP protocol. If we don't listen to our customers - the people who have >>> deployed and are actually using it - what purpose does our work serve? >>> [MB] My experience is that at least half the uses of INFO were in place >>> when the protocol was quite immature (i.e., well before RFC 3261). And, >>> we indeed should listen to our customers by providing a flexible >>> platform for them to do the things they need to do. IMHO, it's been loud >>> and clear in the past that they want to use INFO and in the past, docs >>> like "Info considered harmful" weren't helpful towards this end. [/MB] >>>> Doing something is better than nothing at this point IMHO and I'm >>>> personally really tired of revisiting this issue every couple of >>>> years. AND, this would help us put a stake in the group on the >>>> future usages of INFO (whether we ever get rid of the old usages or >>>> not), as I believe there are other SDOs defining new uses of INFO >>>> right now to add to the mix of un-interoperability in this area. >>> As long as SIP usage continues to rise, I suspect we will continue to >>> see more INFO usages. Just because we cannot fix what is broken in the >>> past, doesn't mean we should let it remain broken for the future. >>> [MB] I'm not at all disagreeing on this point. Optimistically, I'd like >>> to see the current implementations evolve to support this new approach >>> as it will improve interoperability. If the WG can complete this work in >>> a timely manner (perhaps the biggest issue given past performance), then >>> the potential for uptake for a standardized implementation is INFO is >>> far higher IMHO. If we can get this work chartered, then we're far more >>> likely to get uptake by the other SDOs far sooner than if we continue to >>> dillydally. And, it's important to remember that this isn't the only >>> area where there are interoperability issues. And, actually, per SFSIW-1 >>> the use of INFO was not a common theme - either because it was a given >>> or it's not as big an issue as some of us are assuming - in a quick scan >>> I only found one document discussing the use of INFO. [/MB] >>> -Jonathan R. > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 11:05:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C363A6829; Tue, 24 Jun 2008 11:05:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49E73A68B6 for ; Tue, 24 Jun 2008 11:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.657 X-Spam-Level: X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 dWBGbezaGw66 for ; Tue, 24 Jun 2008 11:05:19 -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 9D07B3A67F6 for ; Tue, 24 Jun 2008 11:05:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,697,1204531200"; d="scan'208";a="117784665" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2008 11:05:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5OI58Ck026786; Tue, 24 Jun 2008 11:05:08 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5OI57wv025943; Tue, 24 Jun 2008 18:05:08 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.1830); Tue, 24 Jun 2008 14:05:06 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 14:05:06 -0400 Message-ID: <48613781.2080603@cisco.com> Date: Tue, 24 Jun 2008 14:05:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: X-OriginalArrivalTime: 24 Jun 2008 18:05:06.0608 (UTC) FILETIME=[D550FB00:01C8D624] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2386; t=1214330708; x=1215194708; 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[Sip]=20INFO=20and=20what=20to=20do=20a bout=20it? |Sender:=20; bh=u01Z7A3WDCRkQHhd7CMehnUNUOY0XnllrVK8dO2pRJM=; b=SY2qJBvV/9pxMdYpuqdH9WSA0E65QndgbgkUrds2vGceJVMotJEtOu6V32 Py8U3f+pBKUHSBd04JOaf/oyQqjDTNiS+PQU3O/2oJOY7kpbhuimFpLyglvn woE0v1GH6R; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Henry, You seem to be changing philosophy here. These existing uses of INFO are *running code*. Why doesn't that make them the good candidates for standardization? Paul Henry Sinnreich wrote: >> If we don't listen to our customers - the people who have >> deployed and are actually using it - what purpose does our work serve? > > This is what the managers of the typewriter business must have said when the > word processors appeared: "Our customers ask for a white-out ribbon and for > a price under $500." > > A PC at that time cost $5,000 and the additional laser printer was another > $5,000. > > Some companies opted for the PC business nevertheless and did NOT listen to > their customers. > > Does anyone care for simple SIP that can be understood by developers with > limited time on their hands? > > Henry > > > On 6/24/08 6:25 AM, "Jonathan Rosenberg" wrote: > >> >> Mary Barnes wrote: >>> I don't believe we could ever forbid INFO. I initially did not think >>> we could accomplish anything around INFO, but I believe some of the >>> work that's on the table would be useful for working towards >>> interoperabilty for the INFO usages. I would be afraid to ask >>> honestly for the identification of all the different uses of INFO >>> that are out there right now. >> I don't think we should be afraid of this at all. >> >> There are (sometimes/often) good reasons why folks resort to these >> solutions. Our job here at IETF is to ensure interoperability for the >> SIP protocol. If we don't listen to our customers - the people who have >> deployed and are actually using it - what purpose does our work serve? >> >> >>> Doing something is better than nothing at this point IMHO and I'm >>> personally really tired of revisiting this issue every couple of >>> years. AND, this would help us put a stake in the group on the future >>> usages of INFO (whether we ever get rid of the old usages or not), as >>> I believe there are other SDOs defining new uses of INFO right now to >>> add to the mix of un-interoperability in this area. >> As long as SIP usage continues to rise, I suspect we will continue to >> see more INFO usages. Just because we cannot fix what is broken in the >> past, doesn't mean we should let it remain broken for the future. >> >> -Jonathan R. >> > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 11:23:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387863A684F; Tue, 24 Jun 2008 11:23:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B3C3A67F6 for ; Tue, 24 Jun 2008 11:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxBTUWpcY3HK for ; Tue, 24 Jun 2008 11:23:49 -0700 (PDT) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by core3.amsl.com (Postfix) with ESMTP id B72643A6829 for ; Tue, 24 Jun 2008 11:23:48 -0700 (PDT) Received: (qmail 4082 invoked by uid 0); 24 Jun 2008 18:23:38 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 Jun 2008 18:23:38 -0000 Message-ID: <48613B9F.5020307@zonnet.nl> Date: Tue, 24 Jun 2008 20:23:27 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Rockson Li (zhengyli)" References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com><4860A45F.9020001@zonnet.nl> In-Reply-To: Cc: sip@ietf.org, Christer Holmberg Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer, My point was to formalize the moment a 199 is sent by relating it to the = RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE = requests don't use provisional responses here) So associated with PROCEEDING-->COMPLETED, but indeed only if a to-tag = was received before (so not only 100) Regards, Jeroen PS perhaps an idea to explicitly disallow 199 for non-INVITE requests? Rockson Li (zhengyli) wrote: > Yes, it's a typo, 100 does not establish early-dialog. > -Rockson = > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] = > Sent: Tuesday, June 24, 2008 6:32 PM > To: Rockson Li (zhengyli); Jeroen van Bemmel > Cc: sip@ietf.org > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > > Hi, = > > = >>> Should the 199 response contain a Contact header? And if yes, in case = >>> a proxy sends it, should it contain the address of that proxy (since th= e UAS already sent a final response)? >>> = >> IF the 199 is sent reliably be the proxy must contain a Contact header c= ontaining the address of the proxy, yes. >> >> = >>> Should we say that a proxy may only generate and send a 199 when it = >>> receives a final error response on an INVITE client Transaction which = >>> was in the PROCEEDING state? (i.e. 1xx response was received before, = >>> so conceptually sending the 199 response is an action associated with = >>> the transition from PROCEEDING to COMPLETED) >>> = >> I am not sure I understand. The idea IS to send 199 when a final error = >> response is received by the forking proxy, if a 18x has previously been = received. >> [Rockson] PROCEEDING does not mean early-dialog is established, 100 = >> Trying also move INVITE client Transaction to PROCEEDING state. >> = > > [Christer] 199 is only sent when an early dialog has been established. 10= 0 Trying does not establish an early dialog. > > Regards, > > Christer > > > > > > > Also, a forking proxy with multiple INVITE client Transaction may receive= /forward 180 from one of them, and receive no provisional resp and final re= sp directly from the other one, so INVITE client Transaction's state is no= t dependable. The decision making must be done in TU. > > > > > > Christer Holmberg wrote: > = >> Hi, >> >> I agree it may be a good idea to not forbid sending it reliably. >> >> I do think it would be good to have text, saying that it can be sent unr= eliable even if reliable responses are required, though, so that proxies ar= en't forced to terminate PRACKs etc. >> >> Regards, >> >> Christer >> = >> >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = >> Dale.Worley@comcast.net >> Sent: 21. kes=E4kuuta 2008 1:38 >> To: sip@ietf.org >> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >> >> From: "Christer Holmberg" >> >> [CHH] Whether the text should be in the document at all depends on if= we >> allow 199 to be sent reliably in the first place. Based on the commen= ts >> received so far we should not mandate 199 to be sent reliably, even if >> 100rel is required by the UAC. But, the question if whether we want to >> FORBID sending it reliably. >> >> If we ever might allow 199 to be used for HERFP, we should admit the pos= sibility of sending it reliably in the first draft. Otherwise, we'll be lo= cked out of sending it reliably in the future. >> >> Dale >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip = >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip >> >> = >> = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use sip-impleme= ntors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for= new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 11:32:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF103A6957; Tue, 24 Jun 2008 11:32:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5073A6957 for ; Tue, 24 Jun 2008 11:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 k2Lp3YJksj68 for ; Tue, 24 Jun 2008 11:32:12 -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 CB87C3A68F3 for ; Tue, 24 Jun 2008 11:32:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,697,1204531200"; d="scan'208";a="117797197" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2008 11:32:11 -0700 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 m5OIW379030844; Tue, 24 Jun 2008 11:32:03 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5OIW2p6005130; Tue, 24 Jun 2008 18:32:02 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> Date: Tue, 24 Jun 2008 11:32:01 -0700 Message-ID: <05d001c8d628$98c91510$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4860AD84.60004@gmx.net> Thread-Index: AcjV0rZlT+zGQx+sRQ+GzaRAyuOpXwAVXiHA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3294; t=1214332323; x=1215196323; c=relaxed/simple; s=sjdkim3002; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=1Y/XnaJEOtBoUx7Z5Vytxe5M9KQYL0aMZ6Qd4w0Ss+I=; b=bdOYphxkJg0mdp7vGzmQYB+4EOLehgjMXVidN9TFYMi8T50ZKUzSTlMnrs /8ZU/BOyMterr4geob96SwrS4a56Xw8DYQt6TDSvqPrV6afsE5qhxjDXkqnc 9AItwo4XS2; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org, 'Paul Kyzivat' , 'Dean Willis' Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org To summarize your email: anybody that needs SIP security will use TLS between their own proxies. That does seem to be the consensus. Perhaps how that works should be written up -- as in, does that mean when I have a TLS connection with boeing.com, I should only allow or only expect From: addresses that end in @boeing.com, and not @big-airplane.boeing.com and not @rolls-royce.com? -d > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, June 24, 2008 1:17 AM > To: Dan Wing > Cc: 'Dean Willis'; 'Hadriel Kaplan'; sip@ietf.org; 'Paul Kyzivat' > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > Many of the SIP security mechanisms share the same fate: They are far > ahead of the actual SIP deployment. This is true for SIP > Identity, SIP > CERT, SIP SAML, End-to-End Security, etc. When we started the > SAML work > we looked at what was going on at that time in the HTTP > space. Without > doubt the entire application layer identity management space > found a lot > of excitement. There is a lot of standardization being done > and also a > lot of deployment taking place. With the SIP space that was > obviously a > bit different and deployments today focus largely on voice (and there > not even on end-to-end SIP-based communication). > > For example: Look at what is being used in XMPP. There is no > equalivalent of SIP Identity -- folks are currently looking into > providing certificates for server-to-server communication. > > Even though they are, from a deployment point of view, ahead they are > not even close to where we are with our documents. > > Ciao > Hannes > > PS: I also believe that the SIP Identity case isn't an easy > one either. > The guys that would make use of SIP Identity for a deployment > where the > two SIP proxies talk to each other there would not be a need for SIP > Identity since you are essentially replicating what TLS > provides you at > a lower layer already. In cases where there many SIP proxies > along the > path SIP Identity would be useful since it provides > protection against > any one of them being malicious. However, the guys who favour such a > deployment model are the onces that believe very much in the chain of > trust (hop-by-hop security). They have no interest in using > SIP Identity. > > > > Dan Wing wrote: > >>> draft-ietf-sip-saml > >>> > >> -- I'm not sure this one is ever getting done. > >> > >> So I'm not sure there's enough there to justify a WG. > >> > >> How about an "Identity in SIP" working group that takes on > >> fixing RFC 4474 for gateways/b2buas and possibly considers > >> identity/role assertion using SAML? > >> > > > > I agree we need that. I have tried, and so far failed, to > > initiate activity towards such an effort. > > > > -d > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 12:11:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFBC3A6829; Tue, 24 Jun 2008 12:11:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2D03A688A for ; Tue, 24 Jun 2008 12:11:18 -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=[AWL=-0.001, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chF+BncJEBtP for ; Tue, 24 Jun 2008 12:11:16 -0700 (PDT) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by core3.amsl.com (Postfix) with ESMTP id B6D283A6868 for ; Tue, 24 Jun 2008 12:11:14 -0700 (PDT) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20080624191556.SKLW7070.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Tue, 24 Jun 2008 20:15:56 +0100 Received: from darjeeling.procter.org.uk ([81.104.240.101]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20080624192101.KNQG8797.aamtaout03-winn.ispmail.ntl.com@darjeeling.procter.org.uk>; Tue, 24 Jun 2008 20:21:01 +0100 Received: from [192.168.73.35] (helo=OOLONG) by darjeeling.procter.org.uk with smtp (Exim 4.50) id 1KBDv5-00028m-6M; Tue, 24 Jun 2008 20:11:11 +0100 Message-ID: <000901c8d62e$0cbaaf60$2349a8c0@OOLONG> From: "Michael Procter" To: "Paul Kyzivat" References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> <3470.87.194.179.229.1214320707.squirrel@webmail.procter.org.uk> <48613342.3050504@cisco.com> Date: Tue, 24 Jun 2008 20:11:04 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Let me be clear: for the grandfathering part, I am suggesting that we > develop a registry of *existing* usage, not that those existing usages > change in any way. I want to get them written down, so at least there > is a place to look to find out about something unknown to you, and to > ensure nothing new gets defined that is in conflict with something > old. > > If those existing usages can be updated to use the new framework that > would be better yet. But I'm not going to hold my breath waiting for > that to happen. Exactly. I agree with all this, and recognise it as a good start. I went on to propose a half-way house between no changes for legacy uses, and full adoption of a new framework. A lightweight[0] framework may[1] attract new uses, but the negotiation features present in Hadriel's current draft seem likely to deter the migration of legacy uses. I am merely suggesting that using the INFO-labelling part of Hadriel's draft but not the negotiation aspect could seem more attractive[2] to legacy uses, and would still provide the rest of the community some value (namely being able to identify all the INFO messages flying around their networks). Michael [0] Both the implementation and documentation needs to be lightweight IMO. [1] RjS' email discusses this further, and he seems less optimistic. [2] Low implementation cost, relatively low risk, no additional stateful behaviour required. > > Paul > > Michael Procter wrote: >> On Tue, June 24, 2008 3:00 pm, Paul Kyzivat wrote: >>> My latest thought is that we should "grandfather" existing uses of >>> INFO. >>> We would provide a registry of them, without blessing them or >>> standardizing their specifications. That would at least shine some >>> light >>> in the dark corners. >>> >>> At the same time, we would define the new INFO usage framework >>> (still >>> TBD) and ban *new* INFO usages that don't follow it. >> >> I agree. The framework proposed in draft-kaplan-sip-info-events-01 >> seems >> like a step in the right direction. >> >> And I agree with registering existing uses. Even if existing uses >> aren't >> updated to use the negotiation mechanism suggested (or whatever >> solution >> the WG converges on), I think there is value in strongly encouraging >> the >> adoption of the 'Info-Package' header (or similar). This shouldn't >> noticeably affect interop of legacy devices, but marking the requests >> like >> this would allow more recent devices to act appropriately in the >> presence >> of multiple incompatible non-standard extensions. Not that such >> things >> exist, of course! >> >> Regards, >> >> Michael >> >> > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 12:13:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC273A6829; Tue, 24 Jun 2008 12:13:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0DE3A681F for ; Tue, 24 Jun 2008 12:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 obubo6gC8Nsc for ; Tue, 24 Jun 2008 12:13:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4BB4B3A6800 for ; Tue, 24 Jun 2008 12:13:14 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OJCtiq018382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 14:12:57 -0500 Message-Id: From: Dean Willis To: Robert Sparks In-Reply-To: <1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 14:12:49 -0500 References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> <1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> X-Mailer: Apple Mail (2.924) Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Paul Kyzivat , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 11:52 AM, Robert Sparks wrote: > > The bet we would be placing by putting the work into creating this > framework is that it actually takes some motivation away from using > a non-standard bare INFO to realize some new application (and that > there are new applications out there where this would be a really > good tool to have to realize them). Is this framework really > lowering a barrier to entry or relieving some other pain so that the > people who would otherwise make a new non-standard use of INFO come > use it? I'm having a really hard time seeing that. > Well, that's the whole reason we write RFCs instead of just telling people to innovate, isn't it? > If we end up on the wrong side of that bet, we've arguably made > things _worse_ taking work away from other things, creating > mechanics that have to be implemented, tested and will ultimately be > abused, and not solving the actual problem in the first place. > > So, I'll continue to look for some evidence this will actually get > used and relieves some pressure to just go use INFO in a proprietary > way and skip all this standards pain (hopefully folks here can help > me with this). > > Without it, I think the better path would be to create the registry > you describe, publish an informational document pointing out the > pitfalls of the approaches they take, and get on with other work. Don't use INFO. By the way, here's the "standard required" process for registering your non-standard INFO use by MIME-type and content- disposition. . . Don't blame us when it kills you, or you have to register a new MIME or content-disposition because somebody already signed up for the one you want to use. I kind of like that approach. Can we do the same thing with P-headers? It'd sure save us a lot of work. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 12:20:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CEC63A6868; Tue, 24 Jun 2008 12:20:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138153A6868 for ; Tue, 24 Jun 2008 12:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 gNOaR-bsNTLp for ; Tue, 24 Jun 2008 12:20:01 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3AFE63A6800 for ; Tue, 24 Jun 2008 12:20:01 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OJJxK7018434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 14:20:01 -0500 Message-Id: From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 14:19:54 -0500 X-Mailer: Apple Mail (2.924) Cc: Keith Drage Subject: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've been tipped off that we may be down to as little as two hours (or maybe 2.5) of meeting time in Dublin due to additional WG and BOF events that didn't make it onto the earlier published agenda (like MEDIACTRL). What are the absolutely most important things we need to talk about? What is the best possible use of our very valuable and very scarce time together? I suspect that going by-rote through the list of open milestones is not the best use of our time. Topics that I think we might want to talk about include but are not limited to: Agenda bash and announcements usually use 10 minutes 1) Using SAML for SIP. -- Milestone was Dec. 2007 -- Author has promised new rev before meeting -- Is the WG committed to doing this work? -- 10 minutes? 2) Test Matrix for SIP to Draft Standard -- Milestone was Feb 2008 -- How are we going to move forward? -- 10 minutes 3) Delivery of Request URI and Parameters to UAS Through Proxy -- Milestone was Feb 2008 -- Conversation has lagged. Do we see a workable solution? -- 30 minutes? 4) DTLS-SRTP -- Milestone was Feb 2008 -- Delayed by the RFC 4474/Gateway/B2BUA -- Decide: Do we hold DTLS-SRTP or publish with a caveat? -- EKR may not be attending, can we resolve on-list? (no time?) 5) Mechanisms for UA Initiated Privacy -- Milestone is July 2008 -- Author has promised new rev before meeting -- 20 minutes? 6) Termination of early Dialog Prior to Final Response (199) -- Milestone is November 2008 -- Substantial list activity -- 30 minutes? 7) Guidelines for SIP Extension Modalities -- No milestone -- Needs conceptual discussion -- Defer until #8 below is resolved? (no time?) 8) The INFO solution and Paul's compromise for historical registration -- No milestone -- Previous WG consensus to "do something" -- 40 minutes? Am I missing something that is critically important? Which topics do we really need to talk about in order to move forward? _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 12:38:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFCB3A6844; Tue, 24 Jun 2008 12:38:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F433A6868 for ; Tue, 24 Jun 2008 12:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 QS8fNlNg4Ej5 for ; Tue, 24 Jun 2008 12:38:37 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 5438C3A6844 for ; Tue, 24 Jun 2008 12:38:37 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K2Z0041IFWDZY@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Jun 2008 20:38:37 +0100 (BST) Date: Tue, 24 Jun 2008 20:38:36 +0100 From: "Elwell, John" In-reply-to: To: Dean Willis , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Let's talk about a Dublin agenda Thread-Index: AcjWL1WAD54QsuztSIqYMIDXevqQ2AAAeeKQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: Keith Drage Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, Well, just how exactly do we go about resolving the various Identify issues (E.164 / SBCs / gateways)? I think Dan has tried unsuccessfully for a BoF earlier. No agenda time in SIP this time. There have been some huge email threads since Philadelphia. There are several relevant drafts around (and possibly more before Dublin). John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: 24 June 2008 20:20 > To: sip@ietf.org > Cc: Keith Drage > Subject: [Sip] Let's talk about a Dublin agenda > > > I've been tipped off that we may be down to as little as two > hours (or > maybe 2.5) of meeting time in Dublin due to additional WG and BOF > events that didn't make it onto the earlier published agenda (like > MEDIACTRL). > > What are the absolutely most important things we need to talk about? > What is the best possible use of our very valuable and very scarce > time together? > > I suspect that going by-rote through the list of open milestones is > not the best use of our time. > > Topics that I think we might want to talk about include but are not > limited to: > > Agenda bash and announcements usually use 10 minutes > > 1) Using SAML for SIP. > -- Milestone was Dec. 2007 > -- Author has promised new rev before meeting > -- Is the WG committed to doing this work? > -- 10 minutes? > > 2) Test Matrix for SIP to Draft Standard > -- Milestone was Feb 2008 > -- How are we going to move forward? > -- 10 minutes > > 3) Delivery of Request URI and Parameters to UAS Through Proxy > -- Milestone was Feb 2008 > -- Conversation has lagged. Do we see a workable solution? > -- 30 minutes? > > 4) DTLS-SRTP > -- Milestone was Feb 2008 > -- Delayed by the RFC 4474/Gateway/B2BUA > -- Decide: Do we hold DTLS-SRTP or publish with a caveat? > -- EKR may not be attending, can we resolve on-list? (no time?) > > 5) Mechanisms for UA Initiated Privacy > -- Milestone is July 2008 > -- Author has promised new rev before meeting > -- 20 minutes? > > 6) Termination of early Dialog Prior to Final Response (199) > -- Milestone is November 2008 > -- Substantial list activity > -- 30 minutes? > > 7) Guidelines for SIP Extension Modalities > -- No milestone > -- Needs conceptual discussion > -- Defer until #8 below is resolved? (no time?) > > 8) The INFO solution and Paul's compromise for historical registration > -- No milestone > -- Previous WG consensus to "do something" > -- 40 minutes? > > > Am I missing something that is critically important? > > Which topics do we really need to talk about in order to move forward? > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 12:43:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8DE3A6868; Tue, 24 Jun 2008 12:43:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981213A6868 for ; Tue, 24 Jun 2008 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 8LH8lKMZidIR for ; Tue, 24 Jun 2008 12:43:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 949F83A681F for ; Tue, 24 Jun 2008 12:43:56 -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 m5OJhq4G004577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 14:43:52 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5OJhn1s011831; Tue, 24 Jun 2008 14:43:49 -0500 (CDT) Message-ID: <48614E77.9010904@alcatel-lucent.com> Date: Tue, 24 Jun 2008 14:43:51 -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: Dan Wing References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> In-Reply-To: <05d001c8d628$98c91510$c2f0200a@cisco.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan Wing wrote: > To summarize your email: anybody that needs SIP security will use > TLS between their own proxies. That does seem to be the consensus. > Perhaps how that works should be written up -- as in, does that mean > when I have a TLS connection with boeing.com, I should only allow or > only expect From: addresses that end in @boeing.com, and not > @big-airplane.boeing.com and not @rolls-royce.com? Dan: I suspect you are talking of the above in the context of SIP SAML. Otherwise, for certificate-based authentication between proxies, some of what you write above is discussed in the sip-domain-certs draft. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 12:47:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E3F3A681F; Tue, 24 Jun 2008 12:47:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E29D3A6868 for ; Tue, 24 Jun 2008 12:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 fLlQtjZAGrbO for ; Tue, 24 Jun 2008 12:47:53 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7E7143A681F for ; Tue, 24 Jun 2008 12:47:53 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OJln3o018648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 14:47:51 -0500 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 14:47:44 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org, Keith Drage Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 2:38 PM, Elwell, John wrote: > Dean, > > Well, just how exactly do we go about resolving the various Identify > issues (E.164 / SBCs / gateways)? I think Dan has tried unsuccessfully > for a BoF earlier. No agenda time in SIP this time. There have been > some > huge email threads since Philadelphia. There are several relevant > drafts > around (and possibly more before Dublin). > My suggestion is in two parts: 1) For DTLS-SRTP Framework, simply document the limitation of RFC 4474 and move on. This is a one-paragraph add to the framework. 2) For the remainder, I'd like to suggest the "REal Time Identity and Role Expression" (RETIRE) Working Group, which would take over the RFC 4474 revision along with SIP-SAML. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 12:48:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E20B3A69A1; Tue, 24 Jun 2008 12:48:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DE83A69EA for ; Tue, 24 Jun 2008 12:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTQTLYhoYVoD for ; Tue, 24 Jun 2008 12:48:20 -0700 (PDT) Received: from kilo.rtfm.com (unknown [128.107.30.117]) by core3.amsl.com (Postfix) with ESMTP id 04D693A69D9 for ; Tue, 24 Jun 2008 12:48:20 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id BD39B306834; Tue, 24 Jun 2008 12:48:20 -0700 (PDT) Date: Tue, 24 Jun 2008 12:48:20 -0700 From: Eric Rescorla To: Dean Willis In-Reply-To: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> References: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080624194820.BD39B306834@kilo.rtfm.com> Cc: sip@ietf.org, Cullen Jennings , Eric Rescorla , Keith Drage Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gateway deadlock X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, This sounds like an excellent way to proceed. I'll generate some candidate text and send it to the list in the next few days. -Ekr On Tue, Jun 24, 2008 at 10:21 AM, Dean Willis wrote: > > We've gotten stuck on a fine point in DTLS-SRTP. > > The current draft-ietf-sip-dtls-srtp-framework-01 uses an RFC 4474 Identity > header to preserve the integrity of the media key's fingerprint, thereby > detecting a certain class of MITM attack. > > However, RFC 4474 Identity headers are of questionable validity when used > with protocol gateways or B2BUAs. More or less, they're capable of > asserting the identity of the gateway, not the identity of the calling > party. But the recipient has no real way to figure out which is which. > > We've debated at some length, and with no good result, about whether we > should try and fix RFC 4474. We've had some suggestions that may work for > B2BUAs, and some other suggestions that may work for gateways, but we > certainly don't have a consensus. > > That leaves our chartered deliverable of DTLS-SRTP hanging, and the > milestone has gone past months ago. > > Here's a proposal: > > We add a caveat about the limitation of RFC 4474 to > draft-ietf-sip-dtls-srtp-framework and go ahead and advance that > specification. If somebody later decides to fix RFC 4474, they can do so, > and if necessary update DTLS-SRTP if needed. > > > Does that work for everybody? > > If we agree to it, I suggest that we move the date for WGLC of > draft-ietf-sip-dtls-srtp-framework to July 2008, and move the milestone for > delivery of that doc to the IESG into September. > > -- > Dean > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 13:09:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20AE3A68E4; Tue, 24 Jun 2008 13:09:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357303A6806 for ; Tue, 24 Jun 2008 13:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.055 X-Spam-Level: X-Spam-Status: No, score=-4.055 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, 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 UMfhOvil-kli for ; Tue, 24 Jun 2008 13:09:35 -0700 (PDT) Received: from smtp03.bis.na.blackberry.com (smtp03.bis.na.blackberry.com [216.9.248.50]) by core3.amsl.com (Postfix) with ESMTP id 130213A68E4 for ; Tue, 24 Jun 2008 13:09:34 -0700 (PDT) Received: from bda381.bisx.prod.on.blackberry (bda381.bisx.prod.on.blackberry [172.20.234.81]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m5OK9ZL3012183; Tue, 24 Jun 2008 20:09:35 GMT Received: from bda381.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda381.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id m5OK9YQV001648; Tue, 24 Jun 2008 20:09:34 GMT X-rim-org-msg-ref-id: 1762171404 Message-ID: <1762171404-1214338174-cardhu_decombobulator_blackberry.rim.net-707116175-@bxe014.bisx.prod.on.blackberry> X-Priority: Normal References: In-Reply-To: Sensitivity: Normal Importance: Normal To: "Dean Willis" , sip@ietf.org From: eburger@standardstrack.com Date: Tue, 24 Jun 2008 20:09:32 +0000 MIME-Version: 1.0 Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hey - not our fault - we got our request in on time. That said, I would offer #2 is possibly the most important work item, as it will drive a coherent, scoped work plan. How is this for a far-fetched thought: SIP to DS is the *only* work item for the SIP work group. If we could not get X done in 10 years (yes, it has been that long for some of these things), let us charter a new work group to work on X. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Dean Willis Date: Tue, 24 Jun 2008 14:19:54 To:sip@ietf.org Cc:Keith Drage Subject: [Sip] Let's talk about a Dublin agenda I've been tipped off that we may be down to as little as two hours (or maybe 2.5) of meeting time in Dublin due to additional WG and BOF events that didn't make it onto the earlier published agenda (like MEDIACTRL). What are the absolutely most important things we need to talk about? What is the best possible use of our very valuable and very scarce time together? I suspect that going by-rote through the list of open milestones is not the best use of our time. Topics that I think we might want to talk about include but are not limited to: Agenda bash and announcements usually use 10 minutes 1) Using SAML for SIP. -- Milestone was Dec. 2007 -- Author has promised new rev before meeting -- Is the WG committed to doing this work? -- 10 minutes? 2) Test Matrix for SIP to Draft Standard -- Milestone was Feb 2008 -- How are we going to move forward? -- 10 minutes 3) Delivery of Request URI and Parameters to UAS Through Proxy -- Milestone was Feb 2008 -- Conversation has lagged. Do we see a workable solution? -- 30 minutes? 4) DTLS-SRTP -- Milestone was Feb 2008 -- Delayed by the RFC 4474/Gateway/B2BUA -- Decide: Do we hold DTLS-SRTP or publish with a caveat? -- EKR may not be attending, can we resolve on-list? (no time?) 5) Mechanisms for UA Initiated Privacy -- Milestone is July 2008 -- Author has promised new rev before meeting -- 20 minutes? 6) Termination of early Dialog Prior to Final Response (199) -- Milestone is November 2008 -- Substantial list activity -- 30 minutes? 7) Guidelines for SIP Extension Modalities -- No milestone -- Needs conceptual discussion -- Defer until #8 below is resolved? (no time?) 8) The INFO solution and Paul's compromise for historical registration -- No milestone -- Previous WG consensus to "do something" -- 40 minutes? Am I missing something that is critically important? Which topics do we really need to talk about in order to move forward? _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 13:17:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3226928C0EF; Tue, 24 Jun 2008 13:17:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92E428C0EF for ; Tue, 24 Jun 2008 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 w8X6FWOUG1k7 for ; Tue, 24 Jun 2008 13:17:50 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E0D2728C0E0 for ; Tue, 24 Jun 2008 13:17:49 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K2Z00638HPQRJ@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Jun 2008 21:17:50 +0100 (BST) Date: Tue, 24 Jun 2008 21:17:48 +0100 From: "Elwell, John" In-reply-to: To: Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E42A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Let's talk about a Dublin agenda Thread-Index: AcjWMzS24jwyBxGkRjyYyIqL8KM34wAA3Z5Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net> Cc: sip@ietf.org, Keith Drage Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 24 June 2008 20:48 > To: Elwell, John > Cc: sip@ietf.org; Keith Drage > Subject: Re: [Sip] Let's talk about a Dublin agenda > > > On Jun 24, 2008, at 2:38 PM, Elwell, John wrote: > > > Dean, > > > > Well, just how exactly do we go about resolving the various Identify > > issues (E.164 / SBCs / gateways)? I think Dan has tried > unsuccessfully > > for a BoF earlier. No agenda time in SIP this time. There > have been > > some > > huge email threads since Philadelphia. There are several relevant > > drafts > > around (and possibly more before Dublin). > > > > My suggestion is in two parts: > > 1) For DTLS-SRTP Framework, simply document the limitation of > RFC 4474 > and move on. This is a one-paragraph add to the framework. > > 2) For the remainder, I'd like to suggest the "REal Time > Identity and > Role Expression" (RETIRE) Working Group, which would take > over the RFC > 4474 revision along with SIP-SAML. [JRE] Will that produce results before we all retire? But seriously, a new WG might be a good idea, but how long to set it up? What needs to be done at or before Dublin in that direction? John > > -- > Dean > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 13:21:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF9A3A6A86; Tue, 24 Jun 2008 13:21:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5863A6868 for ; Tue, 24 Jun 2008 13:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.105 X-Spam-Level: X-Spam-Status: No, score=-4.105 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, 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 nqV2Mrao38gZ for ; Tue, 24 Jun 2008 13:21:06 -0700 (PDT) Received: from smtp03.bis.na.blackberry.com (smtp03.bis.na.blackberry.com [216.9.248.50]) by core3.amsl.com (Postfix) with ESMTP id E8A8F3A6A86 for ; Tue, 24 Jun 2008 13:21:05 -0700 (PDT) Received: from bda381.bisx.prod.on.blackberry (bda381.bisx.prod.on.blackberry [172.20.234.81]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m5OKL5CP018198; Tue, 24 Jun 2008 20:21:05 GMT Received: from bda381.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda381.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id m5OKL3LY016016; Tue, 24 Jun 2008 20:21:03 GMT X-rim-org-msg-ref-id: 1359479597 Message-ID: <1359479597-1214338862-cardhu_decombobulator_blackberry.rim.net-68254602-@bxe014.bisx.prod.on.blackberry> X-Priority: Normal References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com><807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com><4860F5B6.2060307@cisco.com><4860FE00.7030601@cisco.com><1F14D9AE-FDCD-4A37-93FD-8E17AB46467D@nostrum.com> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Dean Willis" , "Robert Sparks" From: eburger@standardstrack.com Date: Tue, 24 Jun 2008 20:20:52 +0000 MIME-Version: 1.0 Cc: SIP@ietf.org Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Here is my prognostication: if we document current usage, that is what will be used. I'm in a foul enough mood to suggest we document curent usage to foster some semblance of interoperation, do the honorable thing and note why life sucks, and then consider our work done. I would offer that any framework we come up would be nothing more than an academic exercise. I can already hear people say we need to publish how to interwork this new framework with Cisco INFO DTMF because, golly gee, that is the only thing their deployed equipment supports. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Dean Willis Date: Tue, 24 Jun 2008 14:12:49 To:Robert Sparks Cc:SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" ,Paul Kyzivat , Mary Barnes ,Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? On Jun 24, 2008, at 11:52 AM, Robert Sparks wrote: > > The bet we would be placing by putting the work into creating this > framework is that it actually takes some motivation away from using > a non-standard bare INFO to realize some new application (and that > there are new applications out there where this would be a really > good tool to have to realize them). Is this framework really > lowering a barrier to entry or relieving some other pain so that the > people who would otherwise make a new non-standard use of INFO come > use it? I'm having a really hard time seeing that. > Well, that's the whole reason we write RFCs instead of just telling people to innovate, isn't it? > If we end up on the wrong side of that bet, we've arguably made > things _worse_ taking work away from other things, creating > mechanics that have to be implemented, tested and will ultimately be > abused, and not solving the actual problem in the first place. > > So, I'll continue to look for some evidence this will actually get > used and relieves some pressure to just go use INFO in a proprietary > way and skip all this standards pain (hopefully folks here can help > me with this). > > Without it, I think the better path would be to create the registry > you describe, publish an informational document pointing out the > pitfalls of the approaches they take, and get on with other work. Don't use INFO. By the way, here's the "standard required" process for registering your non-standard INFO use by MIME-type and content- disposition. . . Don't blame us when it kills you, or you have to register a new MIME or content-disposition because somebody already signed up for the one you want to use. I kind of like that approach. Can we do the same thing with P-headers? It'd sure save us a lot of work. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 13:23:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED46B3A6A9E; Tue, 24 Jun 2008 13:23:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABB228C0E1 for ; Tue, 24 Jun 2008 13:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, J_CHICKENPOX_25=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 QSv79MFss7cG for ; Tue, 24 Jun 2008 13:23:08 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 74F213A6A9B for ; Tue, 24 Jun 2008 13:23:08 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K2Z0066NHYLRJ@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Jun 2008 21:23:09 +0100 (BST) Date: Tue, 24 Jun 2008 21:23:08 +0100 From: "Elwell, John" In-reply-to: A <1762171404-1214338174-cardhu_decombobulator_blackberry.rim.net-707116175-@bxe014.bisx.prod.on.blackberry> To: eburger@standardstrack.com, Dean Willis , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E42B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Let's talk about a Dublin agenda Thread-Index: AcjWNkJrvQctOQwkSOe7pzexgYSeeQAASTOg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: A <1762171404-1214338174-cardhu_decombobulator_blackberry.rim.net-707116175-@bxe014.bisx.prod.on.blackberry> Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric, I too think #2 is important, particularly if that is viewed as one means of attacking the issues from SFSIW. I am thinking here that less is more, and what can we throw out of the Draft Standard to reduce the options, whilst at the same time retaining or adding whatever is needed to give us the necessary resilience, security, NAT/firewall-tolerance, etc.. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of eburger@standardstrack.com > Sent: 24 June 2008 21:10 > To: Dean Willis; sip@ietf.org > Subject: Re: [Sip] Let's talk about a Dublin agenda > > Hey - not our fault - we got our request in on time. > > That said, I would offer #2 is possibly the most important > work item, as it will drive a coherent, scoped work plan. > > How is this for a far-fetched thought: SIP to DS is the > *only* work item for the SIP work group. If we could not get > X done in 10 years (yes, it has been that long for some of > these things), let us charter a new work group to work on X. > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Dean Willis > > Date: Tue, 24 Jun 2008 14:19:54 > To:sip@ietf.org > Cc:Keith Drage > Subject: [Sip] Let's talk about a Dublin agenda > > > > I've been tipped off that we may be down to as little as two > hours (or > maybe 2.5) of meeting time in Dublin due to additional WG and BOF > events that didn't make it onto the earlier published agenda (like > MEDIACTRL). > > What are the absolutely most important things we need to talk about? > What is the best possible use of our very valuable and very scarce > time together? > > I suspect that going by-rote through the list of open milestones is > not the best use of our time. > > Topics that I think we might want to talk about include but are not > limited to: > > Agenda bash and announcements usually use 10 minutes > > 1) Using SAML for SIP. > -- Milestone was Dec. 2007 > -- Author has promised new rev before meeting > -- Is the WG committed to doing this work? > -- 10 minutes? > > 2) Test Matrix for SIP to Draft Standard > -- Milestone was Feb 2008 > -- How are we going to move forward? > -- 10 minutes > > 3) Delivery of Request URI and Parameters to UAS Through Proxy > -- Milestone was Feb 2008 > -- Conversation has lagged. Do we see a workable solution? > -- 30 minutes? > > 4) DTLS-SRTP > -- Milestone was Feb 2008 > -- Delayed by the RFC 4474/Gateway/B2BUA > -- Decide: Do we hold DTLS-SRTP or publish with a caveat? > -- EKR may not be attending, can we resolve on-list? (no time?) > > 5) Mechanisms for UA Initiated Privacy > -- Milestone is July 2008 > -- Author has promised new rev before meeting > -- 20 minutes? > > 6) Termination of early Dialog Prior to Final Response (199) > -- Milestone is November 2008 > -- Substantial list activity > -- 30 minutes? > > 7) Guidelines for SIP Extension Modalities > -- No milestone > -- Needs conceptual discussion > -- Defer until #8 below is resolved? (no time?) > > 8) The INFO solution and Paul's compromise for historical registration > -- No milestone > -- Previous WG consensus to "do something" > -- 40 minutes? > > > Am I missing something that is critically important? > > Which topics do we really need to talk about in order to move forward? > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 13:46:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184543A688E; Tue, 24 Jun 2008 13:46:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB0B3A67F7 for ; Tue, 24 Jun 2008 13:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 FRnZfTA86-rP for ; Tue, 24 Jun 2008 13:46:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E69013A69FE for ; Tue, 24 Jun 2008 13:45:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 24 Jun 2008 16:47:40 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 24 Jun 2008 16:45:04 -0400 From: Hadriel Kaplan To: Dean Willis , "sip@ietf.org" Date: Tue, 24 Jun 2008 16:45:50 -0400 Thread-Topic: [Sip] Let's talk about a Dublin agenda Thread-Index: AcjWLzVVXmf8yzqAT3SGmzN/KRwFSQACpurg 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 MIME-Version: 1.0 Cc: Keith Drage Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Oy vey. That's less time than we had in Philly, and we got barely anything done there. Why can't some RAI groups overlap - for example mediactrl or xcon at the same time as speermint or drinks, or let p2psip overlap with any of those 4? -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Tuesday, June 24, 2008 3:20 PM > To: sip@ietf.org > Cc: Keith Drage > Subject: [Sip] Let's talk about a Dublin agenda > > > I've been tipped off that we may be down to as little as two hours (or > maybe 2.5) of meeting time in Dublin due to additional WG and BOF > events that didn't make it onto the earlier published agenda (like > MEDIACTRL). > > What are the absolutely most important things we need to talk about? > What is the best possible use of our very valuable and very scarce > time together? > > I suspect that going by-rote through the list of open milestones is > not the best use of our time. > > Topics that I think we might want to talk about include but are not > limited to: > > Agenda bash and announcements usually use 10 minutes > > 1) Using SAML for SIP. > -- Milestone was Dec. 2007 > -- Author has promised new rev before meeting > -- Is the WG committed to doing this work? > -- 10 minutes? > > 2) Test Matrix for SIP to Draft Standard > -- Milestone was Feb 2008 > -- How are we going to move forward? > -- 10 minutes > > 3) Delivery of Request URI and Parameters to UAS Through Proxy > -- Milestone was Feb 2008 > -- Conversation has lagged. Do we see a workable solution? > -- 30 minutes? > > 4) DTLS-SRTP > -- Milestone was Feb 2008 > -- Delayed by the RFC 4474/Gateway/B2BUA > -- Decide: Do we hold DTLS-SRTP or publish with a caveat? > -- EKR may not be attending, can we resolve on-list? (no time?) > > 5) Mechanisms for UA Initiated Privacy > -- Milestone is July 2008 > -- Author has promised new rev before meeting > -- 20 minutes? > > 6) Termination of early Dialog Prior to Final Response (199) > -- Milestone is November 2008 > -- Substantial list activity > -- 30 minutes? > > 7) Guidelines for SIP Extension Modalities > -- No milestone > -- Needs conceptual discussion > -- Defer until #8 below is resolved? (no time?) > > 8) The INFO solution and Paul's compromise for historical registration > -- No milestone > -- Previous WG consensus to "do something" > -- 40 minutes? > > > Am I missing something that is critically important? > > Which topics do we really need to talk about in order to move forward? > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 13:54:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15B93A69E9; Tue, 24 Jun 2008 13:54:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A27228C0CE for ; Tue, 24 Jun 2008 13:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 AjYO3EP6rrK7 for ; Tue, 24 Jun 2008 13:54:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5066B3A6A02 for ; Tue, 24 Jun 2008 13:54:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 24 Jun 2008 16:56:14 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 24 Jun 2008 16:53:23 -0400 From: Hadriel Kaplan To: Michael Procter , Paul Kyzivat Date: Tue, 24 Jun 2008 16:54:10 -0400 Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjWLfzx7+G20j/jR1mVbzA47h2mcAADYg6w Message-ID: References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com> <807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com> <4860F5B6.2060307@cisco.com> <4860FE00.7030601@cisco.com> <3470.87.194.179.229.1214320707.squirrel@webmail.procter.org.uk> <48613342.3050504@cisco.com> <000901c8d62e$0cbaaf60$2349a8c0@OOLONG> In-Reply-To: <000901c8d62e$0cbaaf60$2349a8c0@OOLONG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Michael Procter > > I went on to propose a half-way house between no changes for legacy > uses, and full adoption of a new framework. A lightweight[0] framework > may[1] attract new uses, but the negotiation features present in > Hadriel's current draft seem likely to deter the migration of legacy > uses. I am merely suggesting that using the INFO-labelling part of > Hadriel's draft but not the negotiation aspect could seem more > attractive[2] to legacy uses, and would still provide the rest of the > community some value (namely being able to identify all the INFO > messages flying around their networks). I don't think there's much value in documenting the labeling part without negotiation. One of the main issues right now is you don't know which INFO mechanisms the far end wants/needs/supports. There isn't really much issue with discerning what the INFO you received was for once you got it, 'cause the content-type has been unambiguous so far for all of the current usages I think (or majority thereof). It was the potential for content-type ambiguity in the future that was one of the concerns of INFO, but the real driver for me at least is the "what does the other end want/expect" problem. I'm all for making the "negotiation" part as trivial and KISS as possible - I started with what I thought was trivial, but people wanted to pile onto it to cover 3PCC and other scenarios. I'm cool with going back to simple as a better-than-nothing approach. :) -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 14:13:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F7828C12D; Tue, 24 Jun 2008 14:13:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674F028C126 for ; Tue, 24 Jun 2008 14:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 deaZ+D8t3Yab for ; Tue, 24 Jun 2008 14:13:41 -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 75DF83A67D9 for ; Tue, 24 Jun 2008 14:13:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="117860901" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2008 14:13:43 -0700 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 m5OLDg2E021570; Tue, 24 Jun 2008 14:13:42 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5OLDgqZ025201; Tue, 24 Jun 2008 21:13:42 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> Date: Tue, 24 Jun 2008 14:13:41 -0700 Message-ID: <071b01c8d63f$2e39e910$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48614E77.9010904@alcatel-lucent.com> Thread-Index: AcjWMqhH1MSti/78QWq0+4rRlq77gQADFwKw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=913; t=1214342023; x=1215206023; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=REkmFajbFLvxUMdihCq7Lhnm6bVwooB5901swZIOYwA=; b=rXPEbZl+jIr5Kam0mNAHb3uzHoNqdKL+ybwfDeXKN18odX2tGiY8nky2yG ZTDvlMdFCUEO6ztfcDWzpM7lF8rwEQhcfNxF17n48UdGU5Y9yfvfD7Sg8k8a oWPQYutu1ymGJxOWmN1jj1cUEKrmLFM541PpkZT/5qyShyEA8pyas=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > To summarize your email: anybody that needs SIP security will use > > TLS between their own proxies. That does seem to be the consensus. > > Perhaps how that works should be written up -- as in, does that mean > > when I have a TLS connection with boeing.com, I should only allow or > > only expect From: addresses that end in @boeing.com, and not > > @big-airplane.boeing.com and not @rolls-royce.com? > > Dan: I suspect you are talking of the above in the context > of SIP SAML. That wasn't my intent. > Otherwise, for certificate-based authentication > between proxies, some of what you write above is discussed in > the sip-domain-certs draft. Yes, some of it is there. Can that draft be extended to talk about validating the From of requests (and maybe responses, I'm not sure) that come from over a TLS-authenticated connection? Or would that be out of scope for it? -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 14:15:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017CE3A69FE; Tue, 24 Jun 2008 14:15:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA1F3A69E9 for ; Tue, 24 Jun 2008 14:15:53 -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=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WVyFhGQw+AT for ; Tue, 24 Jun 2008 14:15:52 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by core3.amsl.com (Postfix) with ESMTP id 4DF983A67D9 for ; Tue, 24 Jun 2008 14:15:52 -0700 (PDT) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080624212020.OXHW28496.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Tue, 24 Jun 2008 22:20:20 +0100 Received: from darjeeling.procter.org.uk ([81.104.240.101]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080624212148.QDPY16854.aamtaout01-winn.ispmail.ntl.com@darjeeling.procter.org.uk>; Tue, 24 Jun 2008 22:21:48 +0100 Received: from [192.168.73.35] (helo=OOLONG) by darjeeling.procter.org.uk with smtp (Exim 4.50) id 1KBFri-0002mh-9O; Tue, 24 Jun 2008 22:15:50 +0100 Message-ID: <00ac01c8d63f$769b92d0$2349a8c0@OOLONG> From: "Michael Procter" To: "Hadriel Kaplan" , "Paul Kyzivat" References: <6BFBFA7D-F646-4647-A084-DF383B6A8371@softarmor.com><3FC39F18-6598-4EF1-A7B8-808E8BD7951D@softarmor.com><807133087-1214075432-cardhu_decombobulator_blackberry.rim.net-2139736818-@bxe014.bisx.prod.on.blackberry><14C85D6CCBE92743AF33663BF5D24EBA06DBFE@gaalpa1msgusr7e.ugd.att.com><485D8B99.8070607@cisco.com><4860F5B6.2060307@cisco.com><4860FE00.7030601@cisco.com><3470.87.194.179.229.1214320707.squirrel@webmail.procter.org.uk><48613342.3050504@cisco.com> <000901c8d62e$0cbaaf60$2349a8c0@OOLONG> Date: Tue, 24 Jun 2008 22:15:44 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > I don't think there's much value in documenting the labeling part > without negotiation. One of the main issues right now is you don't > know which INFO mechanisms the far end wants/needs/supports. There > isn't really much issue with discerning what the INFO you received was > for once you got it, 'cause the content-type has been unambiguous so > far for all of the current usages I think (or majority thereof). It > was the potential for content-type ambiguity in the future that was > one of the concerns of INFO, but the real driver for me at least is > the "what does the other end want/expect" problem. That is exactly the use-case that I am concerned with. I've seen more than one 'application/xml' to date, and whilst I have so far been able to disambiguate those based on content analysis, I fear more are on the way. But on reflection, I suppose that vendors unwilling to declare their content more precisely are unlikely to add a new header instead. > I'm all for making the "negotiation" part as trivial and KISS as > possible - I started with what I thought was trivial, but people > wanted > to pile onto it to cover 3PCC and other scenarios. I'm cool with > going > back to simple as a better-than-nothing approach. :) I'll leave it in your capable hands then! Regards, Michael _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 14:30:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4D73A68F6; Tue, 24 Jun 2008 14:30:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068F93A68F6 for ; Tue, 24 Jun 2008 14:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 WiojxSH0+wxj for ; Tue, 24 Jun 2008 14:30:21 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 959213A681F for ; Tue, 24 Jun 2008 14:30:21 -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 m5OLU7mQ002608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 16:30:07 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5OLU4G4016149; Tue, 24 Jun 2008 16:30:04 -0500 (CDT) Message-ID: <4861675E.1010507@alcatel-lucent.com> Date: Tue, 24 Jun 2008 16:30:06 -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: Dan Wing References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> In-Reply-To: <071b01c8d63f$2e39e910$c2f0200a@cisco.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan Wing wrote: > That wasn't my intent. Dan: OK; sorry. >> Otherwise, for certificate-based authentication >> between proxies, some of what you write above is discussed in >> the sip-domain-certs draft. > > Yes, some of it is there. Can that draft be extended to talk > about validating the From of requests (and maybe responses, I'm > not sure) that come from over a TLS-authenticated connection? Or > would that be out of scope for it? I believe that validating the From would be out of scope as the draft currently stands. The draft does discuss how a receiving proxy (i.e., the one that did the passive accept) may authenticate the sender (see S7.4, http://tools.ietf.org/html/draft-ietf-sip-domain-certs-00#section-7.4), but this discussion does not normatively involve the From header. Furthermore, trying to match sender identity as carried in From to the TLS-level connection identity as carried in the certificate does not work well in the the hop-by-hop model. For instance, the sender's From may as well be user@a.com, but the last upstream proxy that opened up a connection to the recipient could be some intermediary (proxy.com) not in the a.com domain, thus making it impossible to enforce that the From must match the identity of the last upstream proxy in the certificate. Did you have some alternate or new thoughts on this to see if we can hash out something that would still be in the context of the domain-certs draft? As it stands, Scott and I are about to submit a final post WGLC revision on it by next week. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 14:35:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4B03A6858; Tue, 24 Jun 2008 14:35:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B45C3A681F for ; Tue, 24 Jun 2008 14:35:19 -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 lBJfcUhtKZ-t for ; Tue, 24 Jun 2008 14:35:18 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 0D8243A6781 for ; Tue, 24 Jun 2008 14:35:16 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP; Tue, 24 Jun 2008 14:35:14 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 m5OLZAE0024420; Tue, 24 Jun 2008 14:35:10 -0700 (PDT) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m5OLZ2qN000535; Tue, 24 Jun 2008 14:35:08 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 06:35:05 +0900 Received: from 10.58.20.192 ([10.58.20.192]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 21:35:02 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 14:35:02 -0700 From: Henry Sinnreich To: Paul Kyzivat Message-ID: Thread-Topic: [Sip] INFO and what to do about it? Thread-Index: AcjWQijBs90ctDgQkEGvDGGfNFQeRQ== In-Reply-To: <48613781.2080603@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 21:35:05.0054 (UTC) FILETIME=[2A9347E0:01C8D642] Cc: SIP@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] INFO and what to do about it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > You seem to be changing philosophy here. Not at all. The philosophy is very simple: Use "simple SIP" - basically the rendezvous and session setup functions, be they CS or P2P. Everything else related to SIP applications and customer demands (I understand Jonathan's desire) can be better accomplished with API's, SDKs, IDE's and various tool kits as is customary in the industry. (Unfortunately we have other tools: Concept papers, frameworks, etc.) This presumes however respecting the e2e Internet principle, the "dumb network" architecture and the applications in the endpoints. Henry On 6/24/08 11:05 AM, "Paul Kyzivat" wrote: > Henry, > > You seem to be changing philosophy here. These existing uses of INFO are > *running code*. Why doesn't that make them the good candidates for > standardization? > > Paul > > Henry Sinnreich wrote: >>> If we don't listen to our customers - the people who have >>> deployed and are actually using it - what purpose does our work serve? >> >> This is what the managers of the typewriter business must have said when the >> word processors appeared: "Our customers ask for a white-out ribbon and for >> a price under $500." >> >> A PC at that time cost $5,000 and the additional laser printer was another >> $5,000. >> >> Some companies opted for the PC business nevertheless and did NOT listen to >> their customers. >> >> Does anyone care for simple SIP that can be understood by developers with >> limited time on their hands? >> >> Henry >> >> >> On 6/24/08 6:25 AM, "Jonathan Rosenberg" wrote: >> >>> >>> Mary Barnes wrote: >>>> I don't believe we could ever forbid INFO. I initially did not think >>>> we could accomplish anything around INFO, but I believe some of the >>>> work that's on the table would be useful for working towards >>>> interoperabilty for the INFO usages. I would be afraid to ask >>>> honestly for the identification of all the different uses of INFO >>>> that are out there right now. >>> I don't think we should be afraid of this at all. >>> >>> There are (sometimes/often) good reasons why folks resort to these >>> solutions. Our job here at IETF is to ensure interoperability for the >>> SIP protocol. If we don't listen to our customers - the people who have >>> deployed and are actually using it - what purpose does our work serve? >>> >>> >>>> Doing something is better than nothing at this point IMHO and I'm >>>> personally really tired of revisiting this issue every couple of >>>> years. AND, this would help us put a stake in the group on the future >>>> usages of INFO (whether we ever get rid of the old usages or not), as >>>> I believe there are other SDOs defining new uses of INFO right now to >>>> add to the mix of un-interoperability in this area. >>> As long as SIP usage continues to rise, I suspect we will continue to >>> see more INFO usages. Just because we cannot fix what is broken in the >>> past, doesn't mean we should let it remain broken for the future. >>> >>> -Jonathan R. >>> >> >> _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 14:44:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA643A68F0; Tue, 24 Jun 2008 14:44:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496A13A68F0 for ; Tue, 24 Jun 2008 14:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 V7i+lDSSacAh for ; Tue, 24 Jun 2008 14:44:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4FF3B3A67D9 for ; Tue, 24 Jun 2008 14:44:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="34028422" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 24 Jun 2008 14:44:47 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5OLil9A004760; Tue, 24 Jun 2008 14:44:47 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5OLilO2014981; Tue, 24 Jun 2008 21:44:47 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> Date: Tue, 24 Jun 2008 14:44:46 -0700 Message-ID: <076c01c8d643$85c210a0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4861675E.1010507@alcatel-lucent.com> Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3132; t=1214343887; x=1215207887; c=relaxed/simple; s=sjdkim2002; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=gy/pZhWG2sPWqX8PpoR9fJCch68YzApxe2xqP/yX66M=; b=oYzdC/j/wqKGYjcm2vCRhushZvwF3CfL+2Iwo46c4qNrngtUmlOVbXRqUZ /AslbPi5IMq8pjwhYYAEdP4jpYW3tD+HrbkcFV29XDcGO2p27Z/F1KDRnVgq +PaEUHvoqA; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Tuesday, June 24, 2008 2:30 PM > To: Dan Wing > Cc: sip@ietf.org > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > Dan Wing wrote: > > That wasn't my intent. > > Dan: OK; sorry. No worries. > >> Otherwise, for certificate-based authentication > >> between proxies, some of what you write above is discussed in > >> the sip-domain-certs draft. > > > > Yes, some of it is there. Can that draft be extended to talk > > about validating the From of requests (and maybe responses, I'm > > not sure) that come from over a TLS-authenticated connection? Or > > would that be out of scope for it? > > I believe that validating the From would be out of scope as > the draft currently stands. The draft does discuss how a > receiving proxy (i.e., the one that did the passive accept) > may authenticate the sender (see S7.4, > http://tools.ietf.org/html/draft-ietf-sip-domain-certs-00#sect > ion-7.4), > but this discussion does not normatively involve the From > header. Right. > Furthermore, trying to match sender identity as carried in > From to the TLS-level connection identity as carried in the > certificate does not work well in the the hop-by-hop model. > For instance, the sender's From may as well be user@a.com, but > the last upstream proxy that opened up a connection to the > recipient could be some intermediary (proxy.com) not in the > a.com domain, thus making it impossible to enforce that the > From must match the identity of the last upstream proxy in the > certificate. Agreed. > Did you have some alternate or new thoughts on this to see if > we can hash out something that would still be in the context > of the domain-certs draft? As it stands, Scott and I are about > to submit a final post WGLC revision on it by next week. I don't think extending domain-cert's scope would be wise -- rather, I do think this is a separate problem. The separate problem is that with *some domains* you connect to (and do domain-certs validation with), you trust them to claim and use any old "From" they want -- because with those domains you trust them to have done some validation of their previous hop, who validated their previous hop, etc. This is how you would configure a SIP trunk with a service provider, for example. However, if you are communicating directly with another organization then you would not want to allow them to assert any identity they wished, because the only identity you expect them to send you requests with a From that had their own identity (@microsoft.com, @boeing.com, etc.) -- that is, the identity of their own employees. You do not expect them to assert the identity belonging to some other company. You would not extend the transitive trust to them. I do wish there was more interest in cryptographic end-to-end identity that survives through B2BUAs operated by service providers. It is the end goal; service provider B2BUAs/SBCs are not going away! -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 14:59:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8F53A6896; Tue, 24 Jun 2008 14:59:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78EC13A688A for ; Tue, 24 Jun 2008 14:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 hNOUhb7Yd1Kc for ; Tue, 24 Jun 2008 14:59:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5212F3A6834 for ; Tue, 24 Jun 2008 14:59:24 -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 m5OLxOZO024440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 16:59:24 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5OLxLO8008452; Tue, 24 Jun 2008 16:59:21 -0500 (CDT) Message-ID: <48616E3C.2060800@alcatel-lucent.com> Date: Tue, 24 Jun 2008 16:59:24 -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: Dan Wing References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> In-Reply-To: <076c01c8d643$85c210a0$c2f0200a@cisco.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan Wing wrote: > However, if you are communicating directly with another > organization then you would not want to allow them to assert > any identity they wished, because the only identity you expect > them to send you requests with a From that had their own > identity (@microsoft.com, @boeing.com, etc.) -- that is, > the identity of their own employees. You do not expect them > to assert the identity belonging to some other company. You > would not extend the transitive trust to them. > > I do wish there was more interest in cryptographic end-to-end > identity that survives through B2BUAs operated by service providers. > It is the end goal; service provider B2BUAs/SBCs are not going > away! The sipsec URI (http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01). Sorry could not resist ;-) Though that is not a panacea either since I doubt any B2BUA operated by the service provider will agree to behave as a transparent bit forwarder (although there are crypto- techniques to allow intermediaries to snoop in an encrypted stream to look only for certain keywords. But I doubt that work is to a point that one can create a scalable production system out of it.) There is also some work on using IBE (see http://tools.ietf.org/html/draft-kupwade-sip-iba-00); this draft was discussed on the list before the PHL IETF. IIRC, the discussions centered around problems with key escrow. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 15:05:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1C93A68F0; Tue, 24 Jun 2008 15:05:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D664B3A6896 for ; Tue, 24 Jun 2008 15:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 B2l7IluSxRLq for ; Tue, 24 Jun 2008 15:05:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E4D583A67FD for ; Tue, 24 Jun 2008 15:05:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BA738204C8; Wed, 25 Jun 2008 00:05:05 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-87-48616f91d37a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8A9522024B; Wed, 25 Jun 2008 00:05:05 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 00:05:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 00:05:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep thread-index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAETNKsAAA+WlQAACwqdAADHnwwA== References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E384@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Elwell, John" , "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 24 Jun 2008 22:05:32.0997 (UTC) FILETIME=[6C1D3F50:01C8D646] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, As I said before, I would be happy to extend the scope to also cover proxy-= proxy. I have also received an off-line comment indicating that it would be= useful. I don't think it would change the mechanism itself, so... So, if we choose to move forward with the draft I would then update the sco= pe etc it in the next version. Does that sound ok? Regards, Christer = -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] = Sent: 24. kes=E4kuuta 2008 19:11 To: Elwell, John; DRAGE, Keith (Keith); sip@ietf.org Cc: Christer Holmberg Subject: RE: [Sip] Progress draft-holmberg-sip-keep Those cases are the ones I said would be useful in my original email far be= low. I.e., when I said "two reasons not cited: PBX connections a la SIP tr= unks, and proxy-proxy connections." They are not identical, in the sense t= hat an IP-PBX can be a b2bua/UA/whatever, but also in the sense of their ex= ample use-case, for example an IP-PBX could be behind a NAT and thus want t= his keep-alive for more reasons than a proxy-proxy. -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, June 24, 2008 11:48 AM > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > Hadriel, > > That trunking case is no different from other trunking cases, e.g., = > proxy-to-proxy, and I have already suggested to Christer that he might = > extend the scope of the draft to cover that. It would be good to have = > some discussion on whether keep-alive on "trunking" interfaces would = > be beneficial - I have an open mind on that at present. > > John > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: 24 June 2008 16:32 > > To: Elwell, John; DRAGE, Keith (Keith); sip@ietf.org > > Cc: Christer Holmberg > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > Hey John, > > For the case where the IP-PBX registers into the SP, outbound can be = > > used. But it's the other case I was talking about: > > where the IP-PBX does NOT register into the SP, but it instead is a = > > trunk. > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Tuesday, June 24, 2008 3:15 AM > > > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > > > Cc: Christer Holmberg > > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > > > Hadriel, > > > > > > Concerning your "PBX connections a la SIP trunks" use case, I am = > > > not convinced of this. ETSI TISPAN has specified two ways for > > an IPPBX to > > > connect to a service provider. One is the so-called > > subscription-based > > > approach, where the IPPBX registers with the SP and > > communicates via an > > > edge proxy. In this case, why not use SIP-outbound? The other is = > > > the so-called peering-based approach, which is essentially the > > same as any > > > SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway. > > > SIP-outbound does not apply to these situations, and similarly the = > > > keep-alive mechanism is not specified for this cases. The > > requirements > > > in SIP-keep do not cover these situations. > > > > > > Basically I am not sold on the idea of a separate SIP-keep spec - = > > > I don't think it would be the best use of WG time. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = > > > > Behalf Of Hadriel Kaplan > > > > Sent: 20 June 2008 18:20 > > > > To: DRAGE, Keith (Keith); sip@ietf.org > > > > Cc: Christer Holmberg > > > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > > > > > My 2 cents: it is a useful draft. Personally, I would like to = > > > > have it available for two reasons not cited: PBX connections a = > > > > la SIP trunks, and proxy-proxy connections. > > > > Today I think a lot of people are using OPTIONS requests or = > > > > proprietary means to perform such keep-alives when registration = > > > > is not appropriate, but it has led to some interop issues and = > > > > performance concerns in some cases. > > > > > > > > Since the contentious issue of what form the keep-alives take = > > > > have already been agreed on for outbound, this seems like a = > > > > simple draft to get done. (famous last words, I know) > > > > > > > > -hadriel > > > > > > > > > > > > > -----Original Message----- > > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > > Behalf Of > > > > > DRAGE, Keith (Keith) > > > > > Sent: Thursday, June 19, 2008 5:31 AM > > > > > To: sip@ietf.org > > > > > Cc: Christer Holmberg > > > > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > > > (As SIP WG cochair) > > > > > > > > > > We have been asked by the author of > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > > > > > Whether the SIP WG can progress this document. > > > > > > > > > > Because this draft arose as a result of the discussion of > > > > outbound, and > > > > > indeed seems to reuse the requirements from outbound, and = > > > > > these requirements never really got handled in the SIPPING > > WG, it has been > > > > > agreed with the SIPPING chairs that we will handle this > > > > entirely within > > > > > SIP. > > > > > > > > > > Now in order to ask for charter milestones, and indeed when > > > > we finally > > > > > present this to IESG, we will be asked for the level of > > > > support in the > > > > > WG, which is also predicated on does this fix a real > > > > problem, or is it > > > > > just a corner case with limited application. So: > > > > > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > > important to > > > > > proceed with this draft? The document states: > > > > > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 > > [I-D.ietf-sip-outbound] > > > > > defines two keep-alive techniques. Even though the > > keep-alive > > > > > techniques are separated from the Outbound mechanism > > > > > [I-D.ietf-sip-outbound], it is currently not > > possible to indicate > > > > > support of the keep-alive techniques without also > > > > indicating support > > > > > for the Outbound mechanism. > > > > > > > > > > The Outbound mechanism is enabled during the UA > > > > registration phase. > > > > > However, there are use-cases where the UA does not > > > > register itself, > > > > > but still needs to be able to make calls and maintain > > > > NAT bindings > > > > > open during the duration of that call. A typical example is > > > > > emergency calls. There are also cases where entities do > > > > not support > > > > > the Outbound mechanism, but still want to be able to > > > > indicate support > > > > > and use the keep-alive techniques defined in > > > > [I-D.ietf-sip-outbound]. > > > > > > > > > > At first sight this is not the most inspiring declaration > > > > of the need > > > > > for the document. Please respond indicating whether you > > > > consider this a > > > > > useful draft, and propose text that you think would be > > > > useful in this > > > > > section. Conversely, if you think this draft is not useful > > > > and the WG > > > > > has other more important things to work on first, please > > > > also respond. > > > > > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of > > requirements for > > > > > proceeding with this work? The document currently lists: > > > > > > > > > > REQ 1: It MUST be possible for a UA to indicate support > > > > of the keep- > > > > > alive techniques defined [I-D.ietf-sip-outbound] if the > > > > UA supports > > > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > > > > > REQ 2: It MUST be possible for an edge proxy to indicate > > > > support of > > > > > the keep-alive techniques defined > > > > [I-D.ietf-sip-outbound] if the edge > > > > > poxy supports only the keep-alive part of > > > > [I-D.ietf-sip-outbound]. > > > > > > > > > > It would be desirable to agree these at the outset, and not > > > > revisit them > > > > > if we continue with the work. So if you require clarification, = > > > > > modification, or addition to these two requirements, then > > > > please also > > > > > response with your questions and proposals. > > > > > > > > > > I suggest we would like responses by 30th June 2008 in > > > > order to allow > > > > > the author to revise the document before the deadlines. > > > > Please note that > > > > > we are looking to make this decision on the list within > > > > this deadline > > > > > based on responses received, not leave it until the > > Dublin meeting. > > > > > > > > > > Regards > > > > > > > > > > Keith > > > > > _______________________________________________ > > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use = > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > _______________________________________________ > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use = > > > > sip-implementors@cs.columbia.edu for questions on current sip = > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 15:08:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586FB3A69FA; Tue, 24 Jun 2008 15:08:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3654C3A69F9 for ; Tue, 24 Jun 2008 15:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 BEUzn9W3qkXJ for ; Tue, 24 Jun 2008 15:08:14 -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 63A153A67FD for ; Tue, 24 Jun 2008 15:08:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="83047641" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2008 15:08:15 -0700 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 m5OM8FYD019701; Tue, 24 Jun 2008 15:08:15 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5OM8FFS020426; Tue, 24 Jun 2008 22:08:15 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <48616E3C.2060800@alcatel-lucent.com> Date: Tue, 24 Jun 2008 15:08:15 -0700 Message-ID: <07a701c8d646$cd02d9b0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48616E3C.2060800@alcatel-lucent.com> Thread-Index: AcjWRZfsNswyt8I+RkuX5KbPZPYsGAAAKqZg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1864; t=1214345295; x=1215209295; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=nF7PPYK/qDiWHpD0npNpt7CuEvFj6H2DbEh5STUug8M=; b=Om8YofOPoaYK7xt97pnfG/Os0krg1yJdZhUf19AMYc3rtiNECfB/5S3llj wLKb7ohM2RBK5XOln+9Vw59KiGrKfir+QNg7M7h902HYIvHRMCKl30l1OXmH 1g9pEjCE7dAtQVyV3lqY0AL6oUmkK/d/5QTAadEKxYU3Wc69oCZ/4=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Dan Wing wrote: > > However, if you are communicating directly with another > > organization then you would not want to allow them to assert > > any identity they wished, because the only identity you expect > > them to send you requests with a From that had their own > > identity (@microsoft.com, @boeing.com, etc.) -- that is, > > the identity of their own employees. You do not expect them > > to assert the identity belonging to some other company. You > > would not extend the transitive trust to them. > > > > I do wish there was more interest in cryptographic end-to-end > > identity that survives through B2BUAs operated by service > > providers. > > It is the end goal; service provider B2BUAs/SBCs are not going > > away! > > The sipsec URI > (http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01). > Sorry could not resist ;-) heh. Yeah, I think SIP four-oh had a few ideas in that space, too. > Though that is not a panacea either since I doubt any B2BUA > operated by the service provider will agree to behave as a > transparent bit forwarder (although there are crypto- > techniques to allow intermediaries to snoop in an encrypted > stream to look only for certain keywords. But I doubt that work > is to a point that one can create a scalable production system > out of it.) > > There is also some work on using IBE (see > http://tools.ietf.org/html/draft-kupwade-sip-iba-00); this draft > was discussed on the list before the PHL IETF. IIRC, the > discussions centered around problems with key escrow. There are also http://tools.ietf.org/html/draft-wing-sip-identity-media-02 and http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00, both of which propose slightly different techniques that are a middleground between sipsec and (today's) blind transitive trust. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 15:38:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ECDB3A69A1; Tue, 24 Jun 2008 15:38:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4E83A6998 for ; Tue, 24 Jun 2008 15:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 2tfCVEBirwEa for ; Tue, 24 Jun 2008 15:38:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D46033A681F for ; Tue, 24 Jun 2008 15:38:36 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OMcZ54019638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 17:38:36 -0500 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E42A@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 17:38:28 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E42A@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org, Keith Drage Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 3:17 PM, Elwell, John wrote: >> >> >> 2) For the remainder, I'd like to suggest the "REal Time >> Identity and >> Role Expression" (RETIRE) Working Group, which would take >> over the RFC >> 4474 revision along with SIP-SAML. > [JRE] Will that produce results before we all retire? But seriously, a > new WG might be a good idea, but how long to set it up? What needs > to be > done at or before Dublin in that direction? Well, a new working group starts with a BOF request and a draft charter and somebody who wants the WG badly enough to do the leg work and chair the BOF. It's a little late in the cycle to get one of those in for Dublin, but we could certainly start talking about a draft charter, then run a BOF at the next meeting. That would fit squarely with my goal of ramping down the "eternal SIP group" by fall 2009. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 15:42:00 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BFB3A688E; Tue, 24 Jun 2008 15:42:00 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFC93A681F for ; Tue, 24 Jun 2008 15:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 3V4xVEmJObCj for ; Tue, 24 Jun 2008 15:41:58 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ABC483A6896 for ; Tue, 24 Jun 2008 15:41:58 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5OMfwRU019683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 17:41:59 -0500 From: Dean Willis To: eburger@standardstrack.com In-Reply-To: <1762171404-1214338174-cardhu_decombobulator_blackberry.rim.net-707116175-@bxe014.bisx.prod.on.blackberry> X-Priority: Normal References: <1762171404-1214338174-cardhu_decombobulator_blackberry.rim.net-707116175-@bxe014.bisx.prod.on.blackberry> Message-Id: <8E9A8381-DC0A-4548-9DA2-D437A7F21383@softarmor.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 17:41:52 -0500 X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 3:09 PM, eburger@standardstrack.com wrote: > Hey - not our fault - we got our request in on time. > > That said, I would offer #2 is possibly the most important work > item, as it will drive a coherent, scoped work plan. #2 was: 2) Test Matrix for SIP to Draft Standard -- Milestone was Feb 2008 -- How are we going to move forward? -- 10 minutes > > > > How is this for a far-fetched thought: SIP to DS is the *only* work > item for the SIP work group. If we could not get X done in 10 years > (yes, it has been that long for some of these things), let us > charter a new work group to work on X. > Sent from my Verizon Wireless BlackBerry How about SIP to Draft Standard as the only work item for a new WG? That's a pretty crisply defined charter. Our current milestone is only to define a test matrix; said test matrix being input to some other work process that either takes SIP to Draft or decides it can't be done. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 15:50:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E14E3A6858; Tue, 24 Jun 2008 15:50:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1383A682C for ; Tue, 24 Jun 2008 15:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 0usuviNwwtj7 for ; Tue, 24 Jun 2008 15:50:23 -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 A7C3D3A6896 for ; Tue, 24 Jun 2008 15:50:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="83057851" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2008 15:50:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5OMoNrB017828; Tue, 24 Jun 2008 15:50:23 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5OMoJaJ012687; Tue, 24 Jun 2008 22:50:21 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Elwell, John'" References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net> Date: Tue, 24 Jun 2008 15:50:19 -0700 Message-ID: <081701c8d64c$afdcc980$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjWMziFGscCbHfJS3mPUpoIckjGmgAGWwjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1159; t=1214347823; x=1215211823; 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[Sip]=20Let's=20talk=20about=20a=20Dubl in=20agenda |Sender:=20; bh=aV4Tq0Cb+jaAj7odxsW9ThrqBDLZjyDy8V0NJuicAcY=; b=EinstygYRMHPMIwcTY49+dr18ydCLQN2g2jBrvFK5Mvvu8up7kTQBx/H0+ JsQbHjUBETTTD5nk3SPYo+w0LtJQeabxt0KVvNGltuk0EJ9oWwF/bmJ+T8Qt JkbmgIG3AGmopw4J8qd2VkRAoLK/IUhB/8ZezJjzXIklWdqW2ClAU=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Keith Drage' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Tuesday, June 24, 2008 12:48 PM > To: Elwell, John > Cc: sip@ietf.org; Keith Drage > Subject: Re: [Sip] Let's talk about a Dublin agenda > > > On Jun 24, 2008, at 2:38 PM, Elwell, John wrote: > > > Dean, > > > > Well, just how exactly do we go about resolving the various Identify > > issues (E.164 / SBCs / gateways)? I think Dan has tried > unsuccessfully > > for a BoF earlier. No agenda time in SIP this time. There > have been > > some > > huge email threads since Philadelphia. There are several relevant > > drafts > > around (and possibly more before Dublin). > > > > My suggestion is in two parts: > > 1) For DTLS-SRTP Framework, simply document the limitation of > RFC 4474 > and move on. This is a one-paragraph add to the framework. Sounds good. > 2) For the remainder, I'd like to suggest the "REal Time > Identity and > Role Expression" (RETIRE) Working Group, which would take > over the RFC > 4474 revision along with SIP-SAML. Sounds good, too. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 15:51:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7053A695D; Tue, 24 Jun 2008 15:51:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE703A688A for ; Tue, 24 Jun 2008 15:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 yqcaHVhD1FrI for ; Tue, 24 Jun 2008 15:51:27 -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 630923A695D for ; Tue, 24 Jun 2008 15:51:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="59981320" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2008 15:51:28 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5OMpSvl013347; Tue, 24 Jun 2008 15:51:28 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5OMpMr0016349; Tue, 24 Jun 2008 22:51:23 GMT From: "Dan Wing" To: "'Dean Willis'" , , "'Eric Rescorla'" , "'Jason Fischl'" References: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> Date: Tue, 24 Jun 2008 15:51:21 -0700 Message-ID: <081801c8d64c$d6909fc0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> Thread-Index: AcjWHt56HfeHRmgVSOGTSqlcopYg2AALfCAw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2202; t=1214347888; x=1215211888; c=relaxed/simple; s=sjdkim2002; 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[Sip]=20A=20proposal=20for=20breaking=2 0the=20DTLS-SRTP=20vs=20RFC4474=20gatewaydeadlock |Sender:=20; bh=b4mGrtx8H5lbSyL+N+gK+vG61+B6vo3GFCIOMgH2kaU=; b=L71ltZwDM/7zSrVw6RKr4zu0aPnfqK6Fo+Q7dQQ5JTjfUnNTh9xVMMNKo5 Ix8/fIsg6b0YpJLYwJNiozOUHtyYwBoP9f6SBwMFVmj+ULgR1UvzsvA8oOlH oU85+vmP+w; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Cullen Jennings' , 'Keith Drage' Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gatewaydeadlock X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Works for me. Thanks, -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Tuesday, June 24, 2008 10:22 AM > To: sip@ietf.org; Eric Rescorla; Jason Fischl > Cc: Cullen Jennings; Keith Drage > Subject: [Sip] A proposal for breaking the DTLS-SRTP vs > RFC4474 gatewaydeadlock > > > We've gotten stuck on a fine point in DTLS-SRTP. > > The current draft-ietf-sip-dtls-srtp-framework-01 uses an RFC 4474 > Identity header to preserve the integrity of the media key's > fingerprint, thereby detecting a certain class of MITM attack. > > However, RFC 4474 Identity headers are of questionable validity when > used with protocol gateways or B2BUAs. More or less, they're > capable > of asserting the identity of the gateway, not the identity of the > calling party. But the recipient has no real way to figure out which > is which. > > We've debated at some length, and with no good result, about whether > we should try and fix RFC 4474. We've had some suggestions that may > work for B2BUAs, and some other suggestions that may work for > gateways, but we certainly don't have a consensus. > > That leaves our chartered deliverable of DTLS-SRTP hanging, and the > milestone has gone past months ago. > > Here's a proposal: > > We add a caveat about the limitation of RFC 4474 to draft-ietf-sip- > dtls-srtp-framework and go ahead and advance that specification. If > somebody later decides to fix RFC 4474, they can do so, and if > necessary update DTLS-SRTP if needed. > > > Does that work for everybody? > > If we agree to it, I suggest that we move the date for WGLC of draft- > ietf-sip-dtls-srtp-framework to July 2008, and move the > milestone for > delivery of that doc to the IESG into September. > > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 15:55:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BC83A6897; Tue, 24 Jun 2008 15:55:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3889C3A6897 for ; Tue, 24 Jun 2008 15:55:58 -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 vEecJGTau53s for ; Tue, 24 Jun 2008 15:55: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 64DF03A688E for ; Tue, 24 Jun 2008 15:55:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="44195387" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2008 15:55:59 -0700 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 m5OMtwV4024784; Tue, 24 Jun 2008 15:55:59 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5OMtwwI019717; Tue, 24 Jun 2008 22:55:58 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Elwell, John'" References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net><0D5F89FAC29E2C41B98A6A762007F5D0D6E42A@GBNTHT12009MSX.gb002.siemens.net> Date: Tue, 24 Jun 2008 15:55:58 -0700 Message-ID: <084a01c8d64d$77f61160$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjWSxv1Zz0VLam/TMW4ay0MJ1rOHAAAcVhw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1816; t=1214348159; x=1215212159; 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[Sip]=20Let's=20talk=20about=20a=20Dubl in=20agenda |Sender:=20; bh=fWPvbC6ZOspQrLFWysNWYmHkMMz4n+O7YTjBr+uVH+I=; b=tq9UfZa6O4DfuBnOlgmSILxiVt4MXPchK7k9tC/bPMIrfC4JU/n7cl8EDn CmKRcrVBz0BqJ0FjigGJLZRmljM6cLYQo9nvN4NzuWNz3/c5goa4EmGu5Iry OYh35lkSkTTuPJUNo72HFaAn9f0kVZsnVUT8ihvZRWXTaiP7fbTnI=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Keith Drage' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Tuesday, June 24, 2008 3:38 PM > To: Elwell, John > Cc: sip@ietf.org; Keith Drage > Subject: Re: [Sip] Let's talk about a Dublin agenda > > > On Jun 24, 2008, at 3:17 PM, Elwell, John wrote: > > >> > >> > >> 2) For the remainder, I'd like to suggest the "REal Time > >> Identity and > >> Role Expression" (RETIRE) Working Group, which would take > >> over the RFC > >> 4474 revision along with SIP-SAML. > > [JRE] Will that produce results before we all retire? But > seriously, a > > new WG might be a good idea, but how long to set it up? What needs > > to be > > done at or before Dublin in that direction? > > Well, a new working group starts with a BOF request and a draft > charter and somebody who wants the WG badly enough to do the > leg work and chair the BOF. You say that as if nobody tried before. I requested a BoF for Philadelphia, called Discussion and Analysis of SIP Identity (DASI). It was turned down by the IESG, and did not have the support of the RAI ADs. I have received no indication that additional people in SIP cared about the problem (beyond the ~6 or so involved in the thread we had on the list), nor an indication from the RAI ADs that our email threads on SIP after the Philadelphia meeting had swayed their opinion. I could continue to beat my head against the wall, but I can't see through the blood as it is. > It's a little late in the cycle to get one of those in for > Dublin, but we could certainly start talking about a draft > charter, then run a BOF at the next meeting. That would fit > squarely with my goal of ramping down the "eternal SIP group" > by fall 2009. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:06:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE713A688E; Tue, 24 Jun 2008 16:06:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D483A69B4 for ; Tue, 24 Jun 2008 16:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 oBX5lUDLNPE6 for ; Tue, 24 Jun 2008 16:06:56 -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 5F9F73A6897 for ; Tue, 24 Jun 2008 16:06:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="59985488" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2008 16:06:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5ON6dRR002278; Tue, 24 Jun 2008 16:06:39 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5ON6d5t029410; Tue, 24 Jun 2008 23:06:39 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Dean Willis'" , References: Date: Tue, 24 Jun 2008 16:06:38 -0700 Message-ID: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjWLzVVXmf8yzqAT3SGmzN/KRwFSQACpurgAAVAu3A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=435; t=1214348800; x=1215212800; c=relaxed/simple; s=sjdkim2002; 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[Sip]=20Let's=20talk=20about=20a=20Dubl in=20agenda |Sender:=20; bh=dd3mF6TBAKZY5q0yce1z9Jnjp2YFxy+Zzw1MxQN/svo=; b=wVtFye9BjzjYrOCmTZo72nYLwhw8SD9HZEgUog1JGXFLEC1P4XCUMlrDqF qZeOZqeow3tJ//WzF54dW155QXNv7+05Rpw7wIVqo+/7cEqFuobcbIuMXZnX GWoO87cetP; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Keith Drage' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Oy vey. That's less time than we had in Philly, and we got > barely anything done there. > > Why can't some RAI groups overlap - for example mediactrl or > xcon at the same time as speermint or drinks, or let p2psip > overlap with any of those 4? I was shot down when I proposed it: http://www.ietf.org/mail-archive/web/rai-discuss/current/threads.html#00009 I do hope we reconsider. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:12:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9970B3A6858; Tue, 24 Jun 2008 16:12:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C6E3A6858 for ; Tue, 24 Jun 2008 16:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 MwtvBPQmca3E for ; Tue, 24 Jun 2008 16:12:46 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 98A723A6820 for ; Tue, 24 Jun 2008 16:12:46 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5ONCfL19798; Tue, 24 Jun 2008 23:12:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 18:09:47 -0500 Message-ID: In-Reply-To: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Let's talk about a Dublin agenda Thread-Index: AcjWLzVVXmf8yzqAT3SGmzN/KRwFSQACpurgAAVAu3AAAAdaoA== References: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com> From: "Mary Barnes" To: "Dan Wing" , "Hadriel Kaplan" , "Dean Willis" , Cc: Keith Drage Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan - your suggestion was for groups that have more overlap (e.g., SIP, MMUSIC with XCON, MEDIACTRL). The groups Hadriel is explicitly suggesting might just work (well it does for me :). Mary. - who was the one that shot Dan down last time. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dan Wing Sent: Tuesday, June 24, 2008 6:07 PM To: 'Hadriel Kaplan'; 'Dean Willis'; sip@ietf.org Cc: 'Keith Drage' Subject: Re: [Sip] Let's talk about a Dublin agenda Hadriel Kaplan wrote: > Oy vey. That's less time than we had in Philly, and we got barely > anything done there. > > Why can't some RAI groups overlap - for example mediactrl or xcon at > the same time as speermint or drinks, or let p2psip overlap with any > of those 4? I was shot down when I proposed it: http://www.ietf.org/mail-archive/web/rai-discuss/current/threads.html#00 009 I do hope we reconsider. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:20:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09953A688E; Tue, 24 Jun 2008 16:20:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2C33A6896 for ; Tue, 24 Jun 2008 16:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 w2jbbQ3-4X76 for ; Tue, 24 Jun 2008 16:20:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 622D33A688E for ; Tue, 24 Jun 2008 16:20:19 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5ONKI2O019934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 24 Jun 2008 18:20:20 -0500 Message-Id: From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 18:20:13 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] First draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a first-pass at what I think we might do with a RETIRE working group --------------- The "REal Time Identity and Role Expression" (RETIRE) Working Group's purpose is to standardize the expression and assertion of identity and roles needed for real-time communications with the IETF's Realtime Applications Infrastructure (RAI) area protocols, primarily the Session Initiation Protocol (SIP) and others used in conjunction with SIP. By "Identity", we mean authenticated addresses of record (as defined in RFC 4474 "Enhancements for Authenticated Identity Management in the Session Initiation Protocol". RFC 4474 provides a means by which a SIP server may vouch for the "From" address of a request transiting that server. It further provides a cryptographic mechanism for testing the source of the assertion. In the typical case, this mechanism is dependent on the same Public Key Infrastructure that supports secure HTTP services. Since RFC 4474 provides only authentication of the source of SIP request messages and it is also important to determine the identity of the sender of responses, RFC 4916 "Connected Identity in the Session Initiation Protocol" provides authenticated identity in an ongoing SIP dialog by applying RFC 4474 to requests in the reverse direction. While adequate for some scenarios, this mechanism is not useful for SIP interactions having a single non-dialog transaction, such as MESSAGE requests. RFC 4474 suffers additional limitations relating to its use with gateways, session border controllers, and back-to-back user agents. By "Role", we mean aspects of a a system user that are related identity, but more dynamic in nature. For example, Alice might delegate her calls to Alice. A calling party, expecting to reach Alice but reaching Bob, needs to know that this is a reasonable thing and what Bob's role in relation to Alice is. This problem is in general referred to as the "unanticipated respondent problem", and it has impacts both at the level of user expectations and key management. Proposals for fixing it have included deprecation of proxy retargeting and the use of a new SIP provisional response to inform the calling party about the retargeting operation. Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee. The SIP working group worked for several years on applying SAML to SIP with mixed results, but the technique appears to have great promise. The initial deliverables of the RETIRE working group are: 1) A standards-track revision of RFC 4474 that resolves its limitations with respect to gateways, session border controllers, and back-to-back user agents. This revision will also address the use of Authenticated Identity Management in conjunction with SIP response messages. 2) Specify a solution for the Unanticipated Respondent Problem in SIP. 3) Guidelines for the use of SAML with SIP for the purposes of expressing identity and role, specifically in the contexts of #1 and #2 above. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:23:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BB63A6896; Tue, 24 Jun 2008 16:23:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FA73A6896 for ; Tue, 24 Jun 2008 16:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 3t0icq-QeMS7 for ; Tue, 24 Jun 2008 16:23:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C821E3A688E for ; Tue, 24 Jun 2008 16:23:16 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5ONN6HT019963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 18:23:07 -0500 Message-Id: <0BD298DC-85C1-4A87-8FA5-503BE46F277D@softarmor.com> From: Dean Willis To: "Dan Wing" In-Reply-To: <084a01c8d64d$77f61160$c2f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 18:23:00 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net><0D5F89FAC29E2C41B98A6A762007F5D0D6E42A@GBNTHT12009MSX.gb002.siemens.net> <084a01c8d64d$77f61160$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org, 'Keith Drage' , "'Elwell, John'" Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 5:55 PM, Dan Wing wrote: >>> >> >> Well, a new working group starts with a BOF request and a draft >> charter and somebody who wants the WG badly enough to do the >> leg work and chair the BOF. > > You say that as if nobody tried before. I requested a BoF for > Philadelphia, called Discussion and Analysis of SIP Identity > (DASI). It was turned down by the IESG, and did not have the > support of the RAI ADs. True, However, the approach you took at that time wasn't clearly coordinated as a handoff of responsibility from the SIP working group. That's what I propose to try now. We should also consider that much of the proposed work of RUCUS (Reducing Unwanted Communications Using SIP), aka anti-SPIT, depend on strong identity. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:29:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02D43A6A24; Tue, 24 Jun 2008 16:29:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F763A6A55 for ; Tue, 24 Jun 2008 16:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWqmHdPkt4ar for ; Tue, 24 Jun 2008 16:29:45 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.247]) by core3.amsl.com (Postfix) with ESMTP id 718293A6A24 for ; Tue, 24 Jun 2008 16:29:45 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so22948876agb.12 for ; Tue, 24 Jun 2008 16:29:44 -0700 (PDT) Received: by 10.100.154.9 with SMTP id b9mr16795853ane.78.1214350183770; Tue, 24 Jun 2008 16:29:43 -0700 (PDT) Received: by 10.100.172.3 with HTTP; Tue, 24 Jun 2008 16:29:43 -0700 (PDT) Message-ID: <167dfb9b0806241629s57c380feg906f8c0ee3088c60@mail.gmail.com> Date: Wed, 25 Jun 2008 00:29:43 +0100 From: "Theo Zourzouvillys" To: "Dean Willis" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: sip@ietf.org Subject: Re: [Sip] First draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Wed, Jun 25, 2008 at 12:20 AM, Dean Willis wrote: > For example, Alice might delegate her calls to Alice. resulting in a horrible loop. ~ Theo _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:36:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283403A6A24; Tue, 24 Jun 2008 16:36:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674643A6820 for ; Tue, 24 Jun 2008 16:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 eEtjcaYsRTFt for ; Tue, 24 Jun 2008 16:36:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 75F583A6A24 for ; Tue, 24 Jun 2008 16:36:18 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 24 Jun 2008 19:38:07 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 24 Jun 2008 19:35:31 -0400 From: Hadriel Kaplan To: Dan Wing , 'Dean Willis' , "sip@ietf.org" Date: Tue, 24 Jun 2008 19:36:17 -0400 Thread-Topic: [Sip] Let's talk about a Dublin agenda Thread-Index: AcjWLzVVXmf8yzqAT3SGmzN/KRwFSQACpurgAAVAu3AAAErVgA== Message-ID: References: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com> In-Reply-To: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'Keith Drage' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org That's because you posted that on a list no one pays attention to. :) (who even knew there was an rai-discuss@ietf.org separate from rai@ietf.org??) And you proposed overlapping things with SIP and MMUSIC, which does seem tough. I'm thinking more like... Thread-safe: Thread-1 Thread-2 Thread-3 -------- -------- -------- speermint xcon p2psip drinks mediactrl enum speechsc Global: ------- avt bliss mmusic simple sip sipping ecrit geopriv Any Thread WG can conflict with a WG from another Thread. No Global or Thread WG can conflict with a Global WG. You could probably create a Thread-4 with ecrit and geopriv, but 3 concurrent threads seem enough. -hadriel > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > > I was shot down when I proposed it: > http://www.ietf.org/mail-archive/web/rai- > discuss/current/threads.html#00009 > > I do hope we reconsider. > > -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:45:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A89C3A687E; Tue, 24 Jun 2008 16:45:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748FE3A687E for ; Tue, 24 Jun 2008 16:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 x3tttq1xMaaS for ; Tue, 24 Jun 2008 16:45:21 -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 8E87D3A6782 for ; Tue, 24 Jun 2008 16:45:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="44215655" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2008 16:45:22 -0700 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 m5ONjM4f008895; Tue, 24 Jun 2008 16:45:22 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5ONjLXj023368; Tue, 24 Jun 2008 23:45:21 GMT From: "Dan Wing" To: "'Dean Willis'" References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E41D@GBNTHT12009MSX.gb002.siemens.net><0D5F89FAC29E2C41B98A6A762007F5D0D6E42A@GBNTHT12009MSX.gb002.siemens.net> <084a01c8d64d$77f61160$c2f0200a@cisco.com> <0BD298DC-85C1-4A87-8FA5-503BE46F277D@softarmor.com> Date: Tue, 24 Jun 2008 16:45:19 -0700 Message-ID: <090101c8d654$5d084880$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0BD298DC-85C1-4A87-8FA5-503BE46F277D@softarmor.com> Thread-Index: AcjWUUis1OgRXFA6TLCVugwIsekakwAAv5jA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=803; t=1214351122; x=1215215122; c=relaxed/simple; s=sjdkim4002; 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[Sip]=20Let's=20talk=20about=20a=20Dubl in=20agenda |Sender:=20; bh=4g0GZnronoCcfwbMBMpsbY1OH/nkHP+sQavEBJR6pYU=; b=nsbj5sSJkkxRWJLxaZGQPQcJz2frDG1/qJRsLobI9+ix0phZrjaf7b/6hy Oj4ruo/lIpZHQhg88wuEY3/Jluc1sRwthTK+eqZdjdO+4AED5yaUuYAaiu2q 1tzlTArxu8; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, 'Keith Drage' , "'Elwell, John'" Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > >> Well, a new working group starts with a BOF request and a draft > >> charter and somebody who wants the WG badly enough to do the > >> leg work and chair the BOF. > > > > You say that as if nobody tried before. I requested a BoF for > > Philadelphia, called Discussion and Analysis of SIP Identity > > (DASI). It was turned down by the IESG, and did not have the > > support of the RAI ADs. > > True, However, the approach you took at that time wasn't clearly > coordinated as a handoff of responsibility from the SIP > working group. True. > That's what I propose to try now. Ok. > We should also consider that much of the proposed work of RUCUS > (Reducing Unwanted Communications Using SIP), aka anti-SPIT, > depend on strong identity. Yes, it does. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 16:50:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77183A6783; Tue, 24 Jun 2008 16:50:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DA43A6783 for ; Tue, 24 Jun 2008 16:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 QXBhNDZvkwoS for ; Tue, 24 Jun 2008 16:50:23 -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 305143A6782 for ; Tue, 24 Jun 2008 16:50:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,699,1204531200"; d="scan'208";a="59996577" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2008 16:50:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5ONoOQv028439; Tue, 24 Jun 2008 16:50:24 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5ONoOaS026782; Tue, 24 Jun 2008 23:50:24 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Dean Willis'" , References: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com> Date: Tue, 24 Jun 2008 16:50:22 -0700 Message-ID: <090c01c8d655$117ae4d0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjWLzVVXmf8yzqAT3SGmzN/KRwFSQACpurgAAVAu3AAAErVgAABJmRw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=917; t=1214351424; x=1215215424; 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[Sip]=20Let's=20talk=20about=20a=20Dubl in=20agenda |Sender:=20; bh=wyUssYuw/FZIcgt51Gtjeh0qvR3LN07nVtvE2atrzc0=; b=adwcGUlyUocu2+3KvzNesuC5zDUYHQO9ioQUF0DEEgxupDjiA9ByDRIoXd myJkKTxNdLXzkQr3HRXV5bi4b6XEKEuSyH2KHi5mPeAQg2hf+vxTLUn79Z/l qp52uKKuOg0zOn5VP12lDanQ0OIJ6Na8F5gzW1YljnizbG2h+RdDo=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Keith Drage' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > That's because you posted that on a list no one pays attention to. :) > (who even knew there was an rai-discuss@ietf.org separate > from rai@ietf.org??) Neither are used much at all, for whatever that's worth. > And you proposed overlapping things with SIP and MMUSIC, > which does seem tough. > I'm thinking more like... > > Thread-safe: > Thread-1 Thread-2 Thread-3 > -------- -------- -------- > speermint xcon p2psip > drinks mediactrl > enum speechsc > > > Global: > ------- > avt > bliss > mmusic > simple > sip > sipping > ecrit > geopriv > > Any Thread WG can conflict with a WG from another Thread. No > Global or Thread WG can conflict with a Global WG. > You could probably create a Thread-4 with ecrit and geopriv, > but 3 concurrent threads seem enough. Sounds great to me! -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 19:48:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CD73A69F9; Tue, 24 Jun 2008 19:48:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21C53A69F9 for ; Tue, 24 Jun 2008 19:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 XGF9t6qKN497 for ; Tue, 24 Jun 2008 19:48:07 -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 EC6673A69CF for ; Tue, 24 Jun 2008 19:48:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,700,1204531200"; d="scan'208";a="117981553" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2008 19:48:08 -0700 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 m5P2m8sM002038; Tue, 24 Jun 2008 19:48:08 -0700 Received: from [128.107.103.28] ([128.107.103.28]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5P2m8Yd006406; Wed, 25 Jun 2008 02:48:08 GMT Message-Id: <0BA4B436-6A13-42A5-A86B-FEDB63C2C877@cisco.com> From: Cullen Jennings To: Dan Wing In-Reply-To: <090c01c8d655$117ae4d0$c2f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 19:48:58 -0700 References: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com> <090c01c8d655$117ae4d0$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.924) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=564; t=1214362088; x=1215226088; 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[Sip]=20Let's=20talk=20about=20a=20Dubl in=20agenda |Sender:=20; bh=nxm8htKAyrGMUp/0PRoQ7CimTFc1/gGLBE2YIRKhjnY=; b=aN7WgW7Fj4T4+7/BKVTHervFX155tX4y31tac3VwUAnuHWaIEqvSF4iwLC O3SQlA2qp6d9QL8vjz+yiCly26upVbz6QPxfKFos/XlTyK5mamrB6teoU1W7 QdPnFK33I5oZRAI6ngBIGsBo7od6F6CySzRY56dud+Nk52tZDshdM=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Keith Drage' , 'Dean Willis' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 4:50 PM, Dan Wing wrote: >> That's because you posted that on a list no one pays attention to. :) >> (who even knew there was an rai-discuss@ietf.org separate >> from rai@ietf.org??) > > Neither are used much at all, for whatever that's worth. I moved the main part of this thread over to rai@ietf. The rai-discuss list was formed very early before the area was formed and is supposed to be more or less dead. The right list for general rai area topics would be rai@ietf.org but as Dan points out, not much happens on it. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 19:49:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DA228C0E0; Tue, 24 Jun 2008 19:49:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2D028C102 for ; Tue, 24 Jun 2008 19:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 C-0u2EiAYM8J for ; Tue, 24 Jun 2008 19:49:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AD7173A69F9 for ; Tue, 24 Jun 2008 19:49:52 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5P2noZd020765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2008 21:49:52 -0500 Message-Id: <437E7696-025C-4DE1-9C9B-9DC1441BDEF8@softarmor.com> From: Dean Willis To: "Theo Zourzouvillys" In-Reply-To: <167dfb9b0806241629s57c380feg906f8c0ee3088c60@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 21:49:45 -0500 References: <167dfb9b0806241629s57c380feg906f8c0ee3088c60@mail.gmail.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] First draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 24, 2008, at 6:29 PM, Theo Zourzouvillys wrote: > On Wed, Jun 25, 2008 at 12:20 AM, Dean Willis > wrote: > >> For example, Alice might delegate her calls to Alice. > > resulting in a horrible loop. Well, that would be unanticipated! Same name, different person . . . Thanks, Theo. I actually did mean "Alice might delegate her calls to Bob". You win the actually-reading-what-I-wrote prize for the day. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 19:52:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1D628C10F; Tue, 24 Jun 2008 19:52:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0072828C10E; Tue, 24 Jun 2008 19:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, 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 x60CBBeGhoIc; Tue, 24 Jun 2008 19:52:20 -0700 (PDT) Received: from smtp03.bis.na.blackberry.com (smtp03.bis.na.blackberry.com [216.9.248.50]) by core3.amsl.com (Postfix) with ESMTP id CAE6228C0E0; Tue, 24 Jun 2008 19:52:19 -0700 (PDT) Received: from bxe189.bisx.prod.on.blackberry (bxe189.bisx.prod.on.blackberry [172.20.225.222]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m5P2ELMM012698; Wed, 25 Jun 2008 02:52:17 GMT X-rim-org-msg-ref-id: 354302028 Message-ID: <354302028-1214362337-cardhu_decombobulator_blackberry.rim.net-1203746074-@bxe189.bisx.prod.on.blackberry> X-Priority: Normal References: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com><090c01c8d655$117ae4d0$c2f0200a@cisco.com><0BA4B436-6A13-42A5-A86B-FEDB63C2C877@cisco.com> In-Reply-To: <0BA4B436-6A13-42A5-A86B-FEDB63C2C877@cisco.com> Sensitivity: Normal Importance: Normal To: "Cullen Jennings" , sip-bounces@ietf.org, "Dan Wing" From: "=?utf-8?B?RGFuIFlvcms=?=" Date: Wed, 25 Jun 2008 02:53:23 +0000 MIME-Version: 1.0 Cc: sip@ietf.org, 'Keith Drage' , 'Dean Willis' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dyork@voxeo.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen, So is that a polite way of telling us that we should also join the rai@ietf.org list and post responses to today's thread about splitting up the SIP WG *there* versus here? Dan (the other one) -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com -----Original Message----- From: Cullen Jennings Date: Tue, 24 Jun 2008 19:48:58 To:Dan Wing Cc:sip@ietf.org, 'Keith Drage' ,'Dean Willis' Subject: Re: [Sip] Let's talk about a Dublin agenda On Jun 24, 2008, at 4:50 PM, Dan Wing wrote: >> That's because you posted that on a list no one pays attention to. :) >> (who even knew there was an rai-discuss@ietf.org separate >> from rai@ietf.org??) > > Neither are used much at all, for whatever that's worth. I moved the main part of this thread over to rai@ietf. The rai-discuss list was formed very early before the area was formed and is supposed to be more or less dead. The right list for general rai area topics would be rai@ietf.org but as Dan points out, not much happens on it. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 24 19:58:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1A03A6A24; Tue, 24 Jun 2008 19:58:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341D53A6A24; Tue, 24 Jun 2008 19:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 BtCgI1Y505JC; Tue, 24 Jun 2008 19:58:16 -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 1BD8B3A694D; Tue, 24 Jun 2008 19:58:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,700,1204531200"; d="scan'208";a="83092968" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2008 19:58:17 -0700 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 m5P2wH5b009366; Tue, 24 Jun 2008 19:58:17 -0700 Received: from [128.107.103.28] ([128.107.103.28]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5P2wHQc019747; Wed, 25 Jun 2008 02:58:17 GMT From: Cullen Jennings To: dyork@voxeo.com In-Reply-To: <354302028-1214362337-cardhu_decombobulator_blackberry.rim.net-1203746074-@bxe189.bisx.prod.on.blackberry> X-Priority: Normal References: <08a301c8d64e$f55b8cb0$c2f0200a@cisco.com><090c01c8d655$117ae4d0$c2f0200a@cisco.com><0BA4B436-6A13-42A5-A86B-FEDB63C2C877@cisco.com> <354302028-1214362337-cardhu_decombobulator_blackberry.rim.net-1203746074-@bxe189.bisx.prod.on.blackberry> Message-Id: <57839384-07E0-49D0-9087-948009BE6B16@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 19:59:07 -0700 X-Mailer: Apple Mail (2.924) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2104; t=1214362697; x=1215226697; 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[Sip]=20Let's=20talk=20about=20a=20Dubl in=20agenda |Sender:=20; bh=1fYRf98anbxDbXjpM5mSPCC6RtM4N8t5gYiuCwyYJyY=; b=eAy8ZdR/RTY4vhq1qDPfVFhUFNTa4EFj6ixNAnYA3nkPw8b9zWHseyr92A lzVG13TiJA5Oa+5ZIBXLer9G1oWLS2r/by65soPZ3GvK0FyN3DJJVvY72LTF 4Z2tFw1AZbPPb0jx/+xjC5AiCeZcJaDOZwS3YXleAV5XvdIOhD8Mo=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Keith Drage' , sip-bounces@ietf.org, Dan Wing , 'Dean Willis' Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The discution of breaking out part of SIP to a new WG is probably best done on SIP list for now. However, discussion of scheduling all the WG in RAI is probably best done on rai@ietf. Not a real big deal one way or the other. On Jun 24, 2008, at 7:53 PM, Dan York wrote: > Cullen, > > So is that a polite way of telling us that we should also join the rai@ietf.org > list and post responses to today's thread about splitting up the > SIP WG *there* versus here? > > Dan (the other one) > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > -----Original Message----- > From: Cullen Jennings > > Date: Tue, 24 Jun 2008 19:48:58 > To:Dan Wing > Cc:sip@ietf.org, 'Keith Drage' ,'Dean > Willis' > Subject: Re: [Sip] Let's talk about a Dublin agenda > > > > On Jun 24, 2008, at 4:50 PM, Dan Wing wrote: > >>> That's because you posted that on a list no one pays attention >>> to. :) >>> (who even knew there was an rai-discuss@ietf.org separate >>> from rai@ietf.org??) >> >> Neither are used much at all, for whatever that's worth. > > I moved the main part of this thread over to rai@ietf. The rai-discuss > list was formed very early before the area was formed and is supposed > to be more or less dead. The right list for general rai area topics > would be rai@ietf.org but as Dan points out, not much happens on it. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.schmitt@a-n-a.de Wed Jun 25 00:00:56 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3633A6862; Wed, 25 Jun 2008 00:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.71 X-Spam-Level: X-Spam-Status: No, score=-66.71 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 WWAAx89x8t7u; Wed, 25 Jun 2008 00:00:55 -0700 (PDT) Received: from 246-49-89.adsl.terra.cl (246-49-89.adsl.terra.cl [200.89.49.246]) by core3.amsl.com (Postfix) with SMTP id 7ACF13A6994; Wed, 25 Jun 2008 00:00:11 -0700 (PDT) X-Originating-IP: 230.136.4.222 by smtp.200.89.49.246; Wed, 25 Jun 2008 03:00:14 -0500 Message-ID: From: "Quinton Cohen" Reply-To: "Quinton Cohen" To: send-archive@ietf.org Subject: New replica watches delivered fast Date: Wed, 25 Jun 2008 03:00:14 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://www.geocities.com/beasleysixita From sip-bounces@ietf.org Wed Jun 25 00:24:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D663A67F9; Wed, 25 Jun 2008 00:24:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55B43A6893 for ; Wed, 25 Jun 2008 00:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 EkduNf8D6sw9 for ; Wed, 25 Jun 2008 00:24:17 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3C8313A67F9 for ; Wed, 25 Jun 2008 00:24:17 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K300002ZCKI4B@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 08:24:18 +0100 (BST) Date: Wed, 25 Jun 2008 08:24:17 +0100 From: "Elwell, John" In-reply-to: To: Dean Willis , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E47C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] First draft, RETIRE Charter Thread-Index: AcjWUObf+uv8GuTpTJ+Nr7hcbwrhpAAQb8Yg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [Sip] First draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, Thanks for preparing this. I like what I see. This seems to be an ample scope for a WG, and it could probably be addressed during a 1 to 1.5 hour slot at each IETF. A couple of comments below. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: 25 June 2008 00:20 > To: sip@ietf.org > Subject: [Sip] First draft, RETIRE Charter > > This is a first-pass at what I think we might do with a > RETIRE working > group > > --------------- > > > The "REal Time Identity and Role Expression" (RETIRE) > Working Group's > purpose is to standardize the expression and assertion of > identity and > roles needed for real-time communications with the IETF's Realtime > Applications Infrastructure (RAI) area protocols, primarily the > Session Initiation Protocol (SIP) and others used in > conjunction with > SIP. > > By "Identity", we mean authenticated addresses of record (as defined > in RFC 4474 "Enhancements for Authenticated Identity > Management in the > Session Initiation Protocol". RFC 4474 provides a means by > which a SIP > server may vouch for the "From" address of a request transiting that > server. It further provides a cryptographic mechanism for > testing the > source of the assertion. In the typical case, this mechanism is > dependent on the same Public Key Infrastructure that supports secure > HTTP services. Since RFC 4474 provides only authentication of the > source of SIP request messages and it is also important to determine > the identity of the sender of responses, RFC 4916 "Connected > Identity > in the Session Initiation Protocol" provides authenticated > identity in > an ongoing SIP dialog by applying RFC 4474 to requests in the > reverse > direction. While adequate for some scenarios, this mechanism is not > useful for SIP interactions having a single non-dialog transaction, > such as MESSAGE requests. RFC 4474 suffers additional limitations > relating to its use with gateways, session border controllers, and > back-to-back user agents. [JRE] It also suffers an additional limitation to do with E.164 numbers. So I would prefer to say: "RFC 4474 suffers additional limitations relating to its use with E.164 numbers and with gateways, session border controllers, and back-to-back user agents." > > By "Role", we mean aspects of a a system user that are related > identity, but more dynamic in nature. For example, Alice might > delegate her calls to Alice. A calling party, expecting to > reach Alice > but reaching Bob, needs to know that this is a reasonable thing and > what Bob's role in relation to Alice is. This problem is in general > referred to as the "unanticipated respondent problem", and it has > impacts both at the level of user expectations and key management. > Proposals for fixing it have included deprecation of proxy > retargeting > and the use of a new SIP provisional response to inform the calling > party about the retargeting operation. > > Security Assertion Markup Language (SAML) is an XML-based > standard for > exchanging authentication and authorization data between security > domains, that is, between an identity provider (a producer of > assertions) and a service provider (a consumer of > assertions). SAML is > a product of the OASIS Security Services Technical Committee. > The SIP > working group worked for several years on applying SAML to SIP with > mixed results, but the technique appears to have great promise. > > > The initial deliverables of the RETIRE working group are: > > 1) A standards-track revision of RFC 4474 that resolves its > limitations with respect to gateways, session border > controllers, and > back-to-back user agents. This revision will also address the use of > Authenticated Identity Management in conjunction with SIP response > messages. [JRE] One thing we have talked about in the past has been an additional parameter in a SIP URI. I am not saying we definitely need to do this, but I would not want to close the door on this if the group concludes it would be a good thing. Another possible deliverable might a some sort of BCP to do with E.164 numbers in SIP URIs. > > 2) Specify a solution for the Unanticipated Respondent Problem in SIP. > > 3) Guidelines for the use of SAML with SIP for the purposes of > expressing identity and role, specifically in the contexts of #1 and > #2 above. > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 00:33:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F763A6848; Wed, 25 Jun 2008 00:33:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4313A6860 for ; Wed, 25 Jun 2008 00:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 F9Y8Me12oLVu for ; Wed, 25 Jun 2008 00:33:47 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 91D553A6830 for ; Wed, 25 Jun 2008 00:33:47 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K3000M95CTAZD@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 08:33:43 +0100 (BST) Date: Wed, 25 Jun 2008 08:31:56 +0100 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , Dean Willis , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E48D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Let's talk about a Dublin agenda Thread-Index: AcjWLzVVXmf8yzqAT3SGmzN/KRwFSQACpurgABbp6TA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: Keith Drage Subject: Re: [Sip] Let's talk about a Dublin agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Those overlaps would work for me. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 24 June 2008 21:46 > To: Dean Willis; sip@ietf.org > Cc: Keith Drage > Subject: Re: [Sip] Let's talk about a Dublin agenda > > > Oy vey. That's less time than we had in Philly, and we got > barely anything done there. > > Why can't some RAI groups overlap - for example mediactrl or > xcon at the same time as speermint or drinks, or let p2psip > overlap with any of those 4? > > -hadriel > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean > > Willis > > Sent: Tuesday, June 24, 2008 3:20 PM > > To: sip@ietf.org > > Cc: Keith Drage > > Subject: [Sip] Let's talk about a Dublin agenda > > > > > > I've been tipped off that we may be down to as little as > two hours (or > > maybe 2.5) of meeting time in Dublin due to additional WG and BOF > > events that didn't make it onto the earlier published agenda (like > > MEDIACTRL). > > > > What are the absolutely most important things we need to talk about? > > What is the best possible use of our very valuable and very scarce > > time together? > > > > I suspect that going by-rote through the list of open milestones is > > not the best use of our time. > > > > Topics that I think we might want to talk about include but are not > > limited to: > > > > Agenda bash and announcements usually use 10 minutes > > > > 1) Using SAML for SIP. > > -- Milestone was Dec. 2007 > > -- Author has promised new rev before meeting > > -- Is the WG committed to doing this work? > > -- 10 minutes? > > > > 2) Test Matrix for SIP to Draft Standard > > -- Milestone was Feb 2008 > > -- How are we going to move forward? > > -- 10 minutes > > > > 3) Delivery of Request URI and Parameters to UAS Through Proxy > > -- Milestone was Feb 2008 > > -- Conversation has lagged. Do we see a workable solution? > > -- 30 minutes? > > > > 4) DTLS-SRTP > > -- Milestone was Feb 2008 > > -- Delayed by the RFC 4474/Gateway/B2BUA > > -- Decide: Do we hold DTLS-SRTP or publish with a caveat? > > -- EKR may not be attending, can we resolve on-list? (no time?) > > > > 5) Mechanisms for UA Initiated Privacy > > -- Milestone is July 2008 > > -- Author has promised new rev before meeting > > -- 20 minutes? > > > > 6) Termination of early Dialog Prior to Final Response (199) > > -- Milestone is November 2008 > > -- Substantial list activity > > -- 30 minutes? > > > > 7) Guidelines for SIP Extension Modalities > > -- No milestone > > -- Needs conceptual discussion > > -- Defer until #8 below is resolved? (no time?) > > > > 8) The INFO solution and Paul's compromise for historical > registration > > -- No milestone > > -- Previous WG consensus to "do something" > > -- 40 minutes? > > > > > > Am I missing something that is critically important? > > > > Which topics do we really need to talk about in order to > move forward? > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 00:39:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8924B3A6834; Wed, 25 Jun 2008 00:39:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D338A3A6994 for ; Wed, 25 Jun 2008 00:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, 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 C0L4RUDjPXic for ; Wed, 25 Jun 2008 00:39:38 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 9FF1C3A679F for ; Wed, 25 Jun 2008 00:39:37 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Wed, 25 Jun 2008 09:39:37 +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, 25 Jun 2008 09:39:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 09:39:37 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD402CA87C5@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <7237141A-1E4D-4F39-8B76-AC6D9D267505@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft: draft-holmberg-sip-keep-00.txt Thread-Index: AcjWFQKD2DEzkH64RGyONI6xiEHRhAAfrhiw References: <9886E5FCA6D76549A3011068483A4BD402CA8686@S4DE8PSAAQB.mitte.t-com.de> <7237141A-1E4D-4F39-8B76-AC6D9D267505@softarmor.com> From: "Jesske, R" To: X-OriginalArrivalTime: 25 Jun 2008 07:39:37.0398 (UTC) FILETIME=[9E93BD60:01C8D696] Cc: sip@ietf.org Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thank you for your answer. I see there is some ongoing discussion and it is worth to progress the draf= t. I support such an mechanism it is very useful. Thanks and Best Regards Roland = > -----Urspr=FCngliche Nachricht----- > Von: Dean Willis [mailto:dean.willis@softarmor.com] = > Gesendet: Dienstag, 24. Juni 2008 18:12 > An: Jesske, Roland > Cc: sip@ietf.org > Betreff: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt > = > = > On Jun 24, 2008, at 10:07 AM, Jesske, R wrote: > = > > Dear all, > > what is the status of this draft? > = > We are trying to determine whether there is a constituency for the = > draft that justifies further WG effort in advancing it. > = > > Will there be some consideration of this proposal of = > defining a keep = > > parameter? > = > Yes, that's one of the conversations we're having now. > = > > will this possibly incorporated into draft-ietf-sip-outbound? > > > = > No. It's more or less been split off from "outbound". > = > Were I to do this all over again, I would have separated out the = > keepalive function from outbound early on. But we didn't, and = > outbound = > is pretty much done. > = > -- > Dean > = > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 00:52:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CEE3A6830; Wed, 25 Jun 2008 00:52:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456553A6830 for ; Wed, 25 Jun 2008 00:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 uSe4NBytUj2B for ; Wed, 25 Jun 2008 00:52:00 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 0F8FB3A67AB for ; Wed, 25 Jun 2008 00:52:00 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K300010XDUPXS@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 08:52:01 +0100 (BST) Date: Wed, 25 Jun 2008 08:51:59 +0100 From: "Elwell, John" In-reply-to: <076c01c8d643$85c210a0$c2f0200a@cisco.com> To: Dan Wing , "Vijay K. Gurbani" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: 24 June 2008 22:45 > To: 'Vijay K. Gurbani' > Cc: sip@ietf.org > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > Sent: Tuesday, June 24, 2008 2:30 PM > > To: Dan Wing > > Cc: sip@ietf.org > > Subject: Re: [Sip] Toward the Evolution of SIP and Related > > Working Groups > > > > Dan Wing wrote: > > > That wasn't my intent. > > > > Dan: OK; sorry. > > No worries. > > > >> Otherwise, for certificate-based authentication > > >> between proxies, some of what you write above is discussed in > > >> the sip-domain-certs draft. > > > > > > Yes, some of it is there. Can that draft be extended to talk > > > about validating the From of requests (and maybe responses, I'm > > > not sure) that come from over a TLS-authenticated connection? Or > > > would that be out of scope for it? > > > > I believe that validating the From would be out of scope as > > the draft currently stands. The draft does discuss how a > > receiving proxy (i.e., the one that did the passive accept) > > may authenticate the sender (see S7.4, > > http://tools.ietf.org/html/draft-ietf-sip-domain-certs-00#sect > > ion-7.4), > > but this discussion does not normatively involve the From > > header. > > Right. > > > Furthermore, trying to match sender identity as carried in > > From to the TLS-level connection identity as carried in the > > certificate does not work well in the the hop-by-hop model. > > For instance, the sender's From may as well be user@a.com, but > > the last upstream proxy that opened up a connection to the > > recipient could be some intermediary (proxy.com) not in the > > a.com domain, thus making it impossible to enforce that the > > From must match the identity of the last upstream proxy in the > > certificate. > > Agreed. > > > Did you have some alternate or new thoughts on this to see if > > we can hash out something that would still be in the context > > of the domain-certs draft? As it stands, Scott and I are about > > to submit a final post WGLC revision on it by next week. > > I don't think extending domain-cert's scope would be wise -- > rather, I do think this is a separate problem. The separate > problem is that with *some domains* you connect to (and do > domain-certs validation with), you trust them to claim and > use any old "From" they want -- because with those domains > you trust them to have done some validation of their previous > hop, who validated their previous hop, etc. This is how > you would configure a SIP trunk with a service provider, for > example. > > However, if you are communicating directly with another > organization then you would not want to allow them to assert > any identity they wished, because the only identity you expect > them to send you requests with a From that had their own > identity (@microsoft.com, @boeing.com, etc.) -- that is, > the identity of their own employees. You do not expect them > to assert the identity belonging to some other company. You > would not extend the transitive trust to them. [JRE] It depends. I (john@siemens.com) receive a call from dan@cisco.com, and because I am working at home, the siemens.com proxy forwards it to my home via a service provider. The service provider now needs to accept dan@cisco.com (rather than xxx@siemens.com) as the source of the call. At home I would expect to receive dan@cisco.com as caller ID. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 01:06:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7F73A68ED; Wed, 25 Jun 2008 01:06:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9613A68ED for ; Wed, 25 Jun 2008 01:06:11 -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=[BAYES_00=-2.599, HELO_EQ_DE=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 ZSm4r87F2PbG for ; Wed, 25 Jun 2008 01:06:10 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 5C9803A68B8 for ; Wed, 25 Jun 2008 01:06:10 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m5P863D1032363; Wed, 25 Jun 2008 10:06:03 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m5P862Yd019047; Wed, 25 Jun 2008 10:06:02 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 10:06:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 10:05:59 +0200 Message-ID: <198A10EC585EC74687BCA414E2A5971802296B4A@MCHP7RDA.ww002.siemens.net> In-Reply-To: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gatewaydeadlock Thread-Index: AcjWHtwte7dPhd5lT0KGLuVKo++pzQAesldA References: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> From: "Fischer, Kai" To: "Dean Willis" , , "Eric Rescorla" , "Jason Fischl" X-OriginalArrivalTime: 25 Jun 2008 08:06:01.0841 (UTC) FILETIME=[4EFA8E10:01C8D69A] Cc: Cullen Jennings , Keith Drage Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gatewaydeadlock X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If it is the goal to proceed with the DTLS-SRTP framework timely and to reach the milestone, that's the only reasonable approach. However, I hope there will be support to fix RFC 4474 and we can address the backwards compatibility issues. Kai > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Dienstag, 24. Juni 2008 19:22 > To: sip@ietf.org; Eric Rescorla; Jason Fischl > Cc: Cullen Jennings; Keith Drage > Subject: [Sip] A proposal for breaking the DTLS-SRTP vs > RFC4474 gatewaydeadlock > > > We've gotten stuck on a fine point in DTLS-SRTP. > > The current draft-ietf-sip-dtls-srtp-framework-01 uses an RFC 4474 > Identity header to preserve the integrity of the media key's > fingerprint, thereby detecting a certain class of MITM attack. > > However, RFC 4474 Identity headers are of questionable validity when > used with protocol gateways or B2BUAs. More or less, they're > capable > of asserting the identity of the gateway, not the identity of the > calling party. But the recipient has no real way to figure out which > is which. > > We've debated at some length, and with no good result, about whether > we should try and fix RFC 4474. We've had some suggestions that may > work for B2BUAs, and some other suggestions that may work for > gateways, but we certainly don't have a consensus. > > That leaves our chartered deliverable of DTLS-SRTP hanging, and the > milestone has gone past months ago. > > Here's a proposal: > > We add a caveat about the limitation of RFC 4474 to draft-ietf-sip- > dtls-srtp-framework and go ahead and advance that specification. If > somebody later decides to fix RFC 4474, they can do so, and if > necessary update DTLS-SRTP if needed. > > > Does that work for everybody? > > If we agree to it, I suggest that we move the date for WGLC of draft- > ietf-sip-dtls-srtp-framework to July 2008, and move the > milestone for > delivery of that doc to the IESG into September. > > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 01:08:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128EB3A68FA; Wed, 25 Jun 2008 01:08:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDE53A68FA for ; Wed, 25 Jun 2008 01:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 IM-T9aUfFiOF for ; Wed, 25 Jun 2008 01:08:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 46A653A6852 for ; Wed, 25 Jun 2008 01:08:54 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5P88nSa022011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 10:08:49 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5P88kRt009356; Wed, 25 Jun 2008 10:08:48 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 10:08:48 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 10:08:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 11:08:48 +0300 Message-ID: In-Reply-To: <198A10EC585EC74687BCA414E2A5971802296B4A@MCHP7RDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474gatewaydeadlock Thread-Index: AcjWHtwte7dPhd5lT0KGLuVKo++pzQAesldAAAA7gtA= References: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> <198A10EC585EC74687BCA414E2A5971802296B4A@MCHP7RDA.ww002.siemens.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Fischer, Kai" , "Dean Willis" , , "Eric Rescorla" , "Jason Fischl" X-OriginalArrivalTime: 25 Jun 2008 08:08:48.0201 (UTC) FILETIME=[B2231390:01C8D69A] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-15992.005 X-TM-AS-Result: No--23.787100-8.000000-31 Cc: Cullen Jennings , Keith Drage Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474gatewaydeadlock X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, I like your approach. Ciao Hannes >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of ext Fischer, Kai >Sent: 25 June, 2008 11:06 >To: Dean Willis; sip@ietf.org; Eric Rescorla; Jason Fischl >Cc: Cullen Jennings; Keith Drage >Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP vs >RFC4474gatewaydeadlock > >If it is the goal to proceed with the DTLS-SRTP framework >timely and to reach the milestone, that's the only reasonable >approach. However, I hope there will be support to fix RFC >4474 and we can address the backwards compatibility issues. > >Kai > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of >> Dean Willis >> Sent: Dienstag, 24. Juni 2008 19:22 >> To: sip@ietf.org; Eric Rescorla; Jason Fischl >> Cc: Cullen Jennings; Keith Drage >> Subject: [Sip] A proposal for breaking the DTLS-SRTP vs >> RFC4474 gatewaydeadlock >> >> >> We've gotten stuck on a fine point in DTLS-SRTP. >> >> The current draft-ietf-sip-dtls-srtp-framework-01 uses an RFC 4474 >> Identity header to preserve the integrity of the media key's >> fingerprint, thereby detecting a certain class of MITM attack. >> >> However, RFC 4474 Identity headers are of questionable validity when >> used with protocol gateways or B2BUAs. More or less, >they're capable >> of asserting the identity of the gateway, not the identity of the >> calling party. But the recipient has no real way to figure out which >> is which. >> >> We've debated at some length, and with no good result, about whether >> we should try and fix RFC 4474. We've had some suggestions that may >> work for B2BUAs, and some other suggestions that may work for >> gateways, but we certainly don't have a consensus. >> >> That leaves our chartered deliverable of DTLS-SRTP hanging, and the >> milestone has gone past months ago. >> >> Here's a proposal: >> >> We add a caveat about the limitation of RFC 4474 to draft-ietf-sip- >> dtls-srtp-framework and go ahead and advance that specification. If >> somebody later decides to fix RFC 4474, they can do so, and if >> necessary update DTLS-SRTP if needed. >> >> >> Does that work for everybody? >> >> If we agree to it, I suggest that we move the date for WGLC >of draft- >> ietf-sip-dtls-srtp-framework to July 2008, and move the >milestone for >> delivery of that doc to the IESG into September. >> >> -- >> Dean >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 01:34:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EE33A6994; Wed, 25 Jun 2008 01:34:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D953A6994 for ; Wed, 25 Jun 2008 01:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 gpspzyDcf67x for ; Wed, 25 Jun 2008 01:34:44 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 4C9183A687F for ; Wed, 25 Jun 2008 01:34:44 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K300046ZFTXDN@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 09:34:45 +0100 (BST) Date: Wed, 25 Jun 2008 09:34:42 +0100 From: "Elwell, John" In-reply-to: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> To: Dean Willis , sip@ietf.org, Eric Rescorla , Jason Fischl Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E506@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gateway deadlock Thread-Index: AcjWHuNivmQ/+08LTuOZUVjY4a7RmQAerSsA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7C76092F-6FD4-4951-9166-935CC9001ACD@softarmor.com> Cc: Cullen Jennings , Keith Drage Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gateway deadlock X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, Yes, that would work for me, given an intent to push ahead with trying to fix the RFC 4474 issues, e.g., through your proposed RETIRE WG. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: 24 June 2008 18:22 > To: sip@ietf.org; Eric Rescorla; Jason Fischl > Cc: Cullen Jennings; Keith Drage > Subject: [Sip] A proposal for breaking the DTLS-SRTP vs > RFC4474 gateway deadlock > > > We've gotten stuck on a fine point in DTLS-SRTP. > > The current draft-ietf-sip-dtls-srtp-framework-01 uses an RFC 4474 > Identity header to preserve the integrity of the media key's > fingerprint, thereby detecting a certain class of MITM attack. > > However, RFC 4474 Identity headers are of questionable validity when > used with protocol gateways or B2BUAs. More or less, they're > capable > of asserting the identity of the gateway, not the identity of the > calling party. But the recipient has no real way to figure out which > is which. > > We've debated at some length, and with no good result, about whether > we should try and fix RFC 4474. We've had some suggestions that may > work for B2BUAs, and some other suggestions that may work for > gateways, but we certainly don't have a consensus. > > That leaves our chartered deliverable of DTLS-SRTP hanging, and the > milestone has gone past months ago. > > Here's a proposal: > > We add a caveat about the limitation of RFC 4474 to draft-ietf-sip- > dtls-srtp-framework and go ahead and advance that specification. If > somebody later decides to fix RFC 4474, they can do so, and if > necessary update DTLS-SRTP if needed. > > > Does that work for everybody? > > If we agree to it, I suggest that we move the date for WGLC of draft- > ietf-sip-dtls-srtp-framework to July 2008, and move the > milestone for > delivery of that doc to the IESG into September. > > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 02:10:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDBC3A68D5; Wed, 25 Jun 2008 02:10:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A753A696D for ; Wed, 25 Jun 2008 02:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6PfQ7EidzSeN for ; Wed, 25 Jun 2008 02:10:47 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id A2C0C3A6860 for ; Wed, 25 Jun 2008 02:10:46 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Wed, 25 Jun 2008 11:10:42 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 11:10:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 11:10:39 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD402CA88B5@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAAETNKsAAA+WlQAACwqdAADHnwwAAXRQqw References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com><0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net><0D5F89FAC29E2C41B98A6A762007F5D0D6E384@GBNTHT12009MSX.gb002.siemens.net> From: "Jesske, R" To: , , , , X-OriginalArrivalTime: 25 Jun 2008 09:10:42.0305 (UTC) FILETIME=[57EA5F10:01C8D6A3] Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I see this also as useful to have the proxy-proxy behaviour covered. BR Roland = > -----Urspr=FCngliche Nachricht----- > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im = > Auftrag von Christer Holmberg > Gesendet: Mittwoch, 25. Juni 2008 00:05 > An: Hadriel Kaplan; Elwell, John; DRAGE, Keith (Keith); sip@ietf.org > Betreff: Re: [Sip] Progress draft-holmberg-sip-keep > = > = > Hi, > = > As I said before, I would be happy to extend the scope to = > also cover proxy-proxy. I have also received an off-line = > comment indicating that it would be useful. I don't think it = > would change the mechanism itself, so... > = > So, if we choose to move forward with the draft I would then = > update the scope etc it in the next version. > = > Does that sound ok? > = > Regards, > = > Christer = > = > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] = > Sent: 24. kes=E4kuuta 2008 19:11 > To: Elwell, John; DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > = > = > = > Those cases are the ones I said would be useful in my = > original email far below. I.e., when I said "two reasons not = > cited: PBX connections a la SIP trunks, and proxy-proxy = > connections." They are not identical, in the sense that an = > IP-PBX can be a b2bua/UA/whatever, but also in the sense of = > their example use-case, for example an IP-PBX could be behind = > a NAT and thus want this keep-alive for more reasons than a = > proxy-proxy. > = > -hadriel > = > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Tuesday, June 24, 2008 11:48 AM > > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > > Cc: Christer Holmberg > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > Hadriel, > > > > That trunking case is no different from other trunking cases, e.g., = > > proxy-to-proxy, and I have already suggested to Christer = > that he might = > > extend the scope of the draft to cover that. It would be = > good to have = > > some discussion on whether keep-alive on "trunking" = > interfaces would = > > be beneficial - I have an open mind on that at present. > > > > John > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: 24 June 2008 16:32 > > > To: Elwell, John; DRAGE, Keith (Keith); sip@ietf.org > > > Cc: Christer Holmberg > > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > > > Hey John, > > > For the case where the IP-PBX registers into the SP, = > outbound can be = > > > used. But it's the other case I was talking about: > > > where the IP-PBX does NOT register into the SP, but it = > instead is a = > > > trunk. > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Tuesday, June 24, 2008 3:15 AM > > > > To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org > > > > Cc: Christer Holmberg > > > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > Hadriel, > > > > > > > > Concerning your "PBX connections a la SIP trunks" use = > case, I am = > > > > not convinced of this. ETSI TISPAN has specified two ways for > > > an IPPBX to > > > > connect to a service provider. One is the so-called > > > subscription-based > > > > approach, where the IPPBX registers with the SP and > > > communicates via an > > > > edge proxy. In this case, why not use SIP-outbound? The = > other is = > > > > the so-called peering-based approach, which is essentially the > > > same as any > > > > SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, = > proxy-to-gateway. > > > > SIP-outbound does not apply to these situations, and = > similarly the = > > > > keep-alive mechanism is not specified for this cases. The > > > requirements > > > > in SIP-keep do not cover these situations. > > > > > > > > Basically I am not sold on the idea of a separate = > SIP-keep spec - = > > > > I don't think it would be the best use of WG time. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = > > > > > Behalf Of Hadriel Kaplan > > > > > Sent: 20 June 2008 18:20 > > > > > To: DRAGE, Keith (Keith); sip@ietf.org > > > > > Cc: Christer Holmberg > > > > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > > > > > > > > My 2 cents: it is a useful draft. Personally, I = > would like to = > > > > > have it available for two reasons not cited: PBX = > connections a = > > > > > la SIP trunks, and proxy-proxy connections. > > > > > Today I think a lot of people are using OPTIONS requests or = > > > > > proprietary means to perform such keep-alives when = > registration = > > > > > is not appropriate, but it has led to some interop issues and = > > > > > performance concerns in some cases. > > > > > > > > > > Since the contentious issue of what form the keep-alives take = > > > > > have already been agreed on for outbound, this seems like a = > > > > > simple draft to get done. (famous last words, I know) > > > > > > > > > > -hadriel > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > > > Behalf Of > > > > > > DRAGE, Keith (Keith) > > > > > > Sent: Thursday, June 19, 2008 5:31 AM > > > > > > To: sip@ietf.org > > > > > > Cc: Christer Holmberg > > > > > > Subject: [Sip] Progress draft-holmberg-sip-keep > > > > > > > > > > > > (As SIP WG cochair) > > > > > > > > > > > > We have been asked by the author of > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > > > > > > > Whether the SIP WG can progress this document. > > > > > > > > > > > > Because this draft arose as a result of the discussion of > > > > > outbound, and > > > > > > indeed seems to reuse the requirements from outbound, and = > > > > > > these requirements never really got handled in the SIPPING > > > WG, it has been > > > > > > agreed with the SIPPING chairs that we will handle this > > > > > entirely within > > > > > > SIP. > > > > > > > > > > > > Now in order to ask for charter milestones, and indeed when > > > > > we finally > > > > > > present this to IESG, we will be asked for the level of > > > > > support in the > > > > > > WG, which is also predicated on does this fix a real > > > > > problem, or is it > > > > > > just a corner case with limited application. So: > > > > > > > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > > > important to > > > > > > proceed with this draft? The document states: > > > > > > > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 > > > [I-D.ietf-sip-outbound] > > > > > > defines two keep-alive techniques. Even though the > > > keep-alive > > > > > > techniques are separated from the Outbound mechanism > > > > > > [I-D.ietf-sip-outbound], it is currently not > > > possible to indicate > > > > > > support of the keep-alive techniques without also > > > > > indicating support > > > > > > for the Outbound mechanism. > > > > > > > > > > > > The Outbound mechanism is enabled during the UA > > > > > registration phase. > > > > > > However, there are use-cases where the UA does not > > > > > register itself, > > > > > > but still needs to be able to make calls and maintain > > > > > NAT bindings > > > > > > open during the duration of that call. A = > typical example is > > > > > > emergency calls. There are also cases where entities do > > > > > not support > > > > > > the Outbound mechanism, but still want to be able to > > > > > indicate support > > > > > > and use the keep-alive techniques defined in > > > > > [I-D.ietf-sip-outbound]. > > > > > > > > > > > > At first sight this is not the most inspiring declaration > > > > > of the need > > > > > > for the document. Please respond indicating whether you > > > > > consider this a > > > > > > useful draft, and propose text that you think would be > > > > > useful in this > > > > > > section. Conversely, if you think this draft is not useful > > > > > and the WG > > > > > > has other more important things to work on first, please > > > > > also respond. > > > > > > > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of > > > requirements for > > > > > > proceeding with this work? The document currently lists: > > > > > > > > > > > > REQ 1: It MUST be possible for a UA to indicate support > > > > > of the keep- > > > > > > alive techniques defined [I-D.ietf-sip-outbound] if the > > > > > UA supports > > > > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > > > > > > > REQ 2: It MUST be possible for an edge proxy to indicate > > > > > support of > > > > > > the keep-alive techniques defined > > > > > [I-D.ietf-sip-outbound] if the edge > > > > > > poxy supports only the keep-alive part of > > > > > [I-D.ietf-sip-outbound]. > > > > > > > > > > > > It would be desirable to agree these at the outset, and not > > > > > revisit them > > > > > > if we continue with the work. So if you require = > clarification, = > > > > > > modification, or addition to these two requirements, then > > > > > please also > > > > > > response with your questions and proposals. > > > > > > > > > > > > I suggest we would like responses by 30th June 2008 in > > > > > order to allow > > > > > > the author to revise the document before the deadlines. > > > > > Please note that > > > > > > we are looking to make this decision on the list within > > > > > this deadline > > > > > > based on responses received, not leave it until the > > > Dublin meeting. > > > > > > > > > > > > Regards > > > > > > > > > > > > Keith > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP = > Protocol Use = > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip > > > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > _______________________________________________ > > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use = > > > > > sip-implementors@cs.columbia.edu for questions on current sip = > > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 02:36:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB643A68A0; Wed, 25 Jun 2008 02:36:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDBA3A6843 for ; Wed, 25 Jun 2008 02:36:42 -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 4DJx6lsJDZsA for ; Wed, 25 Jun 2008 02:36:41 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 5C1573A65A6 for ; Wed, 25 Jun 2008 02:36:41 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m5P9afEb001534; Wed, 25 Jun 2008 04:36:41 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 04:36:40 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 11:36:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 11:36:35 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYAFE91BQ From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 25 Jun 2008 09:36:38.0366 (UTC) FILETIME=[F7666FE0:01C8D6A6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) While I am seeing some traffic on the list, I am not yet seeing enough clear answers to the two questions asked to progress this to the AD as a charter request. Can I ask people who have already participated in the discussion to repost in regard to the questions asked. Can I ask more people in the group to review and and post their opinions on the two questions. Additionally, one issue that has been raised is proxy to proxy usage. If this draft progresses, is that an additional complexity that should be in or out? Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: Wednesday, June 18, 2008 11:28 PM > To: sip@ietf.org > Cc: 'Christer Holmberg' > Subject: Progress draft-holmberg-sip-keep > > (As SIP WG cochair) > > We have been asked by the author of > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > Whether the SIP WG can progress this document. > > Because this draft arose as a result of the discussion of > outbound, and indeed seems to reuse the requirements from > outbound, and these requirements never really got handled in > the SIPPING WG, it has been agreed with the SIPPING chairs > that we will handle this entirely within SIP. > > Now in order to ask for charter milestones, and indeed when > we finally present this to IESG, we will be asked for the > level of support in the WG, which is also predicated on does > this fix a real problem, or is it just a corner case with > limited application. So: > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > important to proceed with this draft? The document states: > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > defines two keep-alive techniques. Even though the keep-alive > techniques are separated from the Outbound mechanism > [I-D.ietf-sip-outbound], it is currently not possible to indicate > support of the keep-alive techniques without also > indicating support > for the Outbound mechanism. > > The Outbound mechanism is enabled during the UA registration phase. > However, there are use-cases where the UA does not register itself, > but still needs to be able to make calls and maintain NAT bindings > open during the duration of that call. A typical example is > emergency calls. There are also cases where entities do > not support > the Outbound mechanism, but still want to be able to > indicate support > and use the keep-alive techniques defined in > [I-D.ietf-sip-outbound]. > > At first sight this is not the most inspiring declaration of > the need for the document. Please respond indicating whether > you consider this a useful draft, and propose text that you > think would be useful in this section. Conversely, if you > think this draft is not useful and the WG has other more > important things to work on first, please also respond. > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements > for proceeding with this work? The document currently lists: > > REQ 1: It MUST be possible for a UA to indicate support of > the keep- > alive techniques defined [I-D.ietf-sip-outbound] if the UA supports > only the keep-alive part of [I-D.ietf-sip-outbound]. > > REQ 2: It MUST be possible for an edge proxy to indicate support of > the keep-alive techniques defined [I-D.ietf-sip-outbound] > if the edge > poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. > > It would be desirable to agree these at the outset, and not > revisit them if we continue with the work. So if you require > clarification, modification, or addition to these two > requirements, then please also response with your questions > and proposals. > > I suggest we would like responses by 30th June 2008 in order > to allow the author to revise the document before the > deadlines. Please note that we are looking to make this > decision on the list within this deadline based on responses > received, not leave it until the Dublin meeting. > > Regards > > Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 02:49:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C033C3A69FF; Wed, 25 Jun 2008 02:49:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17ED43A6946 for ; Wed, 25 Jun 2008 02:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 5CyMs8jktTiI for ; Wed, 25 Jun 2008 02:49:22 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C2F9E3A69FF for ; Wed, 25 Jun 2008 02:49:21 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K300089AJA1Q2@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 10:49:22 +0100 (BST) Date: Wed, 25 Jun 2008 10:48:40 +0100 From: "Elwell, John" In-reply-to: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith (Keith)" , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E5CF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYAFE91BQAABb6TA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Keith, In reply to question 1, I don't see the use cases as presently documented as being sufficiently important. I would be prepared to reconsider this if the draft were to be extended to cover interfaces other than UA-to-edge-proxy, in particular proxy-to-proxy. I would need to see convincing use cases for this, plus discussion as to whether the same technical solution applies or whether there are differences (e.g., who is responsible for keep-alives in symmetrical situations?). Therefore I can't answer question 2 at present. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: 25 June 2008 10:37 > To: sip@ietf.org > Cc: Christer Holmberg > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > (As SIP WG cochair) > > While I am seeing some traffic on the list, I am not yet seeing enough > clear answers to the two questions asked to progress this to > the AD as a > charter request. > > Can I ask people who have already participated in the discussion to > repost in regard to the questions asked. > > Can I ask more people in the group to review and and post > their opinions > on the two questions. > > Additionally, one issue that has been raised is proxy to > proxy usage. If > this draft progresses, is that an additional complexity that should be > in or out? > > Regards > > Keith > > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: Wednesday, June 18, 2008 11:28 PM > > To: sip@ietf.org > > Cc: 'Christer Holmberg' > > Subject: Progress draft-holmberg-sip-keep > > > > (As SIP WG cochair) > > > > We have been asked by the author of > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > Whether the SIP WG can progress this document. > > > > Because this draft arose as a result of the discussion of > > outbound, and indeed seems to reuse the requirements from > > outbound, and these requirements never really got handled in > > the SIPPING WG, it has been agreed with the SIPPING chairs > > that we will handle this entirely within SIP. > > > > Now in order to ask for charter milestones, and indeed when > > we finally present this to IESG, we will be asked for the > > level of support in the WG, which is also predicated on does > > this fix a real problem, or is it just a corner case with > > limited application. So: > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > > important to proceed with this draft? The document states: > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > > defines two keep-alive techniques. Even though the keep-alive > > techniques are separated from the Outbound mechanism > > [I-D.ietf-sip-outbound], it is currently not possible to indicate > > support of the keep-alive techniques without also > > indicating support > > for the Outbound mechanism. > > > > The Outbound mechanism is enabled during the UA > registration phase. > > However, there are use-cases where the UA does not > register itself, > > but still needs to be able to make calls and maintain > NAT bindings > > open during the duration of that call. A typical example is > > emergency calls. There are also cases where entities do > > not support > > the Outbound mechanism, but still want to be able to > > indicate support > > and use the keep-alive techniques defined in > > [I-D.ietf-sip-outbound]. > > > > At first sight this is not the most inspiring declaration of > > the need for the document. Please respond indicating whether > > you consider this a useful draft, and propose text that you > > think would be useful in this section. Conversely, if you > > think this draft is not useful and the WG has other more > > important things to work on first, please also respond. > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements > > for proceeding with this work? The document currently lists: > > > > REQ 1: It MUST be possible for a UA to indicate support of > > the keep- > > alive techniques defined [I-D.ietf-sip-outbound] if the > UA supports > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > REQ 2: It MUST be possible for an edge proxy to indicate > support of > > the keep-alive techniques defined [I-D.ietf-sip-outbound] > > if the edge > > poxy supports only the keep-alive part of > [I-D.ietf-sip-outbound]. > > > > It would be desirable to agree these at the outset, and not > > revisit them if we continue with the work. So if you require > > clarification, modification, or addition to these two > > requirements, then please also response with your questions > > and proposals. > > > > I suggest we would like responses by 30th June 2008 in order > > to allow the author to revise the document before the > > deadlines. Please note that we are looking to make this > > decision on the list within this deadline based on responses > > received, not leave it until the Dublin meeting. > > > > Regards > > > > Keith > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 05:04:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970B128C15A; Wed, 25 Jun 2008 05:04:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9C928C159 for ; Wed, 25 Jun 2008 05:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.539 X-Spam-Level: X-Spam-Status: No, score=-4.539 tagged_above=-999 required=5 tests=[AWL=2.060, 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 Xh6x-7QNBwZk for ; Wed, 25 Jun 2008 05:04:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 56C6A28C156 for ; Wed, 25 Jun 2008 05:04:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,702,1204531200"; d="scan'208";a="34123216" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 25 Jun 2008 05:04:30 -0700 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 m5PC4UKY014687; Wed, 25 Jun 2008 05:04:30 -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.13.8) with ESMTP id m5PC4UUv021477; Wed, 25 Jun 2008 12:04:30 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.1830); Wed, 25 Jun 2008 08:04:29 -0400 Received: from [10.86.248.184] ([10.86.248.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 08:04:29 -0400 Message-ID: <4862347B.8080405@cisco.com> Date: Wed, 25 Jun 2008 08:05:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Elwell, John" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 25 Jun 2008 12:04:29.0578 (UTC) FILETIME=[9F0DF6A0:01C8D6BB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1353; t=1214395470; x=1215259470; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=xaWSyyHU4l268yiEde3L6CDLT6bEZlFvv6hYiuCBAXU=; b=JEA8yJJjZ5ASPdXVF2qVeKqsVO/MK08eTufjZkju6L97BQTSaHlLJzSjss Wno8HVT3gTecWWAr6XA/CUeC5pZOJZxe4VIEfjBITLUpoXHgn9mg2prdaiEm woR2sKenBd; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: >> However, if you are communicating directly with another >> organization then you would not want to allow them to assert >> any identity they wished, because the only identity you expect >> them to send you requests with a From that had their own >> identity (@microsoft.com, @boeing.com, etc.) -- that is, >> the identity of their own employees. You do not expect them >> to assert the identity belonging to some other company. You >> would not extend the transitive trust to them. > [JRE] It depends. I (john@siemens.com) receive a call from > dan@cisco.com, and because I am working at home, the siemens.com proxy > forwards it to my home via a service provider. The service provider now > needs to accept dan@cisco.com (rather than xxx@siemens.com) as the > source of the call. At home I would expect to receive dan@cisco.com as > caller ID. John, I know that is what you would like to see on your phone. But that doesn't mean there is a plausible way for it to happen. We are discussing transitive trust here. Why would the SP trust siemens.com when it asserts a cisco.com domain? If that turns out to be incorrect, and you complain, you could justifiably complain that the SP lied to you. They put themself at risk by trusting such an assertion from siemens. Thanks, Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 05:40:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6158D3A6A86; Wed, 25 Jun 2008 05:40:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214E33A69D1 for ; Wed, 25 Jun 2008 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 mvCvRvmhPC8M for ; Wed, 25 Jun 2008 05:40:00 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 189103A6A86 for ; Wed, 25 Jun 2008 05:40:00 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K3000J71R6L7A@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 13:39:57 +0100 (BST) Date: Wed, 25 Jun 2008 13:39:52 +0100 From: "Elwell, John" In-reply-to: <4862347B.8080405@cisco.com> To: Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWu7bItHEZm/qzRxKdJneZdiknCQAA9CEw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 25 June 2008 13:05 > To: Elwell, John > Cc: Dan Wing; Vijay K. Gurbani; sip@ietf.org > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > > Elwell, John wrote: > > >> However, if you are communicating directly with another > >> organization then you would not want to allow them to assert > >> any identity they wished, because the only identity you expect > >> them to send you requests with a From that had their own > >> identity (@microsoft.com, @boeing.com, etc.) -- that is, > >> the identity of their own employees. You do not expect them > >> to assert the identity belonging to some other company. You > >> would not extend the transitive trust to them. > > [JRE] It depends. I (john@siemens.com) receive a call from > > dan@cisco.com, and because I am working at home, the > siemens.com proxy > > forwards it to my home via a service provider. The service > provider now > > needs to accept dan@cisco.com (rather than xxx@siemens.com) as the > > source of the call. At home I would expect to receive > dan@cisco.com as > > caller ID. > > John, > > I know that is what you would like to see on your phone. > But that doesn't mean there is a plausible way for it to happen. > > We are discussing transitive trust here. Why would the SP trust > siemens.com when it asserts a cisco.com domain? If that turns > out to be > incorrect, and you complain, you could justifiably complain > that the SP > lied to you. They put themself at risk by trusting such an assertion > from siemens. [JRE] I am not expecting the service provider to trust siemens.com, because siemens.com is not making the assertion. The assertion from cisco.com is merely being passed on by siemens.com to the service provider. It will be the cisco.com certificate, not the siemens.com certificate. Of course, siemens.com also has to make an assertion, it has to assert that it is siemens.com that is passing this request to the service provider, and this can be done using TLS authentication. But that says nothing about the original source of request or the caller ID. We must not get the two layers mixed up - transport layer authentication is for a single hop and SIP layer authentication is end-to-end (or end-domain-to-end-domain). John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 06:00:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49A728C0F1; Wed, 25 Jun 2008 06:00:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5243A6851 for ; Wed, 25 Jun 2008 06:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.456 X-Spam-Level: X-Spam-Status: No, score=-5.456 tagged_above=-999 required=5 tests=[AWL=1.143, 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 3E88AhWWNFbR for ; Wed, 25 Jun 2008 06:00:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 132F628C0F1 for ; Wed, 25 Jun 2008 06:00:42 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5PD0LOo008226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 15:00:21 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5PD0LCn005143; Wed, 25 Jun 2008 15:00:21 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 15:00:21 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 15:00:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 16:00:09 +0300 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWu7bItHEZm/qzRxKdJneZdiknCQAA9CEwAABwkGA= References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com><5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com><08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net><05d001c8d628$98c91510$c2f0200a@cisco.com><48614E77.9010904@alcatel-lucent.com><071b01c8d63f$2e39e910$c2f0200a@cisco.com><4861675E.1010507@alcatel-lucent.com><076c01c8d643$85c210a0$c2f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net><4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 25 Jun 2008 13:00:20.0132 (UTC) FILETIME=[6C23EE40:01C8D6C3] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-15992.007 X-TM-AS-Result: No--21.126100-8.000000-31 Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Consider the following scenario: +-----------+ +-----------+ |SIP | |SIP | +------>|Proxy |<---------->|Proxy |<------+ | |Server X | TLS |Server Y | | | +-----------+ +-----------+ | | | | TLS or TLS or | | SIP Digest SIP Digest | | | | | v v +-----------+ +-----------+ |SIP | |SIP | |User Agent | RTP |User Agent | |Alice | <=================================> |Bob | +-----------+ +-----------+ When there are no further proxies between X and Y then Y has the information that Alice was authenticated by X. Proxy Y would pass that info on to Bob. Bob trusts Y. Obviously, the two VoIP providers may have a far more complicated infrastructure with multiple proxies but they all belong to the same domain and could be seen from external as just one box. The same would not work when there are more proxies between X and Y. However, these guys that prefer such a deployment belong more to the chain of trust camp rather than the end-to-end / email alike peering camp. It is rather unlikely that you get their support for getting SIP Identity to work in their networks. So, do we have an indication that some folks plan to use SIP Identity for their deployment? Wouldn't it be better to rely on something like SIP CERT for a better end-to-end security mechanism (ignoring for a moment that SIP CERT also uses SIP Identity for "simplified deployment" reasons whereby one has to state that the usage of SIP Identity for SUBSCRIBE/NOTIFY might have different B2BUA aspects). Ciao Hannes >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of ext Elwell, John >Sent: 25 June, 2008 15:40 >To: Paul Kyzivat >Cc: sip@ietf.org; Dan Wing >Subject: Re: [Sip] Toward the Evolution of SIP and Related >Working Groups > >Paul, > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 25 June 2008 13:05 >> To: Elwell, John >> Cc: Dan Wing; Vijay K. Gurbani; sip@ietf.org >> Subject: Re: [Sip] Toward the Evolution of SIP and Related Working >> Groups >> >> >> >> Elwell, John wrote: >> >> >> However, if you are communicating directly with another >> >> organization then you would not want to allow them to assert any >> >> identity they wished, because the only identity you >expect them to >> >> send you requests with a From that had their own identity >> >> (@microsoft.com, @boeing.com, etc.) -- that is, the identity of >> >> their own employees. You do not expect them to assert >the identity >> >> belonging to some other company. You would not extend the >> >> transitive trust to them. >> > [JRE] It depends. I (john@siemens.com) receive a call from >> > dan@cisco.com, and because I am working at home, the >> siemens.com proxy >> > forwards it to my home via a service provider. The service >> provider now >> > needs to accept dan@cisco.com (rather than xxx@siemens.com) as the >> > source of the call. At home I would expect to receive >> dan@cisco.com as >> > caller ID. >> >> John, >> >> I know that is what you would like to see on your phone. >> But that doesn't mean there is a plausible way for it to happen. >> >> We are discussing transitive trust here. Why would the SP trust >> siemens.com when it asserts a cisco.com domain? If that turns out to >> be incorrect, and you complain, you could justifiably complain that >> the SP lied to you. They put themself at risk by trusting such an >> assertion from siemens. >[JRE] I am not expecting the service provider to trust >siemens.com, because siemens.com is not making the assertion. >The assertion from cisco.com is merely being passed on by >siemens.com to the service provider. It will be the cisco.com >certificate, not the siemens.com certificate. > >Of course, siemens.com also has to make an assertion, it has >to assert that it is siemens.com that is passing this request >to the service provider, and this can be done using TLS >authentication. But that says nothing about the original >source of request or the caller ID. We must not get the two >layers mixed up - transport layer authentication is for a >single hop and SIP layer authentication is end-to-end (or >end-domain-to-end-domain). > >John >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 06:03:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96ED3A6A76; Wed, 25 Jun 2008 06:03:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469CB3A6A89 for ; Wed, 25 Jun 2008 06:03:41 -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=[BAYES_00=-2.599, HELO_EQ_DE=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 E39ytulmldSq for ; Wed, 25 Jun 2008 06:03:40 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 12F913A6A76 for ; Wed, 25 Jun 2008 06:03:39 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m5PD3bDe022395; Wed, 25 Jun 2008 15:03:40 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m5PD3bts030942; Wed, 25 Jun 2008 15:03:37 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 15:03:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 15:03:36 +0200 Message-ID: <198A10EC585EC74687BCA414E2A5971802296C36@MCHP7RDA.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] First draft, RETIRE Charter Thread-Index: AcjWUOcGrpR0MsN0QY6jvekjWVnxqAAcNGhA References: From: "Fischer, Kai" To: "Dean Willis" , X-OriginalArrivalTime: 25 Jun 2008 13:03:36.0752 (UTC) FILETIME=[E155C300:01C8D6C3] Subject: Re: [Sip] First draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Dean, this looks good for me - see one comment below. Kai > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Mittwoch, 25. Juni 2008 01:20 > To: sip@ietf.org > Subject: [Sip] First draft, RETIRE Charter > > This is a first-pass at what I think we might do with a > RETIRE working > group > > --------------- > > > The "REal Time Identity and Role Expression" (RETIRE) > Working Group's > purpose is to standardize the expression and assertion of > identity and > roles needed for real-time communications with the IETF's Realtime > Applications Infrastructure (RAI) area protocols, primarily the > Session Initiation Protocol (SIP) and others used in > conjunction with > SIP. > > By "Identity", we mean authenticated addresses of record (as defined > in RFC 4474 "Enhancements for Authenticated Identity > Management in the > Session Initiation Protocol". RFC 4474 provides a means by > which a SIP > server may vouch for the "From" address of a request transiting that > server. It further provides a cryptographic mechanism for > testing the > source of the assertion. In the typical case, this mechanism is > dependent on the same Public Key Infrastructure that supports secure > HTTP services. Since RFC 4474 provides only authentication of the > source of SIP request messages and it is also important to determine > the identity of the sender of responses, RFC 4916 "Connected > Identity > in the Session Initiation Protocol" provides authenticated > identity in > an ongoing SIP dialog by applying RFC 4474 to requests in the > reverse > direction. While adequate for some scenarios, this mechanism is not > useful for SIP interactions having a single non-dialog transaction, > such as MESSAGE requests. RFC 4474 suffers additional limitations > relating to its use with gateways, session border controllers, and > back-to-back user agents. The whole discussion of the limitations with RFC 4474 came up in the context of DTLS-SRTP and end-to-end security and the limited binding of the identity and certificate fingerprint. From my point of view, this should be added explicitly here. > > By "Role", we mean aspects of a a system user that are related > identity, but more dynamic in nature. For example, Alice might > delegate her calls to Alice. A calling party, expecting to > reach Alice > but reaching Bob, needs to know that this is a reasonable thing and > what Bob's role in relation to Alice is. This problem is in general > referred to as the "unanticipated respondent problem", and it has > impacts both at the level of user expectations and key management. > Proposals for fixing it have included deprecation of proxy > retargeting > and the use of a new SIP provisional response to inform the calling > party about the retargeting operation. > > Security Assertion Markup Language (SAML) is an XML-based > standard for > exchanging authentication and authorization data between security > domains, that is, between an identity provider (a producer of > assertions) and a service provider (a consumer of > assertions). SAML is > a product of the OASIS Security Services Technical Committee. > The SIP > working group worked for several years on applying SAML to SIP with > mixed results, but the technique appears to have great promise. > > > The initial deliverables of the RETIRE working group are: > > 1) A standards-track revision of RFC 4474 that resolves its > limitations with respect to gateways, session border > controllers, and > back-to-back user agents. This revision will also address the use of > Authenticated Identity Management in conjunction with SIP response > messages. > > 2) Specify a solution for the Unanticipated Respondent Problem in SIP. > > 3) Guidelines for the use of SAML with SIP for the purposes of > expressing identity and role, specifically in the contexts of #1 and > #2 above. > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 07:21:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B17E3A687F; Wed, 25 Jun 2008 07:21:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D0F3A687F for ; Wed, 25 Jun 2008 07:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 MDE9OODuNwVD for ; Wed, 25 Jun 2008 07:21:22 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.245.115]) by core3.amsl.com (Postfix) with ESMTP id E2F973A6851 for ; Wed, 25 Jun 2008 07:21:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1214403682!17738147!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 30653 invoked from network); 25 Jun 2008 14:21:23 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 25 Jun 2008 14:21:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5PELMeY004492 for ; Wed, 25 Jun 2008 10:21:22 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5PELCPM004313 for ; Wed, 25 Jun 2008 10:21:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 10:21:11 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA56E0C3@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYAFE91BQAAnvD8A= References: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> From: "DOLLY, MARTIN C, ATTLABS" To: "DRAGE, Keith (Keith)" , Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Keith, We would find this very useful. Being the mechanism can be used between any two SIP entities, I agree with John to expand the scope to reflect that. We support proxy to proxy being in, as it is needed for the network deployments. Martin -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Wednesday, June 25, 2008 5:37 AM To: sip@ietf.org Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep (As SIP WG cochair) While I am seeing some traffic on the list, I am not yet seeing enough clear answers to the two questions asked to progress this to the AD as a charter request. Can I ask people who have already participated in the discussion to repost in regard to the questions asked. Can I ask more people in the group to review and and post their opinions on the two questions. Additionally, one issue that has been raised is proxy to proxy usage. If this draft progresses, is that an additional complexity that should be in or out? Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: Wednesday, June 18, 2008 11:28 PM > To: sip@ietf.org > Cc: 'Christer Holmberg' > Subject: Progress draft-holmberg-sip-keep > > (As SIP WG cochair) > > We have been asked by the author of > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > Whether the SIP WG can progress this document. > > Because this draft arose as a result of the discussion of > outbound, and indeed seems to reuse the requirements from > outbound, and these requirements never really got handled in > the SIPPING WG, it has been agreed with the SIPPING chairs > that we will handle this entirely within SIP. > > Now in order to ask for charter milestones, and indeed when > we finally present this to IESG, we will be asked for the > level of support in the WG, which is also predicated on does > this fix a real problem, or is it just a corner case with > limited application. So: > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > important to proceed with this draft? The document states: > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > defines two keep-alive techniques. Even though the keep-alive > techniques are separated from the Outbound mechanism > [I-D.ietf-sip-outbound], it is currently not possible to indicate > support of the keep-alive techniques without also > indicating support > for the Outbound mechanism. > > The Outbound mechanism is enabled during the UA registration phase. > However, there are use-cases where the UA does not register itself, > but still needs to be able to make calls and maintain NAT bindings > open during the duration of that call. A typical example is > emergency calls. There are also cases where entities do > not support > the Outbound mechanism, but still want to be able to > indicate support > and use the keep-alive techniques defined in > [I-D.ietf-sip-outbound]. > > At first sight this is not the most inspiring declaration of > the need for the document. Please respond indicating whether > you consider this a useful draft, and propose text that you > think would be useful in this section. Conversely, if you > think this draft is not useful and the WG has other more > important things to work on first, please also respond. > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements > for proceeding with this work? The document currently lists: > > REQ 1: It MUST be possible for a UA to indicate support of > the keep- > alive techniques defined [I-D.ietf-sip-outbound] if the UA supports > only the keep-alive part of [I-D.ietf-sip-outbound]. > > REQ 2: It MUST be possible for an edge proxy to indicate support of > the keep-alive techniques defined [I-D.ietf-sip-outbound] > if the edge > poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. > > It would be desirable to agree these at the outset, and not > revisit them if we continue with the work. So if you require > clarification, modification, or addition to these two > requirements, then please also response with your questions > and proposals. > > I suggest we would like responses by 30th June 2008 in order > to allow the author to revise the document before the > deadlines. Please note that we are looking to make this > decision on the list within this deadline based on responses > received, not leave it until the Dublin meeting. > > Regards > > Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 07:43:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C193A68D5; Wed, 25 Jun 2008 07:43:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFE23A68CC for ; Wed, 25 Jun 2008 07:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 SnvyBN5RjDy2 for ; Wed, 25 Jun 2008 07:43:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6DF433A67E3 for ; Wed, 25 Jun 2008 07:43:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 25 Jun 2008 10:45:33 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 25 Jun 2008 10:42:57 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "sip@ietf.org" Date: Wed, 25 Jun 2008 10:43:41 -0400 Thread-Topic: Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYAFE91BQAAq7zZA= Message-ID: References: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Q1: yes, with some minor edits to the draft to include the proxy-proxy type thing, it's clearly valuable work. Q2: yes, I think those are the set of requirements - though I don't know why we can' expand them in the future if we decide a couple more are required. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: Wednesday, June 25, 2008 5:37 AM > To: sip@ietf.org > Cc: Christer Holmberg > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > (As SIP WG cochair) > > While I am seeing some traffic on the list, I am not yet seeing enough > clear answers to the two questions asked to progress this to the AD as a > charter request. > > Can I ask people who have already participated in the discussion to > repost in regard to the questions asked. > > Can I ask more people in the group to review and and post their opinions > on the two questions. > > Additionally, one issue that has been raised is proxy to proxy usage. If > this draft progresses, is that an additional complexity that should be > in or out? > > Regards > > Keith > > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: Wednesday, June 18, 2008 11:28 PM > > To: sip@ietf.org > > Cc: 'Christer Holmberg' > > Subject: Progress draft-holmberg-sip-keep > > > > (As SIP WG cochair) > > > > We have been asked by the author of > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > Whether the SIP WG can progress this document. > > > > Because this draft arose as a result of the discussion of > > outbound, and indeed seems to reuse the requirements from > > outbound, and these requirements never really got handled in > > the SIPPING WG, it has been agreed with the SIPPING chairs > > that we will handle this entirely within SIP. > > > > Now in order to ask for charter milestones, and indeed when > > we finally present this to IESG, we will be asked for the > > level of support in the WG, which is also predicated on does > > this fix a real problem, or is it just a corner case with > > limited application. So: > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > > important to proceed with this draft? The document states: > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > > defines two keep-alive techniques. Even though the keep-alive > > techniques are separated from the Outbound mechanism > > [I-D.ietf-sip-outbound], it is currently not possible to indicate > > support of the keep-alive techniques without also > > indicating support > > for the Outbound mechanism. > > > > The Outbound mechanism is enabled during the UA registration phase. > > However, there are use-cases where the UA does not register itself, > > but still needs to be able to make calls and maintain NAT bindings > > open during the duration of that call. A typical example is > > emergency calls. There are also cases where entities do > > not support > > the Outbound mechanism, but still want to be able to > > indicate support > > and use the keep-alive techniques defined in > > [I-D.ietf-sip-outbound]. > > > > At first sight this is not the most inspiring declaration of > > the need for the document. Please respond indicating whether > > you consider this a useful draft, and propose text that you > > think would be useful in this section. Conversely, if you > > think this draft is not useful and the WG has other more > > important things to work on first, please also respond. > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements > > for proceeding with this work? The document currently lists: > > > > REQ 1: It MUST be possible for a UA to indicate support of > > the keep- > > alive techniques defined [I-D.ietf-sip-outbound] if the UA supports > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > REQ 2: It MUST be possible for an edge proxy to indicate support of > > the keep-alive techniques defined [I-D.ietf-sip-outbound] > > if the edge > > poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > It would be desirable to agree these at the outset, and not > > revisit them if we continue with the work. So if you require > > clarification, modification, or addition to these two > > requirements, then please also response with your questions > > and proposals. > > > > I suggest we would like responses by 30th June 2008 in order > > to allow the author to revise the document before the > > deadlines. Please note that we are looking to make this > > decision on the list within this deadline based on responses > > received, not leave it until the Dublin meeting. > > > > Regards > > > > Keith > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 07:51:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86F23A6978; Wed, 25 Jun 2008 07:51:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C595A3A686E for ; Wed, 25 Jun 2008 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.300, 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 xjKFH8+6SRUL for ; Wed, 25 Jun 2008 07:51:31 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 2BF5D3A6A48 for ; Wed, 25 Jun 2008 07:51:21 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Wed, 25 Jun 2008 16:51:20 +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, 25 Jun 2008 16:51:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 16:50:57 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD402CA8B60@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYAFE91BQAAq7zZAAADMdYA== References: <5D1A7985295922448D5550C94DE291800209B9E0@DEEXC1U01.de.lucent.com> From: "Jesske, R" To: , , X-OriginalArrivalTime: 25 Jun 2008 14:51:00.0160 (UTC) FILETIME=[E1E7CC00:01C8D6D2] Cc: christer.holmberg@ericsson.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ok Even with the questions from Keith I didn't changed my mind and support aga= in. = For me are the requirements sufficient enough and could be if really needed= also extended later. And we support the proxy-proxy case. Some more support needed from my side? BR Roland > -----Urspr=FCngliche Nachricht----- > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im = > Auftrag von Hadriel Kaplan > Gesendet: Mittwoch, 25. Juni 2008 16:44 > An: DRAGE, Keith (Keith); sip@ietf.org > Cc: Christer Holmberg > Betreff: Re: [Sip] Progress draft-holmberg-sip-keep > = > = > Q1: yes, with some minor edits to the draft to include the = > proxy-proxy type thing, it's clearly valuable work. > = > Q2: yes, I think those are the set of requirements - though I = > don't know why we can' expand them in the future if we decide = > a couple more are required. > = > -hadriel > = > = > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = > Behalf Of > > DRAGE, Keith (Keith) > > Sent: Wednesday, June 25, 2008 5:37 AM > > To: sip@ietf.org > > Cc: Christer Holmberg > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > > (As SIP WG cochair) > > > > While I am seeing some traffic on the list, I am not yet = > seeing enough > > clear answers to the two questions asked to progress this = > to the AD as a > > charter request. > > > > Can I ask people who have already participated in the discussion to > > repost in regard to the questions asked. > > > > Can I ask more people in the group to review and and post = > their opinions > > on the two questions. > > > > Additionally, one issue that has been raised is proxy to = > proxy usage. If > > this draft progresses, is that an additional complexity = > that should be > > in or out? > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) > > > Sent: Wednesday, June 18, 2008 11:28 PM > > > To: sip@ietf.org > > > Cc: 'Christer Holmberg' > > > Subject: Progress draft-holmberg-sip-keep > > > > > > (As SIP WG cochair) > > > > > > We have been asked by the author of > > > > > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > > > > > Whether the SIP WG can progress this document. > > > > > > Because this draft arose as a result of the discussion of > > > outbound, and indeed seems to reuse the requirements from > > > outbound, and these requirements never really got handled in > > > the SIPPING WG, it has been agreed with the SIPPING chairs > > > that we will handle this entirely within SIP. > > > > > > Now in order to ask for charter milestones, and indeed when > > > we finally present this to IESG, we will be asked for the > > > level of support in the WG, which is also predicated on does > > > this fix a real problem, or is it just a corner case with > > > limited application. So: > > > > > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > > > important to proceed with this draft? The document states: > > > > > > Chapter 3.5 of draft-ietf-sip-outbound-13 = > [I-D.ietf-sip-outbound] > > > defines two keep-alive techniques. Even though the keep-alive > > > techniques are separated from the Outbound mechanism > > > [I-D.ietf-sip-outbound], it is currently not possible = > to indicate > > > support of the keep-alive techniques without also > > > indicating support > > > for the Outbound mechanism. > > > > > > The Outbound mechanism is enabled during the UA = > registration phase. > > > However, there are use-cases where the UA does not = > register itself, > > > but still needs to be able to make calls and maintain = > NAT bindings > > > open during the duration of that call. A typical example is > > > emergency calls. There are also cases where entities do > > > not support > > > the Outbound mechanism, but still want to be able to > > > indicate support > > > and use the keep-alive techniques defined in > > > [I-D.ietf-sip-outbound]. > > > > > > At first sight this is not the most inspiring declaration of > > > the need for the document. Please respond indicating whether > > > you consider this a useful draft, and propose text that you > > > think would be useful in this section. Conversely, if you > > > think this draft is not useful and the WG has other more > > > important things to work on first, please also respond. > > > > > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements > > > for proceeding with this work? The document currently lists: > > > > > > REQ 1: It MUST be possible for a UA to indicate support of > > > the keep- > > > alive techniques defined [I-D.ietf-sip-outbound] if = > the UA supports > > > only the keep-alive part of [I-D.ietf-sip-outbound]. > > > > > > REQ 2: It MUST be possible for an edge proxy to = > indicate support of > > > the keep-alive techniques defined [I-D.ietf-sip-outbound] > > > if the edge > > > poxy supports only the keep-alive part of = > [I-D.ietf-sip-outbound]. > > > > > > It would be desirable to agree these at the outset, and not > > > revisit them if we continue with the work. So if you require > > > clarification, modification, or addition to these two > > > requirements, then please also response with your questions > > > and proposals. > > > > > > I suggest we would like responses by 30th June 2008 in order > > > to allow the author to revise the document before the > > > deadlines. Please note that we are looking to make this > > > decision on the list within this deadline based on responses > > > received, not leave it until the Dublin meeting. > > > > > > Regards > > > > > > Keith > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 08:39:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF20628C104; Wed, 25 Jun 2008 08:39:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9123F28C0F5 for ; Wed, 25 Jun 2008 08:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 kCfz2tKw2mq3 for ; Wed, 25 Jun 2008 08:39:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 62DFE28C104 for ; Wed, 25 Jun 2008 08:39:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C30CF2064C; Wed, 25 Jun 2008 17:39:06 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-29-4862669a8aeb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A9BE2205C5; Wed, 25 Jun 2008 17:39:06 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 17:39:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 17:39:34 +0200 Message-ID: In-Reply-To: <4861347C.8020100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjWIxt9fMrJV+vKSPGXLzdJLoAhSwAtkGcQ References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com> <4860E783.3070008@cisco.com> <4860EC06.6080104@cisco.com> <4861347C.8020100@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 25 Jun 2008 15:39:34.0845 (UTC) FILETIME=[AB316ED0:01C8D6D9] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >>>>One option, as proposed by Paul, is to say that a UAC shall be able to RECEIVE reliable 199 responses. >>>Based on my comments above, I am reconsidering the advisability of that. >> >>Well, I guess it wouldn't affect the complexness in the UAC, since it will have to be able to handle reliable >>provisional responses anyway (if it indicates support of it, that is). > >Yes, I think it does increase the complexity in the implementation of 199 handling. > >You are right that the PRACK itself would be handled by the standard machinery for reliable provisionals. But then >tearing down the dialog, which is what the 199 is supposed to trigger, can't be done upon receipt of a reliable 199. >Rather it must wait until the after the PRACK is at least send, and perhaps until the 200 for the prack is received. And >this is different than for the unreliable 199. This isn't rocket science, but it is more complexity. And of course it >requires something that sends reliable 199s in order to test the UAC. It is true that the PRACK transaction must be "alive" until the 200 OK is received, but I assume all other "resources" can be released once the 199 is received. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 08:47:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D7128C104; Wed, 25 Jun 2008 08:47:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1383A67AB for ; Wed, 25 Jun 2008 08:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, 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 OYCVxZOXNVyy for ; Wed, 25 Jun 2008 08:47:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0B1DC28C0F9 for ; Wed, 25 Jun 2008 08:47:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AFBC921284; Wed, 25 Jun 2008 17:47:11 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-d0-4862687ff16a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F3D620F8C; Wed, 25 Jun 2008 17:47:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 17:47:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 17:47:28 +0200 Message-ID: In-Reply-To: <48613B9F.5020307@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft submission: draft-ietf-sip-199-00 thread-index: AcjWJ33OOqHXx3jdTxWGs7bycJB7RgAsxEYA References: <200806130255.m5D2t0gC031044@dragon.ariadne.com> <200806202237.m5KMbcuk008312@dragon.ariadne.com><4860A45F.9020001@zonnet.nl> <48613B9F.5020307@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "Rockson Li (zhengyli)" X-OriginalArrivalTime: 25 Jun 2008 15:47:30.0337 (UTC) FILETIME=[C69BC110:01C8D6DA] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jeroen, Forgive me if I don't understand what you are trying to say, but if you hav= e an early dialog it means that you have received a non-100 provisional res= ponse with a to-tag. Are you asking that I should indicate which state the entity is in when it = sends the 199? Do you have some wording proposal? Regards, Christer = -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = Sent: 24. kes=E4kuuta 2008 21:23 To: Rockson Li (zhengyli) Cc: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Christer, My point was to formalize the moment a 199 is sent by relating it to the RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE reque= sts don't use provisional responses here) So associated with PROCEEDING-->C= OMPLETED, but indeed only if a to-tag was received before (so not only 100) Regards, Jeroen PS perhaps an idea to explicitly disallow 199 for non-INVITE requests? Rockson Li (zhengyli) wrote: > Yes, it's a typo, 100 does not establish early-dialog. > -Rockson > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 24, 2008 6:32 PM > To: Rockson Li (zhengyli); Jeroen van Bemmel > Cc: sip@ietf.org > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > > Hi, > > = >>> Should the 199 response contain a Contact header? And if yes, in = >>> case a proxy sends it, should it contain the address of that proxy (sin= ce the UAS already sent a final response)? >>> = >> IF the 199 is sent reliably be the proxy must contain a Contact header c= ontaining the address of the proxy, yes. >> >> = >>> Should we say that a proxy may only generate and send a 199 when it = >>> receives a final error response on an INVITE client Transaction = >>> which was in the PROCEEDING state? (i.e. 1xx response was received = >>> before, so conceptually sending the 199 response is an action = >>> associated with the transition from PROCEEDING to COMPLETED) >>> = >> I am not sure I understand. The idea IS to send 199 when a final = >> error response is received by the forking proxy, if a 18x has previously= been received. >> [Rockson] PROCEEDING does not mean early-dialog is established, 100 = >> Trying also move INVITE client Transaction to PROCEEDING state. >> = > > [Christer] 199 is only sent when an early dialog has been established. 10= 0 Trying does not establish an early dialog. > > Regards, > > Christer > > > > > > > Also, a forking proxy with multiple INVITE client Transaction may receive= /forward 180 from one of them, and receive no provisional resp and final re= sp directly from the other one, so INVITE client Transaction's state is no= t dependable. The decision making must be done in TU. > > > > > > Christer Holmberg wrote: > = >> Hi, >> >> I agree it may be a good idea to not forbid sending it reliably. >> >> I do think it would be good to have text, saying that it can be sent unr= eliable even if reliable responses are required, though, so that proxies ar= en't forced to terminate PRACKs etc. >> >> Regards, >> >> Christer >> = >> >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = >> Dale.Worley@comcast.net >> Sent: 21. kes=E4kuuta 2008 1:38 >> To: sip@ietf.org >> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >> >> From: "Christer Holmberg" >> >> [CHH] Whether the text should be in the document at all depends on if= we >> allow 199 to be sent reliably in the first place. Based on the commen= ts >> received so far we should not mandate 199 to be sent reliably, even if >> 100rel is required by the UAC. But, the question if whether we want to >> FORBID sending it reliably. >> >> If we ever might allow 199 to be used for HERFP, we should admit the pos= sibility of sending it reliably in the first draft. Otherwise, we'll be lo= cked out of sending it reliably in the future. >> >> Dale >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip = >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip >> >> = >> = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 08:55:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF0428C0FC; Wed, 25 Jun 2008 08:55:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7136E28C11B for ; Wed, 25 Jun 2008 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 KJT6DxgrXxtC for ; Wed, 25 Jun 2008 08:55:21 -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 6D40828C0FC for ; Wed, 25 Jun 2008 08:55:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,703,1204531200"; d="scan'208";a="44557627" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2008 08:55:23 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5PFtN8u009904; Wed, 25 Jun 2008 08:55:23 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5PFtMsc010791; Wed, 25 Jun 2008 15:55:23 GMT From: "Dan Wing" To: "'Elwell, John'" , "'Vijay K. Gurbani'" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 25 Jun 2008 08:55:22 -0700 Message-ID: <0d5101c8d6db$e0751310$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkAAEP1fAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2511; t=1214409323; x=1215273323; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=vDID8uh7zhYJbJEonOPBa2zsX3lsEIOxYg2+LRyYKVU=; b=jAAP6CkQ14FZQYJ7fGcdRaFzYuwrYoj7EOqVF3PpekrIzj9y0+OMzyvlZf Ruuow1A33v7FyZHJIxfK/1a1X2/yne7haPuA0u55ZMmQQ1vAQ6miXjpbZi4d Hd1gn2IneDskO6A/h8zsDobWgtIp/xEFJPfZQRyaElhIMMs8454B4=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > > Furthermore, trying to match sender identity as carried in > > > From to the TLS-level connection identity as carried in the > > > certificate does not work well in the the hop-by-hop model. > > > For instance, the sender's From may as well be user@a.com, but > > > the last upstream proxy that opened up a connection to the > > > recipient could be some intermediary (proxy.com) not in the > > > a.com domain, thus making it impossible to enforce that the > > > From must match the identity of the last upstream proxy in the > > > certificate. > > > > Agreed. > > > > > Did you have some alternate or new thoughts on this to see if > > > we can hash out something that would still be in the context > > > of the domain-certs draft? As it stands, Scott and I are about > > > to submit a final post WGLC revision on it by next week. > > > > I don't think extending domain-cert's scope would be wise -- > > rather, I do think this is a separate problem. The separate > > problem is that with *some domains* you connect to (and do > > domain-certs validation with), you trust them to claim and > > use any old "From" they want -- because with those domains > > you trust them to have done some validation of their previous > > hop, who validated their previous hop, etc. This is how > > you would configure a SIP trunk with a service provider, for > > example. > > > > However, if you are communicating directly with another > > organization then you would not want to allow them to assert > > any identity they wished, because the only identity you expect > > them to send you requests with a From that had their own > > identity (@microsoft.com, @boeing.com, etc.) -- that is, > > the identity of their own employees. You do not expect them > > to assert the identity belonging to some other company. You > > would not extend the transitive trust to them. > [JRE] It depends. I (john@siemens.com) receive a call from > dan@cisco.com, and because I am working at home, the siemens.com proxy > forwards it to my home via a service provider. The service > provider now > needs to accept dan@cisco.com (rather than xxx@siemens.com) as the > source of the call. At home I would expect to receive dan@cisco.com as > caller ID. So the title of the document would be "Validating SIP From Considered Harmful". After writing that document, do you feel the community would then see the need for designing a B2BUA-survivable identity mechanism?? -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 09:01:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06993A686E; Wed, 25 Jun 2008 09:01:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8213A68C2 for ; Wed, 25 Jun 2008 09:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 uE58sP0ssyu6 for ; Wed, 25 Jun 2008 09:01:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 44AE63A6A37 for ; Wed, 25 Jun 2008 09:01:20 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5PG1JLl026418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Jun 2008 11:01:21 -0500 Message-Id: <96A06FFB-912F-4F0C-BAF3-7E39A1783912@softarmor.com> From: Dean Willis To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E47C@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 25 Jun 2008 11:01:14 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E47C@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] First draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 25, 2008, at 2:24 AM, Elwell, John wrote: >> > [JRE] It also suffers an additional limitation to do with E.164 > numbers. > So I would prefer to say: > "RFC 4474 suffers additional limitations relating to its use with E. > 164 > numbers and with gateways, session border controllers, and back-to- > back > user agents." > Does it really have issues with E,164 numbers, or only when they are used through gateways? For example, I thought we had agreed that if the ENUM entry for an E.164 points to a domain including an authentication service, then that AS could reasonably issue Identity headers on that phone number. >> > [JRE] One thing we have talked about in the past has been an > additional > parameter in a SIP URI. I am not saying we definitely need to do this, > but I would not want to close the door on this if the group > concludes it > would be a good thing. Another possible deliverable might a some > sort of > BCP to do with E.164 numbers in SIP URIs. That is indeed one of the proposals for alerting an RFC4474 consumer to the fact that the identity assertion is "weak" because it came from the PSTN. General guidance on E.164s in URIs might be a reasonable thing to do. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 09:06:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA063A698C; Wed, 25 Jun 2008 09:06:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121833A698C for ; Wed, 25 Jun 2008 09:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 ZjxBU-8AtoiU for ; Wed, 25 Jun 2008 09:06:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 35EF83A68E5 for ; Wed, 25 Jun 2008 09:06:48 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5PG6ibx026450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Jun 2008 11:06:46 -0500 Message-Id: From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 25 Jun 2008 11:06:39 -0500 X-Mailer: Apple Mail (2.924) Cc: Keith Drage , Gonzalo Camarillo Subject: [Sip] WGLC for draft-ietf-sip-body-handling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm pleased to announce a working group last call for the "Body Handling" draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-02.txt This draft is intended for the Standards Track. The only minor issue I'm aware of is an outdated reference that should have no impact on the review: == Outdated reference: A later version (-08) exists of draft-ietf- mmusic-file-transfer-mech-06 Please review the draft carefully and post your comments back to the list and author. I'd like to conclude this WGLC period by July 11, 2008. Ok everybody, get busy reviewing! -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 09:13:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95583A694D; Wed, 25 Jun 2008 09:13:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CB73A694D for ; Wed, 25 Jun 2008 09:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnFVeYCgrzDs for ; Wed, 25 Jun 2008 09:12:59 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 321533A67AB for ; Wed, 25 Jun 2008 09:12:59 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5PGCxx6026526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 25 Jun 2008 11:13:00 -0500 Message-Id: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 25 Jun 2008 11:12:53 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] Second draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've revised the proposed charter fora RETIRE working group based on list comments. This is still a very early concept, and the formation of such a working group is contingent on a great many things that are outside of my control. -------- The "REal Time Identity and Role Expression" (RETIRE) Working Group's purpose is to standardize the expression and assertion of identity and roles needed for real-time communications with the IETF's Realtime Applications Infrastructure (RAI) area protocols, primarily the Session Initiation Protocol (SIP) and others used in conjunction with SIP. By "Identity", we mean authenticated addresses of record (as defined in RFC 4474 "Enhancements for Authenticated Identity Management in the Session Initiation Protocol". RFC 4474 provides a means by which a SIP server may vouch for the "From" address of a request transiting that server. It further provides a cryptographic mechanism for testing the source of the assertion. In the typical case, this mechanism is dependent on the same Public Key Infrastructure that supports secure HTTP services. Since RFC 4474 provides only authentication of the source of SIP request messages and it is also important to determine the identity of the sender of responses, RFC 4916 "Connected Identity in the Session Initiation Protocol" provides authenticated identity in an ongoing SIP dialog by applying RFC 4474 to requests in the reverse direction. While adequate for some scenarios, this mechanism is not useful for SIP interactions having a single non-dialog transaction, such as MESSAGE requests. RFC 4474 suffers additional limitations relating to its use with E.164 numbers, gateways, session border controllers, and back-to-back user agents. By "Role", we mean aspects of a a system user that are related identity, but more dynamic in nature. For example, Alice might delegate her calls to Bob. A calling party, expecting to reach Alice but reaching Bob, needs to know that this is a reasonable thing and what Bob's role in relation to Alice is. This problem is in general referred to as the "unanticipated respondent problem", and it has impacts both at the level of user expectations and key management. Proposals for fixing it have included deprecation of proxy retargeting and the use of a new SIP provisional response to inform the calling party about the retargeting operation. Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee. The SIP working group worked for several years on applying SAML to SIP with mixed results, but the technique appears to have great promise. The initial deliverables of the RETIRE working group are: 1) A standards-track revision of RFC 4474 that resolves its limitations with respect to E.164 numbers, gateways, session border controllers, and back-to-back user agents. This revision will also address the use of Authenticated Identity Management in conjunction with SIP response messages. It may also be necessary to document the impact of such changes, if any, on the DTLS-SRTP framework. 2) Specify a solution (or set of solutions) for the Unanticipated Respondent Problem in SIP. 3) Guidelines for the use of E.164 numbers as SIP identifiers. 4) Guidelines for the use of SAML with SIP for the purposes of expressing identity and role, specifically in the contexts of #1, #2 and #3 above. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 10:05:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5305C28B23E; Wed, 25 Jun 2008 10:05:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A07228C0CE for ; Wed, 25 Jun 2008 10:05:41 -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 Av1nNHUeSyR2 for ; Wed, 25 Jun 2008 10:05:40 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by core3.amsl.com (Postfix) with ESMTP id B973628B23E for ; Wed, 25 Jun 2008 10:05:31 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP; Wed, 25 Jun 2008 10:05:33 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 m5PH28G3029745; Wed, 25 Jun 2008 10:02:08 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m5PH5UI0010543; Wed, 25 Jun 2008 10:05:30 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 10:05:30 -0700 Received: from 10.58.20.192 ([10.58.20.192]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Jun 2008 17:05:29 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 25 Jun 2008 10:05:28 -0700 From: Henry Sinnreich To: Dan Wing , "'Elwell, John'" , "'Vijay K. Gurbani'" Message-ID: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkAAEP1fAAACiKvX In-Reply-To: <0d5101c8d6db$e0751310$c2f0200a@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 25 Jun 2008 17:05:30.0494 (UTC) FILETIME=[AC3309E0:01C8D6E5] Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 6/25/08 8:55 AM, "Dan Wing" wrote: > So the title of the document would be "Validating SIP From Considered > Harmful". After writing that document, do you feel the community would > then see the need for designing a B2BUA-survivable identity mechanism?? > > -d No mechanism can survive with B2BUAs and intermediaries in general. That's why we have the e2e principle on the Internet. Henry _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 10:11:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B98F3A6A55; Wed, 25 Jun 2008 10:11:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9799C3A6810 for ; Wed, 25 Jun 2008 10:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 kKIuZPAQ3jBS for ; Wed, 25 Jun 2008 10:11:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D73A03A6A70 for ; Wed, 25 Jun 2008 10:11:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 25 Jun 2008 13:10:16 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 25 Jun 2008 13:10:16 -0400 From: Hadriel Kaplan To: Henry Sinnreich , Dan Wing , "'Elwell, John'" , "'Vijay K. Gurbani'" Date: Wed, 25 Jun 2008 13:10:14 -0400 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkAAEP1fAAACiKvXAAAMIOA= Message-ID: References: <0d5101c8d6db$e0751310$c2f0200a@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Henry Sinnreich > > On 6/25/08 8:55 AM, "Dan Wing" wrote: > > > So the title of the document would be "Validating SIP From Considered > > Harmful". After writing that document, do you feel the community would > > then see the need for designing a B2BUA-survivable identity mechanism?? > > > > -d > > No mechanism can survive with B2BUAs and intermediaries in general. > That's why we have the e2e principle on the Internet. > Henry That's odd, it sure looks like your email went through a bunch of intermediaries. I wonder what it contained when it was originally sent. ;) -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 10:17:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD7A3A6A07; Wed, 25 Jun 2008 10:17:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80D93A6A2E for ; Wed, 25 Jun 2008 10:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 xQ6jqfyvcF5G for ; Wed, 25 Jun 2008 10:17:41 -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 3452F3A683B for ; Wed, 25 Jun 2008 10:17:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,703,1204531200"; d="scan'208";a="44600548" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2008 10:17:43 -0700 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 m5PHHhSv010874; Wed, 25 Jun 2008 10:17:43 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5PHHgV0025240; Wed, 25 Jun 2008 17:17:42 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Elwell, John'" , "'Vijay K. Gurbani'" References: <0d5101c8d6db$e0751310$c2f0200a@cisco.com> Date: Wed, 25 Jun 2008 10:17:43 -0700 Message-ID: <0da501c8d6e7$61853b50$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkAAEP1fAAACiKvXAABZlVA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=728; t=1214414263; x=1215278263; c=relaxed/simple; s=sjdkim3002; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=L9P0yvesL4Mg3nB1QrUgR3KRo4pzWGmf0tdcCUQ0x8U=; b=JB7JJWWFDLapE4U4YdNypWH93kbDBOJNvQ9sDqVk+AiFgMC/NICkxhderO gshREcrK8DHZSGaQyJBcajkJ+O7LzwpoN40QyCeKbV9E40leOlQ/nP4gW3rQ rV5n9nGUEB; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > So the title of the document would be "Validating SIP From > > Considered > > Harmful". After writing that document, do you feel the > > community would > > then see the need for designing a B2BUA-survivable identity > > mechanism?? > > > > -d > > No mechanism can survive with B2BUAs and intermediaries in general. Two I-Ds have been proposed which will survive B2BUAs and SBCs: http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 http://tools.ietf.org/html/draft-wing-sip-identity-media-02 > That's why we have the e2e principle on the Internet. TLS and IPsec work through transport- and network-layer intermediaries (NATs and NAPTs), and NAPTs destroy the e2e principle. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 11:31:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AEB3A6AB9; Wed, 25 Jun 2008 11:31:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB0D3A6ABC for ; Wed, 25 Jun 2008 11:31:09 -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 OT86SeytTiDO for ; Wed, 25 Jun 2008 11:31:06 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 853C93A69AC for ; Wed, 25 Jun 2008 11:31:02 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Wed, 25 Jun 2008 11:31:03 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m5PIUwE0007505; Wed, 25 Jun 2008 11:30:59 -0700 (PDT) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m5PIUuI0027696; Wed, 25 Jun 2008 11:30:57 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 03:30:55 +0900 Received: from 10.58.20.192 ([10.58.20.192]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Jun 2008 18:30:53 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 25 Jun 2008 11:30:53 -0700 From: Henry Sinnreich To: Dan Wing , "'Elwell, John'" , "'Vijay K. Gurbani'" Message-ID: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkAAEP1fAAACiKvXAABZlVAAAqIa6w== In-Reply-To: <0da501c8d6e7$61853b50$c2f0200a@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 25 Jun 2008 18:30:55.0732 (UTC) FILETIME=[9B144B40:01C8D6F1] Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Two I-Ds have been proposed which will survive B2BUAs and SBCs: You would have to show that what is valid for identity can be extended to any type of application. > TLS and IPsec work through transport- and network-layer intermediaries (NATs > and NAPTs), and NAPTs destroy the e2e principle. Same as above. Can this be generalized? What complexity costs are involved? This is an interesting discussion to pursue with the IAB. Henry On 6/25/08 10:17 AM, "Dan Wing" wrote: >>> So the title of the document would be "Validating SIP From >>> Considered >>> Harmful". After writing that document, do you feel the >>> community would >>> then see the need for designing a B2BUA-survivable identity >>> mechanism?? >>> >>> -d >> >> No mechanism can survive with B2BUAs and intermediaries in general. > > Two I-Ds have been proposed which will survive B2BUAs and SBCs: > > http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 > http://tools.ietf.org/html/draft-wing-sip-identity-media-02 > >> That's why we have the e2e principle on the Internet. > > TLS and IPsec work through transport- and network-layer intermediaries (NATs > and NAPTs), and NAPTs destroy the e2e principle. > > -d > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 11:43:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686E43A6A32; Wed, 25 Jun 2008 11:43:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB1B3A69F9 for ; Wed, 25 Jun 2008 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.343 X-Spam-Level: X-Spam-Status: No, score=-5.343 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 aslEFLrP81eJ for ; Wed, 25 Jun 2008 11:43:44 -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 9D3803A68A3 for ; Wed, 25 Jun 2008 11:43:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,703,1204531200"; d="scan'208";a="44642769" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2008 11:43:39 -0700 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 m5PIhcTO005829; Wed, 25 Jun 2008 11:43:38 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5PIhcLA018085; Wed, 25 Jun 2008 18:43:38 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Elwell, John'" , "'Vijay K. Gurbani'" References: <0da501c8d6e7$61853b50$c2f0200a@cisco.com> Date: Wed, 25 Jun 2008 11:43:40 -0700 Message-ID: <016601c8d6f3$636c5460$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkAAEP1fAAACiKvXAABZlVAAAqIa6wAAaZyw In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=874; t=1214419419; x=1215283419; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=Xi4tuDASD89Vq4YtTWl749UBmF/Hyc62iR5UDkP5Q2k=; b=u+dA7XF6M0ruYS+vaEB/1BHc3nkdaGMa9GR3NShgdnr6cp2kX4rwtALqs3 LYTq/31SrqhC+Cb5374RtFEVbMvxI3nKUcZQA0rNmTS+SgscT9LIjI0oI1+Q YOU4LzhU/mS5NlYiCAja8VH9bUb52gWvspO1Ao0Tz+DqaI5ON4xUw=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, June 25, 2008 11:31 AM > To: Dan Wing; 'Elwell, John'; 'Vijay K. Gurbani' > Cc: sip@ietf.org > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > Two I-Ds have been proposed which will survive B2BUAs and SBCs: > > You would have to show that what is valid for identity can > be extended to any type of application. So that one identity works for email, for SIP, for RTSP, for IPsec? That sounds like the Holy Grail. > > TLS and IPsec work through transport- and network-layer > > intermediaries (NATs > > and NAPTs), and NAPTs destroy the e2e principle. > > Same as above. Can this be generalized? > What complexity costs are involved? > > This is an interesting discussion to pursue with the IAB. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 12:09:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7F83A6A32; Wed, 25 Jun 2008 12:09:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83663A6A32 for ; Wed, 25 Jun 2008 12:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 AMGLXCwddMf3 for ; Wed, 25 Jun 2008 12:09:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CAFFB3A6817 for ; Wed, 25 Jun 2008 12:09:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 25 Jun 2008 15:08:16 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 25 Jun 2008 15:08:16 -0400 From: Hadriel Kaplan To: Dean Willis , "sip@ietf.org" Date: Wed, 25 Jun 2008 15:08:09 -0400 Thread-Topic: [Sip] Second draft, RETIRE Charter Thread-Index: AcjW3kDdIDj0X2jeT4C6mONbGtjBnQABU2HQ Message-ID: References: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> In-Reply-To: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Second draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If your goal is to have a short, focused and constrained WG, I would pull SAML out of it. Also, RETIRE is probably not the best of acronyms. :) How about "Sip Identity for Generic Name and E.164 Deployments"? (SIGNED) Or "Identity for Trust Assurance with Sip Topologies for Everyone"? (I-TASTE, which is the only way I can identify what I am Sipping :) -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Wednesday, June 25, 2008 12:13 PM > To: sip@ietf.org > Subject: [Sip] Second draft, RETIRE Charter > > I've revised the proposed charter fora RETIRE working group based on > list comments. This is still a very early concept, and the formation > of such a working group is contingent on a great many things that are > outside of my control. > > > -------- > > > The "REal Time Identity and Role Expression" (RETIRE) Working Group's > purpose is to standardize the expression and assertion of identity and > roles needed for real-time communications with the IETF's Realtime > Applications Infrastructure (RAI) area protocols, primarily the > Session Initiation Protocol (SIP) and others used in conjunction with > SIP. > > By "Identity", we mean authenticated addresses of record (as defined > in RFC 4474 "Enhancements for Authenticated Identity Management in the > Session Initiation Protocol". RFC 4474 provides a means by which a SIP > server may vouch for the "From" address of a request transiting that > server. It further provides a cryptographic mechanism for testing the > source of the assertion. In the typical case, this mechanism is > dependent on the same Public Key Infrastructure that supports secure > HTTP services. Since RFC 4474 provides only authentication of the > source of SIP request messages and it is also important to determine > the identity of the sender of responses, RFC 4916 "Connected Identity > in the Session Initiation Protocol" provides authenticated identity in > an ongoing SIP dialog by applying RFC 4474 to requests in the reverse > direction. While adequate for some scenarios, this mechanism is not > useful for SIP interactions having a single non-dialog transaction, > such as MESSAGE requests. RFC 4474 suffers additional limitations > relating to its use with E.164 numbers, gateways, session border > controllers, and back-to-back user agents. > > By "Role", we mean aspects of a a system user that are related > identity, but more dynamic in nature. For example, Alice might > delegate her calls to Bob. A calling party, expecting to reach Alice > but reaching Bob, needs to know that this is a reasonable thing and > what Bob's role in relation to Alice is. This problem is in general > referred to as the "unanticipated respondent problem", and it has > impacts both at the level of user expectations and key management. > Proposals for fixing it have included deprecation of proxy retargeting > and the use of a new SIP provisional response to inform the calling > party about the retargeting operation. > > Security Assertion Markup Language (SAML) is an XML-based standard for > exchanging authentication and authorization data between security > domains, that is, between an identity provider (a producer of > assertions) and a service provider (a consumer of assertions). SAML is > a product of the OASIS Security Services Technical Committee. The SIP > working group worked for several years on applying SAML to SIP with > mixed results, but the technique appears to have great promise. > > > The initial deliverables of the RETIRE working group are: > > 1) A standards-track revision of RFC 4474 that resolves its > limitations with respect to E.164 numbers, gateways, session border > controllers, and back-to-back user agents. This revision will also > address the use of Authenticated Identity Management in conjunction > with SIP response messages. It may also be necessary to document the > impact of such changes, if any, on the DTLS-SRTP framework. > > 2) Specify a solution (or set of solutions) for the Unanticipated > Respondent Problem in SIP. > > 3) Guidelines for the use of E.164 numbers as SIP identifiers. > > 4) Guidelines for the use of SAML with SIP for the purposes of > expressing identity and role, specifically in the contexts of #1, #2 > and #3 above. > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 12:13:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D44028C104; Wed, 25 Jun 2008 12:13:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7E73A69AC for ; Wed, 25 Jun 2008 12:13:17 -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 IfsnW1E6bfpI for ; Wed, 25 Jun 2008 12:13:16 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F3A8B28C104 for ; Wed, 25 Jun 2008 12:13:15 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5PJ8N6p011208; Wed, 25 Jun 2008 14:13:10 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 22:11:03 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 22:11:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 22:11:00 +0300 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAASySNcA== References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> From: To: , , , X-OriginalArrivalTime: 25 Jun 2008 19:11:03.0536 (UTC) FILETIME=[363E0700:01C8D6F7] X-Nokia-AV: Clean Cc: christer.holmberg@ericsson.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I'm a bit sceptical about the need for keep-alives between proxies. It is of course entirely possible that an enterprise PBX is connected to (or peering with) a service provider proxy through a NAT and/or a firewall. However, wouldn't such a NAT or firewall be under the administration of either the enterprise itself or its ISP (who quite often would be the SIP service provider), and the required port forwardings or firewall rules could be set through administration. This means that there would not be need for keepalive traffic to implicitely keep the mapping/pinhole open. Or are there really deployment cases where there are SIP PBXs behind unadministrated NATs or firewalls? Wouldn't we then need keepalives for SMTP as well, or how has the e-mail infrastructure managed to solve this problem? Markus >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of ext Elwell, John >Sent: 24 June, 2008 10:15 >To: Hadriel Kaplan; DRAGE, Keith (Keith); sip@ietf.org >Cc: Christer Holmberg >Subject: Re: [Sip] Progress draft-holmberg-sip-keep > >Hadriel, > >Concerning your "PBX connections a la SIP trunks" use case, I >am not convinced of this. ETSI TISPAN has specified two ways >for an IPPBX to connect to a service provider. One is the >so-called subscription-based approach, where the IPPBX >registers with the SP and communicates via an edge proxy. In >this case, why not use SIP-outbound? The other is the >so-called peering-based approach, which is essentially the >same as any SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, >proxy-to-gateway. >SIP-outbound does not apply to these situations, and similarly >the keep-alive mechanism is not specified for this cases. The >requirements in SIP-keep do not cover these situations. > >Basically I am not sold on the idea of a separate SIP-keep >spec - I don't think it would be the best use of WG time. > >John > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of >> Hadriel Kaplan >> Sent: 20 June 2008 18:20 >> To: DRAGE, Keith (Keith); sip@ietf.org >> Cc: Christer Holmberg >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep >> >> >> My 2 cents: it is a useful draft. Personally, I would like >to have it >> available for two reasons not cited: PBX connections a la >SIP trunks, >> and proxy-proxy connections. >> Today I think a lot of people are using OPTIONS requests or >> proprietary means to perform such keep-alives when >registration is not >> appropriate, but it has led to some interop issues and performance >> concerns in some cases. >> >> Since the contentious issue of what form the keep-alives take have >> already been agreed on for outbound, this seems like a >simple draft to >> get done. (famous last words, I know) >> >> -hadriel >> >> >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of >> > DRAGE, Keith (Keith) >> > Sent: Thursday, June 19, 2008 5:31 AM >> > To: sip@ietf.org >> > Cc: Christer Holmberg >> > Subject: [Sip] Progress draft-holmberg-sip-keep >> > >> > (As SIP WG cochair) >> > >> > We have been asked by the author of >> > >> > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt >> > >> > Whether the SIP WG can progress this document. >> > >> > Because this draft arose as a result of the discussion of >> outbound, and >> > indeed seems to reuse the requirements from outbound, and these >> > requirements never really got handled in the SIPPING WG, >it has been >> > agreed with the SIPPING chairs that we will handle this >> entirely within >> > SIP. >> > >> > Now in order to ask for charter milestones, and indeed when >> we finally >> > present this to IESG, we will be asked for the level of >> support in the >> > WG, which is also predicated on does this fix a real >> problem, or is it >> > just a corner case with limited application. So: >> > >> > QUESTION 1 TO SIP WG: Are the use cases sufficiently important to >> > proceed with this draft? The document states: >> > >> > Chapter 3.5 of draft-ietf-sip-outbound-13 >[I-D.ietf-sip-outbound] >> > defines two keep-alive techniques. Even though the keep-alive >> > techniques are separated from the Outbound mechanism >> > [I-D.ietf-sip-outbound], it is currently not possible >to indicate >> > support of the keep-alive techniques without also >> indicating support >> > for the Outbound mechanism. >> > >> > The Outbound mechanism is enabled during the UA >> registration phase. >> > However, there are use-cases where the UA does not >> register itself, >> > but still needs to be able to make calls and maintain >> NAT bindings >> > open during the duration of that call. A typical example is >> > emergency calls. There are also cases where entities do >> not support >> > the Outbound mechanism, but still want to be able to >> indicate support >> > and use the keep-alive techniques defined in >> [I-D.ietf-sip-outbound]. >> > >> > At first sight this is not the most inspiring declaration >> of the need >> > for the document. Please respond indicating whether you >> consider this a >> > useful draft, and propose text that you think would be >> useful in this >> > section. Conversely, if you think this draft is not useful >> and the WG >> > has other more important things to work on first, please >> also respond. >> > >> > QUESTION 2 TO SIP WG: Do we have a robust set of requirements for >> > proceeding with this work? The document currently lists: >> > >> > REQ 1: It MUST be possible for a UA to indicate support >> of the keep- >> > alive techniques defined [I-D.ietf-sip-outbound] if the >> UA supports >> > only the keep-alive part of [I-D.ietf-sip-outbound]. >> > >> > REQ 2: It MUST be possible for an edge proxy to indicate >> support of >> > the keep-alive techniques defined >> [I-D.ietf-sip-outbound] if the edge >> > poxy supports only the keep-alive part of >> [I-D.ietf-sip-outbound]. >> > >> > It would be desirable to agree these at the outset, and not >> revisit them >> > if we continue with the work. So if you require clarification, >> > modification, or addition to these two requirements, then >> please also >> > response with your questions and proposals. >> > >> > I suggest we would like responses by 30th June 2008 in >> order to allow >> > the author to revise the document before the deadlines. >> Please note that >> > we are looking to make this decision on the list within >> this deadline >> > based on responses received, not leave it until the Dublin meeting. >> > >> > Regards >> > >> > Keith >> > _______________________________________________ >> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol Use >> > sip-implementors@cs.columbia.edu for questions on current sip Use >> > sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 12:34:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7AF3A6AD9; Wed, 25 Jun 2008 12:34:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F033A6AD9 for ; Wed, 25 Jun 2008 12:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 QmP06HBB-m5C for ; Wed, 25 Jun 2008 12:34:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CD5283A6AD8 for ; Wed, 25 Jun 2008 12:34:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 25 Jun 2008 15:33:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 25 Jun 2008 15:33:45 -0400 From: Hadriel Kaplan To: "Markus.Isomaki@nokia.com" , "john.elwell@siemens.com" , "drage@alcatel-lucent.com" , "sip@ietf.org" Date: Wed, 25 Jun 2008 15:33:34 -0400 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAASySNcAAAnTcg Message-ID: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "christer.holmberg@ericsson.com" Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes I am of that same opinion - that any real "IP-PBX" or whatever big enough NOT to be doing Registration, and to instead do static provisioning or DNS, would be given a static hole/DMZ address in their firewall/NAT. But some of my customers have told me otherwise. (interestingly mostly in APAC region) There's also some concern that while a static entry is there for inbound TCP connections, the PBX creates outbound ones to the service provider which are ephemeral port sources and need to live for very long durations (though why they can't just do TCP keepalive is beyond me, but I'm no expert). But anyway, the big issue we've seen is that we need both the PBX and the service provider box to detect failure before an active call/request attempt is made; to trigger alternate route selection without waiting for transport failure, and as a method to detect liveness again and revert. Today that's almost exclusively done with Options requests as far as I've seen, and lots of people don't seem to like that. -hadriel > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Wednesday, June 25, 2008 3:11 PM > To: john.elwell@siemens.com; Hadriel Kaplan; drage@alcatel-lucent.com; > sip@ietf.org > Cc: christer.holmberg@ericsson.com > Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use > case > > Hi, > > I'm a bit sceptical about the need for keep-alives between proxies. It > is of course entirely possible that an enterprise PBX is connected to > (or peering with) a service provider proxy through a NAT and/or a > firewall. However, wouldn't such a NAT or firewall be under the > administration of either the enterprise itself or its ISP (who quite > often would be the SIP service provider), and the required port > forwardings or firewall rules could be set through administration. This > means that there would not be need for keepalive traffic to implicitely > keep the mapping/pinhole open. > > Or are there really deployment cases where there are SIP PBXs behind > unadministrated NATs or firewalls? > > Wouldn't we then need keepalives for SMTP as well, or how has the e-mail > infrastructure managed to solve this problem? > > Markus > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 12:57:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAD73A6AC8; Wed, 25 Jun 2008 12:57:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255623A67A5 for ; Wed, 25 Jun 2008 12:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL2BMlvj4jAW for ; Wed, 25 Jun 2008 12:57:29 -0700 (PDT) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by core3.amsl.com (Postfix) with ESMTP id D7FEA3A68CC for ; Wed, 25 Jun 2008 12:57:28 -0700 (PDT) Received: (qmail 4608 invoked by uid 0); 25 Jun 2008 19:57:28 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Jun 2008 19:57:28 -0000 Message-ID: <4862A324.6020703@zonnet.nl> Date: Wed, 25 Jun 2008 21:57:24 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hadriel Kaplan References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Cc: "sip@ietf.org" , "drage@alcatel-lucent.com" , "christer.holmberg@ericsson.com" , "john.elwell@siemens.com" , "Markus.Isomaki@nokia.com" Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, Markus, Instead of standardizing keep-alives between proxies, how about we define a "virtual UA" on each element (similar to the one described in RFC3261 section 16.7 point 6) to be used to provide this functionality? (using existing outbound functionality, perhaps both ways) Regards, Jeroen Hadriel Kaplan wrote: > Yes I am of that same opinion - that any real "IP-PBX" or whatever big enough NOT to be doing Registration, and to instead do static provisioning or DNS, would be given a static hole/DMZ address in their firewall/NAT. But some of my customers have told me otherwise. (interestingly mostly in APAC region) > There's also some concern that while a static entry is there for inbound TCP connections, the PBX creates outbound ones to the service provider which are ephemeral port sources and need to live for very long durations (though why they can't just do TCP keepalive is beyond me, but I'm no expert). > > But anyway, the big issue we've seen is that we need both the PBX and the service provider box to detect failure before an active call/request attempt is made; to trigger alternate route selection without waiting for transport failure, and as a method to detect liveness again and revert. Today that's almost exclusively done with Options requests as far as I've seen, and lots of people don't seem to like that. > > -hadriel > > > >> -----Original Message----- >> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >> Sent: Wednesday, June 25, 2008 3:11 PM >> To: john.elwell@siemens.com; Hadriel Kaplan; drage@alcatel-lucent.com; >> sip@ietf.org >> Cc: christer.holmberg@ericsson.com >> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use >> case >> >> Hi, >> >> I'm a bit sceptical about the need for keep-alives between proxies. It >> is of course entirely possible that an enterprise PBX is connected to >> (or peering with) a service provider proxy through a NAT and/or a >> firewall. However, wouldn't such a NAT or firewall be under the >> administration of either the enterprise itself or its ISP (who quite >> often would be the SIP service provider), and the required port >> forwardings or firewall rules could be set through administration. This >> means that there would not be need for keepalive traffic to implicitely >> keep the mapping/pinhole open. >> >> Or are there really deployment cases where there are SIP PBXs behind >> unadministrated NATs or firewalls? >> >> Wouldn't we then need keepalives for SMTP as well, or how has the e-mail >> infrastructure managed to solve this problem? >> >> Markus >> >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 13:19:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF9F28C13F; Wed, 25 Jun 2008 13:19:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917F428C13A for ; Wed, 25 Jun 2008 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 QW195x05UcNY for ; Wed, 25 Jun 2008 13:19:01 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 9B27D28C11A for ; Wed, 25 Jun 2008 13:19:01 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K310006OCFQC6@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 21:19:02 +0100 (BST) Date: Wed, 25 Jun 2008 21:18:49 +0100 From: "Elwell, John" In-reply-to: To: "Tschofenig, Hannes (NSN - FI/Espoo)" , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWu7bItHEZm/qzRxKdJneZdiknCQAA9CEwAABwkGAAD7hfMA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hannes, > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: 25 June 2008 14:00 > To: Elwell, John; Paul Kyzivat > Cc: sip@ietf.org; Dan Wing > Subject: RE: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > Consider the following scenario: > > +-----------+ +-----------+ > |SIP | |SIP | > +------>|Proxy |<---------->|Proxy |<------+ > | |Server X | TLS |Server Y | | > | +-----------+ +-----------+ | > | | > | TLS or TLS or | > | SIP Digest SIP Digest | > | | > | | > v v > +-----------+ +-----------+ > |SIP | |SIP | > |User Agent | RTP |User Agent | > |Alice | <=================================> |Bob | > +-----------+ +-----------+ > > > When there are no further proxies between X and Y then Y has the > information that Alice was authenticated by X. Proxy Y would pass that > info on to Bob. Bob trusts Y. > > Obviously, the two VoIP providers may have a far more complicated > infrastructure with multiple proxies but they all belong to the same > domain and could be seen from external as just one box. > > The same would not work when there are more proxies between X and Y. > However, these guys that prefer such a deployment belong more to the > chain of trust camp rather than the end-to-end / email alike peering > camp. It is rather unlikely that you get their support for getting SIP > Identity to work in their networks. > > So, do we have an indication that some folks plan to use SIP Identity > for their deployment? [JRE] Well, what about enterprise via service provider to enterprise? As an enterprise provider, I would like to be able to use SIP identity, but a precondition is that it gets through that intermediate service provider(s). > > Wouldn't it be better to rely on something like SIP CERT for a better > end-to-end security mechanism (ignoring for a moment that SIP > CERT also > uses SIP Identity for "simplified deployment" reasons whereby > one has to > state that the usage of SIP Identity for SUBSCRIBE/NOTIFY might have > different B2BUA aspects). [JRE] You have lost me there. What is SIP CERT? Can you point me at a draft? John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 13:22:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04A73A6A32; Wed, 25 Jun 2008 13:22:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1295D28C14C for ; Wed, 25 Jun 2008 13:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 Zwai9-mzH6j1 for ; Wed, 25 Jun 2008 13:22:48 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D6FA93A67A5 for ; Wed, 25 Jun 2008 13:22:47 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K3100081CM0C6@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 21:22:48 +0100 (BST) Date: Wed, 25 Jun 2008 21:22:34 +0100 From: "Elwell, John" In-reply-to: <0d5101c8d6db$e0751310$c2f0200a@cisco.com> To: Dan Wing , "Vijay K. Gurbani" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjWQYYI7aX1gs3ARUWQhETRaxgtEgAAGQuQABVqFkAAEP1fAAAJXZLw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <0d5101c8d6db$e0751310$c2f0200a@cisco.com> Cc: sip@ietf.org Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: 25 June 2008 16:55 > To: Elwell, John; 'Vijay K. Gurbani' > Cc: sip@ietf.org > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > > > > Furthermore, trying to match sender identity as carried in > > > > From to the TLS-level connection identity as carried in the > > > > certificate does not work well in the the hop-by-hop model. > > > > For instance, the sender's From may as well be user@a.com, but > > > > the last upstream proxy that opened up a connection to the > > > > recipient could be some intermediary (proxy.com) not in the > > > > a.com domain, thus making it impossible to enforce that the > > > > From must match the identity of the last upstream proxy in the > > > > certificate. > > > > > > Agreed. > > > > > > > Did you have some alternate or new thoughts on this to see if > > > > we can hash out something that would still be in the context > > > > of the domain-certs draft? As it stands, Scott and I are about > > > > to submit a final post WGLC revision on it by next week. > > > > > > I don't think extending domain-cert's scope would be wise -- > > > rather, I do think this is a separate problem. The separate > > > problem is that with *some domains* you connect to (and do > > > domain-certs validation with), you trust them to claim and > > > use any old "From" they want -- because with those domains > > > you trust them to have done some validation of their previous > > > hop, who validated their previous hop, etc. This is how > > > you would configure a SIP trunk with a service provider, for > > > example. > > > > > > However, if you are communicating directly with another > > > organization then you would not want to allow them to assert > > > any identity they wished, because the only identity you expect > > > them to send you requests with a From that had their own > > > identity (@microsoft.com, @boeing.com, etc.) -- that is, > > > the identity of their own employees. You do not expect them > > > to assert the identity belonging to some other company. You > > > would not extend the transitive trust to them. > > [JRE] It depends. I (john@siemens.com) receive a call from > > dan@cisco.com, and because I am working at home, the > siemens.com proxy > > forwards it to my home via a service provider. The service > > provider now > > needs to accept dan@cisco.com (rather than xxx@siemens.com) as the > > source of the call. At home I would expect to receive > dan@cisco.com as > > caller ID. > > So the title of the document would be "Validating SIP From Considered > Harmful". After writing that document, do you feel the > community would > then see the need for designing a B2BUA-survivable identity > mechanism?? [JRE] It's not the best starting point - rather a long train of thought to get to the conclusion. However, it is one of the many factors in this complicated equation. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 13:29:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA36B28C15E; Wed, 25 Jun 2008 13:29:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161CB28C15D for ; Wed, 25 Jun 2008 13:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 9LATT4I2mans for ; Wed, 25 Jun 2008 13:29:46 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3DBCB28C15A for ; Wed, 25 Jun 2008 13:29:46 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K310011ICXO8N@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Jun 2008 21:29:48 +0100 (BST) Date: Wed, 25 Jun 2008 21:29:32 +0100 From: "Elwell, John" In-reply-to: <96A06FFB-912F-4F0C-BAF3-7E39A1783912@softarmor.com> To: Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] First draft, RETIRE Charter Thread-Index: AcjW3MTAi/ycXjRgTYadY+hZrOE84AAJT1kg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D0D6E47C@GBNTHT12009MSX.gb002.siemens.net> <96A06FFB-912F-4F0C-BAF3-7E39A1783912@softarmor.com> Cc: sip@ietf.org Subject: Re: [Sip] First draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 25 June 2008 17:01 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] First draft, RETIRE Charter > > > On Jun 25, 2008, at 2:24 AM, Elwell, John wrote: > > >> > > > [JRE] It also suffers an additional limitation to do with E.164 > > numbers. > > So I would prefer to say: > > "RFC 4474 suffers additional limitations relating to its > use with E. > > 164 > > numbers and with gateways, session border controllers, and back-to- > > back > > user agents." > > > > Does it really have issues with E,164 numbers, or only when they are > used through gateways? For example, I thought we had agreed that if > the ENUM entry for an E.164 points to a domain including an > authentication service, then that AS could reasonably issue Identity > headers on that phone number. [JRE] That was suggested - I am not sure there was an agreement, and even that would need documenting. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 14:31:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11C43A6A01; Wed, 25 Jun 2008 14:31:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C923A699F for ; Wed, 25 Jun 2008 14:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 nWt7FnNRmOUm for ; Wed, 25 Jun 2008 14:31:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 066863A68D4 for ; Wed, 25 Jun 2008 14:31:08 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6177D20437; Wed, 25 Jun 2008 23:31:09 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-63-4862b91dfa08 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3691D201A3; Wed, 25 Jun 2008 23:31:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 23:31:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 23:31:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case thread-index: AcjRkpnVfshskm2FTkKiI23wFbuvYABYtopQALTQNDAASySNcAAAnTcgAASlqyA= References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Hadriel Kaplan" , , , , X-OriginalArrivalTime: 25 Jun 2008 21:31:37.0716 (UTC) FILETIME=[D967C340:01C8D70A] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Also, in some of the "proxy-to-proxy" cases it is not necessarily about the= need for NAT keep-alive, but more about the need for a "heartbeat" functio= n (I guess that is what Hadriel is also talking about). Today that function= ality is sometimes implemented using SIP OPTIONS etc, which is a rather hea= vy and clumsy mechanism for that purpose. Regards, Christer = -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] = Sent: 25. kes=E4kuuta 2008 22:34 To: Markus.Isomaki@nokia.com; john.elwell@siemens.com; drage@alcatel-lucent= .com; sip@ietf.org Cc: Christer Holmberg Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Yes I am of that same opinion - that any real "IP-PBX" or whatever big enou= gh NOT to be doing Registration, and to instead do static provisioning or D= NS, would be given a static hole/DMZ address in their firewall/NAT. But so= me of my customers have told me otherwise. (interestingly mostly in APAC re= gion) There's also some concern that while a static entry is there for inbo= und TCP connections, the PBX creates outbound ones to the service provider = which are ephemeral port sources and need to live for very long durations (= though why they can't just do TCP keepalive is beyond me, but I'm no expert= ). But anyway, the big issue we've seen is that we need both the PBX and the s= ervice provider box to detect failure before an active call/request attempt= is made; to trigger alternate route selection without waiting for transpor= t failure, and as a method to detect liveness again and revert. Today that= 's almost exclusively done with Options requests as far as I've seen, and l= ots of people don't seem to like that. -hadriel > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Wednesday, June 25, 2008 3:11 PM > To: john.elwell@siemens.com; Hadriel Kaplan; drage@alcatel-lucent.com; = > sip@ietf.org > Cc: christer.holmberg@ericsson.com > Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = > use case > > Hi, > > I'm a bit sceptical about the need for keep-alives between proxies. It = > is of course entirely possible that an enterprise PBX is connected to = > (or peering with) a service provider proxy through a NAT and/or a = > firewall. However, wouldn't such a NAT or firewall be under the = > administration of either the enterprise itself or its ISP (who quite = > often would be the SIP service provider), and the required port = > forwardings or firewall rules could be set through administration. = > This means that there would not be need for keepalive traffic to = > implicitely keep the mapping/pinhole open. > > Or are there really deployment cases where there are SIP PBXs behind = > unadministrated NATs or firewalls? > > Wouldn't we then need keepalives for SMTP as well, or how has the = > e-mail infrastructure managed to solve this problem? > > Markus > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 14:39:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9163A6925; Wed, 25 Jun 2008 14:39:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C053B3A6925 for ; Wed, 25 Jun 2008 14:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Vfhy5FlqZjOr for ; Wed, 25 Jun 2008 14:39:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 543C03A686B for ; Wed, 25 Jun 2008 14:39:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 69480203A4; Wed, 25 Jun 2008 23:39:58 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-b3-4862bb2e2f99 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 412AB20587; Wed, 25 Jun 2008 23:39:58 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 23:35:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 23:35:17 +0200 Message-ID: In-Reply-To: <4862A324.6020703@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case thread-index: AcjW/cSu2KSbTZwLQeamP9HSqLQIuwADXZRw References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "Hadriel Kaplan" X-OriginalArrivalTime: 25 Jun 2008 21:35:18.0213 (UTC) FILETIME=[5CD4EF50:01C8D70B] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, drage@alcatel-lucent.com, john.elwell@siemens.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, So, you are proposing that each element should be a B2BUA, and both element= s then register towards each other and use Outbound??? Regards, Christer = -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = Sent: 25. kes=E4kuuta 2008 22:57 To: Hadriel Kaplan Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; drage@alcatel-lucent= .com; sip@ietf.org; Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Hadriel, Markus, Instead of standardizing keep-alives between proxies, how about we define a= "virtual UA" on each element (similar to the one described in RFC3261 section 16.7 point 6) to be used to provide this functionality? = (using existing outbound functionality, perhaps both ways) Regards, Jeroen Hadriel Kaplan wrote: > Yes I am of that same opinion - that any real "IP-PBX" or whatever big = > enough NOT to be doing Registration, and to instead do static provisionin= g or DNS, would be given a static hole/DMZ address in their firewall/NAT. = But some of my customers have told me otherwise. (interestingly mostly in A= PAC region) There's also some concern that while a static entry is there fo= r inbound TCP connections, the PBX creates outbound ones to the service pro= vider which are ephemeral port sources and need to live for very long durat= ions (though why they can't just do TCP keepalive is beyond me, but I'm no = expert). > > But anyway, the big issue we've seen is that we need both the PBX and the= service provider box to detect failure before an active call/request attem= pt is made; to trigger alternate route selection without waiting for transp= ort failure, and as a method to detect liveness again and revert. Today th= at's almost exclusively done with Options requests as far as I've seen, and= lots of people don't seem to like that. > > -hadriel > > > = >> -----Original Message----- >> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >> Sent: Wednesday, June 25, 2008 3:11 PM >> To: john.elwell@siemens.com; Hadriel Kaplan; = >> drage@alcatel-lucent.com; sip@ietf.org >> Cc: christer.holmberg@ericsson.com >> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >> use case >> >> Hi, >> >> I'm a bit sceptical about the need for keep-alives between proxies. = >> It is of course entirely possible that an enterprise PBX is connected = >> to (or peering with) a service provider proxy through a NAT and/or a = >> firewall. However, wouldn't such a NAT or firewall be under the = >> administration of either the enterprise itself or its ISP (who quite = >> often would be the SIP service provider), and the required port = >> forwardings or firewall rules could be set through administration. = >> This means that there would not be need for keepalive traffic to = >> implicitely keep the mapping/pinhole open. >> >> Or are there really deployment cases where there are SIP PBXs behind = >> unadministrated NATs or firewalls? >> >> Wouldn't we then need keepalives for SMTP as well, or how has the = >> e-mail infrastructure managed to solve this problem? >> >> Markus >> >> = > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From cacqaaaaaenaxnwq@wegnohotone.b.tep1.com Wed Jun 25 14:40:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE033A6817; Wed, 25 Jun 2008 14:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.371 X-Spam-Level: X-Spam-Status: No, score=-54.371 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 Owy82PWZB78O; Wed, 25 Jun 2008 14:40:45 -0700 (PDT) Received: from 77-102-20-105.cable.ubr06.donc.blueyonder.co.uk (77-102-20-105.cable.ubr06.donc.blueyonder.co.uk [77.102.20.105]) by core3.amsl.com (Postfix) with SMTP id AD0403A6A1C; Wed, 25 Jun 2008 14:40:28 -0700 (PDT) X-Originating-IP: 0.253.148.176 by smtp.77.102.20.105; Wed, 25 Jun 2008 17:40:32 -0500 Message-ID: From: "Arturo Gonzalez" Reply-To: "Arturo Gonzalez" To: send-archive@ietf.org Subject: Superior replica watches for you Date: Wed, 25 Jun 2008 17:40:32 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://suxiwonitaf52.blogspot.com/ From sip-bounces@ietf.org Wed Jun 25 14:55:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34123A686B; Wed, 25 Jun 2008 14:55:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751503A686B for ; Wed, 25 Jun 2008 14:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVhkUl+CSNs8 for ; Wed, 25 Jun 2008 14:55:53 -0700 (PDT) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by core3.amsl.com (Postfix) with ESMTP id BD73A3A680C for ; Wed, 25 Jun 2008 14:55:51 -0700 (PDT) Received: (qmail 27716 invoked by uid 0); 25 Jun 2008 21:55:51 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Jun 2008 21:55:51 -0000 Message-ID: <4862BEE4.502@zonnet.nl> Date: Wed, 25 Jun 2008 23:55:48 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> In-Reply-To: Cc: sip@ietf.org, drage@alcatel-lucent.com, john.elwell@siemens.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org No, not a B2BUA. Each element would have a virtual UA function "in = parallel" to its regular function (e.g. being a proxy). And indeed, one = way to implement this would be to keep either one (one way) or two = (opposite ways) flows active between them. Like so: |-----------| |-----------| | Proxy | | Proxy | |-----------| |-----------| | UA | <---------->| UA | |-----------| |-----------| Each "UA" would implement both a simple registrar and a UAC performing = registration. It could also be setup asymmetrically, with the (smaller) = IP-PBX doing a single registration towards the (bigger) Service provider = network. Registration expiry would denote a loss of connectivity. Regards, Jeroen Christer Holmberg wrote: > Hi, > > So, you are proposing that each element should be a B2BUA, and both eleme= nts then register towards each other and use Outbound??? > > Regards, > > Christer = > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = > Sent: 25. kes=E4kuuta 2008 22:57 > To: Hadriel Kaplan > Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; drage@alcatel-luce= nt.com; sip@ietf.org; Christer Holmberg > Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use c= ase > > Hadriel, Markus, > > Instead of standardizing keep-alives between proxies, how about we define= a "virtual UA" on each element (similar to the one described in > RFC3261 section 16.7 point 6) to be used to provide this functionality? = > (using existing outbound functionality, perhaps both ways) > > Regards, > Jeroen > > Hadriel Kaplan wrote: > = >> Yes I am of that same opinion - that any real "IP-PBX" or whatever big = >> enough NOT to be doing Registration, and to instead do static provisioni= ng or DNS, would be given a static hole/DMZ address in their firewall/NAT. = But some of my customers have told me otherwise. (interestingly mostly in = APAC region) There's also some concern that while a static entry is there f= or inbound TCP connections, the PBX creates outbound ones to the service pr= ovider which are ephemeral port sources and need to live for very long dura= tions (though why they can't just do TCP keepalive is beyond me, but I'm no= expert). >> >> But anyway, the big issue we've seen is that we need both the PBX and th= e service provider box to detect failure before an active call/request atte= mpt is made; to trigger alternate route selection without waiting for trans= port failure, and as a method to detect liveness again and revert. Today t= hat's almost exclusively done with Options requests as far as I've seen, an= d lots of people don't seem to like that. >> >> -hadriel >> >> >> = >> = >>> -----Original Message----- >>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>> Sent: Wednesday, June 25, 2008 3:11 PM >>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>> drage@alcatel-lucent.com; sip@ietf.org >>> Cc: christer.holmberg@ericsson.com >>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>> use case >>> >>> Hi, >>> >>> I'm a bit sceptical about the need for keep-alives between proxies. = >>> It is of course entirely possible that an enterprise PBX is connected = >>> to (or peering with) a service provider proxy through a NAT and/or a = >>> firewall. However, wouldn't such a NAT or firewall be under the = >>> administration of either the enterprise itself or its ISP (who quite = >>> often would be the SIP service provider), and the required port = >>> forwardings or firewall rules could be set through administration. = >>> This means that there would not be need for keepalive traffic to = >>> implicitely keep the mapping/pinhole open. >>> >>> Or are there really deployment cases where there are SIP PBXs behind = >>> unadministrated NATs or firewalls? >>> >>> Wouldn't we then need keepalives for SMTP as well, or how has the = >>> e-mail infrastructure managed to solve this problem? >>> >>> Markus >>> >>> = >>> = >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip Use = >> sipping@ietf.org for new developments on the application of sip >> >> = >> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 21:02:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46343A6841; Wed, 25 Jun 2008 21:02:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D0B3A681C for ; Wed, 25 Jun 2008 21:02:55 -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 8NDUq7nGM5LT for ; Wed, 25 Jun 2008 21:02:54 -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 CB7B83A67FC for ; Wed, 25 Jun 2008 21:02:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,706,1204520400"; d="scan'208";a="12279510" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Jun 2008 00:02:56 -0400 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 m5Q42u5J008636; Thu, 26 Jun 2008 00:02:56 -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.13.8) with ESMTP id m5Q42uBd004745; Thu, 26 Jun 2008 04:02:56 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 00:02:55 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 00:02:54 -0400 Message-ID: In-Reply-To: <4862BEE4.502@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Thread-Index: AcjXDlB43EhLW0Q8QMSXW9rmugWAtgAMm2WQ From: "Sanjay Sinha (sanjsinh)" To: "Jeroen van Bemmel" , "Christer Holmberg" X-OriginalArrivalTime: 26 Jun 2008 04:02:55.0878 (UTC) FILETIME=[837AFA60:01C8D741] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5885; t=1214452976; x=1215316976; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Progress=20draft-holmberg-sip-k eep=3A=20proxy-to-proxy=20use=20case |Sender:=20 |To:=20=22Jeroen=20van=20Bemmel=22=20,=0 A=20=20=20=20=20=20=20=20=22Christer=20Holmberg=22=20; bh=7Dk34J8TNA8c6lR0r6xxe0PKRT9jhNBSNriYPvaq+bE=; b=nyxlH80vOqXVYcxsVup57thWzQpwCTrefuwVF/rXCC3emamLnklc27qQqM 5EfJDqafSng6GeU2NsTcQEXWk3pNr6nOgGVREuZlBb3B1CXuSHeWay5fg5dA 3EGTnQhPeA; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, john.elwell@siemens.com, drage@alcatel-lucent.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In the asymmetric case, if the registration is established with a long dura= tion, and for some reason if IP-PBX crashes before the registration expires= , then SP n/w will not know about it until the registration expires, or it = tries to send a request to that PBX. If the registration interval is short, then this becomes similar to using s= hort registration intervals to keep nat bindings open. Sanjay >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = >Behalf Of Jeroen van Bemmel >Sent: Wednesday, June 25, 2008 5:56 PM >To: Christer Holmberg >Cc: sip@ietf.org; drage@alcatel-lucent.com; = >john.elwell@siemens.com; Markus.Isomaki@nokia.com >Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = >proxy-to-proxy use case > >No, not a B2BUA. Each element would have a virtual UA function = >"in parallel" to its regular function (e.g. being a proxy). = >And indeed, one way to implement this would be to keep either = >one (one way) or two (opposite ways) flows active between them. > >Like so: > >|-----------| |-----------| >| Proxy | | Proxy | >|-----------| |-----------| >| UA | <---------->| UA | >|-----------| |-----------| > >Each "UA" would implement both a simple registrar and a UAC = >performing registration. It could also be setup = >asymmetrically, with the (smaller) IP-PBX doing a single = >registration towards the (bigger) Service provider network. = >Registration expiry would denote a loss of connectivity. > >Regards, >Jeroen > > >Christer Holmberg wrote: >> Hi, >> >> So, you are proposing that each element should be a B2BUA, = >and both elements then register towards each other and use Outbound??? >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 25. kes=E4kuuta 2008 22:57 >> To: Hadriel Kaplan >> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; = >> drage@alcatel-lucent.com; sip@ietf.org; Christer Holmberg >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >> use case >> >> Hadriel, Markus, >> >> Instead of standardizing keep-alives between proxies, how about we = >> define a "virtual UA" on each element (similar to the one = >described in >> RFC3261 section 16.7 point 6) to be used to provide this = >functionality? = >> (using existing outbound functionality, perhaps both ways) >> >> Regards, >> Jeroen >> >> Hadriel Kaplan wrote: >> = >>> Yes I am of that same opinion - that any real "IP-PBX" or whatever = >>> big enough NOT to be doing Registration, and to instead do = >static provisioning or DNS, would be given a static hole/DMZ = >address in their firewall/NAT. But some of my customers have = >told me otherwise. (interestingly mostly in APAC region) = >There's also some concern that while a static entry is there = >for inbound TCP connections, the PBX creates outbound ones to = >the service provider which are ephemeral port sources and need = >to live for very long durations (though why they can't just do = >TCP keepalive is beyond me, but I'm no expert). >>> >>> But anyway, the big issue we've seen is that we need both = >the PBX and the service provider box to detect failure before = >an active call/request attempt is made; to trigger alternate = >route selection without waiting for transport failure, and as = >a method to detect liveness again and revert. Today that's = >almost exclusively done with Options requests as far as I've = >seen, and lots of people don't seem to like that. >>> >>> -hadriel >>> >>> >>> = >>> = >>>> -----Original Message----- >>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>> drage@alcatel-lucent.com; sip@ietf.org >>>> Cc: christer.holmberg@ericsson.com >>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >proxy-to-proxy = >>>> use case >>>> >>>> Hi, >>>> >>>> I'm a bit sceptical about the need for keep-alives between = >proxies. = >>>> It is of course entirely possible that an enterprise PBX is = >>>> connected to (or peering with) a service provider proxy through a = >>>> NAT and/or a firewall. However, wouldn't such a NAT or firewall be = >>>> under the administration of either the enterprise itself = >or its ISP = >>>> (who quite often would be the SIP service provider), and the = >>>> required port forwardings or firewall rules could be set = >through administration. >>>> This means that there would not be need for keepalive traffic to = >>>> implicitely keep the mapping/pinhole open. >>>> >>>> Or are there really deployment cases where there are SIP = >PBXs behind = >>>> unadministrated NATs or firewalls? >>>> >>>> Wouldn't we then need keepalives for SMTP as well, or how has the = >>>> e-mail infrastructure managed to solve this problem? >>>> >>>> Markus >>>> >>>> = >>>> = >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use = >>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>> sipping@ietf.org for new developments on the application of sip >>> >>> = >>> = >> >> = >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use = >sip-implementors@cs.columbia.edu for questions on current sip = >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 22:14:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69013A68DB; Wed, 25 Jun 2008 22:14:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056A828B797 for ; Wed, 25 Jun 2008 22:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 6QfkTlMTD+Xg for ; Wed, 25 Jun 2008 22:14:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 327D83A6810 for ; Wed, 25 Jun 2008 22:14:51 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5Q5EoFE030954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Jun 2008 00:14:52 -0500 Message-Id: <6E8D475D-42D1-462D-A937-DFB19170DEFF@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <05b101c8d738$e62e17e0$b28a47a0$@us> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 26 Jun 2008 00:14:45 -0500 References: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> <05b101c8d738$e62e17e0$b28a47a0$@us> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org Subject: Re: [Sip] Second draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 25, 2008, at 10:00 PM, Richard Shockey wrote: > Yea .. RETIRE is the right name since you guys are all going to RETIRE > before you get any consensus on what the solution is. The first SIP SAML draft is getting close to pub-ready, and I think we can fix RFC 4474 with a small and discrete set of changes that have already been proposed in a draft. It is very close to right, just a little bit off because of Badness in our Networks. > > Or you are all going to RETIRE to Geneva to figure this out etc... One of our dear friends has suggested to me (rather frequently) that all SIP related work should be ceded to the ITU, as it is now clearly a carrier-centric telephony protocol based on the assumption of a "smart network" and "crippled endpoints". Besides, Geneva is nice this time of year. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 22:57:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8160F28B23E; Wed, 25 Jun 2008 22:57:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E47228B23E for ; Wed, 25 Jun 2008 22:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 29pHVKz03NA7 for ; Wed, 25 Jun 2008 22:57:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E16B23A68DB for ; Wed, 25 Jun 2008 22:57:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 26 Jun 2008 01:56:49 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 26 Jun 2008 01:56:49 -0400 From: Hadriel Kaplan To: Jeroen van Bemmel , Christer Holmberg Date: Thu, 26 Jun 2008 01:56:37 -0400 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Thread-Index: AcjXDiBdbf8ckf6MTF2JnawfZYoe2QAOeZBA Message-ID: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> In-Reply-To: <4862BEE4.502@zonnet.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "drage@alcatel-lucent.com" , "john.elwell@siemens.com" , "Markus.Isomaki@nokia.com" Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hey Jeroen, I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now TISP= AN, make use of a REGISTER for an IP-PBX to register a whole set of AoR's t= o be routed to. For those devices that need that ability, it makes sense t= o use outbound of course, and its inherent keepalive, regardless of being b= ehind a NAT or not. And I don't think Christer's suggesting otherwise. But for IP-PBX's or proxies which do not themselves represent an AoR target= of requests, or do not represent one in the domain of the device they want= to perform keepalive with, why would we want to make them add such registr= ation logic? What would be the gain over just simply sending OPTIONS at th= at point? The beauty of a STUN or double-CRLF keepalive is, in my mind: it's trivial = to construct, trivial to parse, very small and fixed size, can be separated= or handled at a lower layer, explicit in its use, and does not get stopped= by a SIP-layer overload control. In short: it's a transport connection-la= yer keepalive, no more no less. And indicating it in the Via keeps it a ho= p-link thing, backwards-compatible, little or no provisioning, and with no = URI target addressing issues. -hadriel > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Wednesday, June 25, 2008 5:56 PM > To: Christer Holmberg > Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; john.elwell@siemens.com; > drage@alcatel-lucent.com; sip@ietf.org > Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use > case > > No, not a B2BUA. Each element would have a virtual UA function "in > parallel" to its regular function (e.g. being a proxy). And indeed, one > way to implement this would be to keep either one (one way) or two > (opposite ways) flows active between them. > > Like so: > > |-----------| |-----------| > | Proxy | | Proxy | > |-----------| |-----------| > | UA | <---------->| UA | > |-----------| |-----------| > > Each "UA" would implement both a simple registrar and a UAC performing > registration. It could also be setup asymmetrically, with the (smaller) > IP-PBX doing a single registration towards the (bigger) Service provider > network. Registration expiry would denote a loss of connectivity. > > Regards, > Jeroen > > > Christer Holmberg wrote: > > Hi, > > > > So, you are proposing that each element should be a B2BUA, and both > elements then register towards each other and use Outbound??? > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: 25. kes=E4kuuta 2008 22:57 > > To: Hadriel Kaplan > > Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; drage@alcatel- > lucent.com; sip@ietf.org; Christer Holmberg > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use > case > > > > Hadriel, Markus, > > > > Instead of standardizing keep-alives between proxies, how about we > define a "virtual UA" on each element (similar to the one described in > > RFC3261 section 16.7 point 6) to be used to provide this functionality? > > (using existing outbound functionality, perhaps both ways) > > > > Regards, > > Jeroen > > > > Hadriel Kaplan wrote: > > > >> Yes I am of that same opinion - that any real "IP-PBX" or whatever big > >> enough NOT to be doing Registration, and to instead do static > provisioning or DNS, would be given a static hole/DMZ address in their > firewall/NAT. But some of my customers have told me otherwise. > (interestingly mostly in APAC region) There's also some concern that while > a static entry is there for inbound TCP connections, the PBX creates > outbound ones to the service provider which are ephemeral port sources and > need to live for very long durations (though why they can't just do TCP > keepalive is beyond me, but I'm no expert). > >> > >> But anyway, the big issue we've seen is that we need both the PBX and > the service provider box to detect failure before an active call/request > attempt is made; to trigger alternate route selection without waiting for > transport failure, and as a method to detect liveness again and revert. > Today that's almost exclusively done with Options requests as far as I've > seen, and lots of people don't seem to like that. > >> > >> -hadriel > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > >>> Sent: Wednesday, June 25, 2008 3:11 PM > >>> To: john.elwell@siemens.com; Hadriel Kaplan; > >>> drage@alcatel-lucent.com; sip@ietf.org > >>> Cc: christer.holmberg@ericsson.com > >>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy > >>> use case > >>> > >>> Hi, > >>> > >>> I'm a bit sceptical about the need for keep-alives between proxies. > >>> It is of course entirely possible that an enterprise PBX is connected > >>> to (or peering with) a service provider proxy through a NAT and/or a > >>> firewall. However, wouldn't such a NAT or firewall be under the > >>> administration of either the enterprise itself or its ISP (who quite > >>> often would be the SIP service provider), and the required port > >>> forwardings or firewall rules could be set through administration. > >>> This means that there would not be need for keepalive traffic to > >>> implicitely keep the mapping/pinhole open. > >>> > >>> Or are there really deployment cases where there are SIP PBXs behind > >>> unadministrated NATs or firewalls? > >>> > >>> Wouldn't we then need keepalives for SMTP as well, or how has the > >>> e-mail infrastructure managed to solve this problem? > >>> > >>> Markus > >>> > >>> > >>> > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip Use > >> sipping@ietf.org for new developments on the application of sip > >> > >> > >> > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 23:33:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5943A6949; Wed, 25 Jun 2008 23:33:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD3E3A6949 for ; Wed, 25 Jun 2008 23:33:45 -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 Nk0LXvu-Xt1e for ; Wed, 25 Jun 2008 23:33:45 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id EF6A83A6919 for ; Wed, 25 Jun 2008 23:33:44 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3533711wfd.31 for ; Wed, 25 Jun 2008 23:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=64LWE8rtTY00Ozs1ve9PaCXRh3vqadys/7mrPzLJ1lA=; b=Kh8YCNZWvy6Bax3Qn1mGYRshJGU6D+K6tLW1teQdRvh+2UL1ZyDq/v4lnWREYR+S8/ I+DCLAiBk4B86E52CdW1mURA0/HA/4yttVmwGz9wUF5BYeMVBJ7IOINla1/Bw8C9CEoE PSsiY5erPyb3jp8ZllnISs1wj/onIemoisKmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=fBNkqwsg0JKh6PWxyES4OPg6HDa4Y5nzMXg8hh3L/JFgoBcCmGeO+lFWhEhWCa/g0b Lep30RP0Qj4qxsYD71RF/6WQyysql0iKY6c2K0TxbuNNIOG6kjJJ7DHpQER3hyO6YIaZ Srsgi+aVyoRLHdigCw1qQCgAMKEBDV8qHR8H0= Received: by 10.143.33.12 with SMTP id l12mr7368263wfj.272.1214462027733; Wed, 25 Jun 2008 23:33:47 -0700 (PDT) Received: by 10.143.17.4 with HTTP; Wed, 25 Jun 2008 23:33:47 -0700 (PDT) Message-ID: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> Date: Thu, 26 Jun 2008 12:03:47 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] can SDP contain 2 'M' lines X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1950589894==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1950589894== Content-Type: multipart/alternative; boundary="----=_Part_1206_11289861.1214462027706" ------=_Part_1206_11289861.1214462027706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, In SDP can we have two 'M' lines for re-INVITE i.e. for call hold. if yes what is RFC / draft Any response is highly appreciated Regards Sudhir ------=_Part_1206_11289861.1214462027706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

In SDP can we have two 'M' lines for re-INVITE i.e. for call hold.

if yes what is RFC / draft

Any response is highly appreciated

Regards
Sudhir ------=_Part_1206_11289861.1214462027706-- --===============1950589894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1950589894==-- From sip-bounces@ietf.org Wed Jun 25 23:42:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1DD83A69AF; Wed, 25 Jun 2008 23:42:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6805D3A69F7 for ; Wed, 25 Jun 2008 23:42:16 -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=[BAYES_00=-2.599, HELO_EQ_DE=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 5IfY7Wi0Y9Z7 for ; Wed, 25 Jun 2008 23:42:15 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id C94463A67A4 for ; Wed, 25 Jun 2008 23:42:14 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m5Q6gDQW011529; Thu, 26 Jun 2008 08:42:16 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m5Q6gDJk004498; Thu, 26 Jun 2008 08:42:13 +0200 Received: from MCHP7IEA.ww902.siemens.net ([139.25.131.145]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 08:42:12 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Jun 2008 08:42:12 +0200 Message-ID: In-Reply-To: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Second draft, RETIRE Charter Thread-Index: AcjW3mWKMupDP+8DTlazWWaK/RG3GwAeMIuA References: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> From: "Fries, Steffen (CT)" To: "Dean Willis" , X-OriginalArrivalTime: 26 Jun 2008 06:42:12.0832 (UTC) FILETIME=[C3DE6E00:01C8D757] Subject: Re: [Sip] Second draft, RETIRE Charter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Dean, the revised charter sounds good. I'm not sure I like the agronym as it somehow sounds that it will take longer to solve that problem. But tht is just naming, the content is more important ;-) Ciao Steffen PS: How about RISE: Roles and Identities in SIP Environments? > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Wednesday, June 25, 2008 6:13 PM > To: sip@ietf.org > Subject: [Sip] Second draft, RETIRE Charter > > I've revised the proposed charter fora RETIRE working group > based on list comments. This is still a very early concept, > and the formation of such a working group is contingent on a > great many things that are outside of my control. > > > -------- > > > The "REal Time Identity and Role Expression" (RETIRE) > Working Group's purpose is to standardize the expression and > assertion of identity and roles needed for real-time > communications with the IETF's Realtime Applications > Infrastructure (RAI) area protocols, primarily the Session > Initiation Protocol (SIP) and others used in conjunction with SIP. > > By "Identity", we mean authenticated addresses of record (as > defined in RFC 4474 "Enhancements for Authenticated Identity > Management in the Session Initiation Protocol". RFC 4474 > provides a means by which a SIP server may vouch for the > "From" address of a request transiting that server. It > further provides a cryptographic mechanism for testing the > source of the assertion. In the typical case, this mechanism > is dependent on the same Public Key Infrastructure that > supports secure HTTP services. Since RFC 4474 provides only > authentication of the source of SIP request messages and it > is also important to determine the identity of the sender of > responses, RFC 4916 "Connected Identity in the Session > Initiation Protocol" provides authenticated identity in an > ongoing SIP dialog by applying RFC 4474 to requests in the > reverse direction. While adequate for some scenarios, this > mechanism is not useful for SIP interactions having a single > non-dialog transaction, such as MESSAGE requests. RFC 4474 > suffers additional limitations relating to its use with E.164 > numbers, gateways, session border controllers, and > back-to-back user agents. > > By "Role", we mean aspects of a a system user that are > related identity, but more dynamic in nature. For example, > Alice might delegate her calls to Bob. A calling party, > expecting to reach Alice but reaching Bob, needs to know that > this is a reasonable thing and what Bob's role in relation to > Alice is. This problem is in general referred to as the > "unanticipated respondent problem", and it has impacts both > at the level of user expectations and key management. > Proposals for fixing it have included deprecation of proxy > retargeting and the use of a new SIP provisional response to > inform the calling party about the retargeting operation. > > Security Assertion Markup Language (SAML) is an XML-based > standard for exchanging authentication and authorization data > between security domains, that is, between an identity > provider (a producer of > assertions) and a service provider (a consumer of > assertions). SAML is a product of the OASIS Security Services > Technical Committee. The SIP working group worked for several > years on applying SAML to SIP with mixed results, but the > technique appears to have great promise. > > > The initial deliverables of the RETIRE working group are: > > 1) A standards-track revision of RFC 4474 that resolves its > limitations with respect to E.164 numbers, gateways, session > border controllers, and back-to-back user agents. This > revision will also address the use of Authenticated Identity > Management in conjunction with SIP response messages. It may > also be necessary to document the impact of such changes, if > any, on the DTLS-SRTP framework. > > 2) Specify a solution (or set of solutions) for the > Unanticipated Respondent Problem in SIP. > > 3) Guidelines for the use of E.164 numbers as SIP identifiers. > > 4) Guidelines for the use of SAML with SIP for the purposes > of expressing identity and role, specifically in the contexts > of #1, #2 and #3 above. > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 25 23:49:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3E73A6919; Wed, 25 Jun 2008 23:49:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D9A3A6919 for ; Wed, 25 Jun 2008 23:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU06c9eovzyJ for ; Wed, 25 Jun 2008 23:49:43 -0700 (PDT) Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by core3.amsl.com (Postfix) with ESMTP id 566C23A68E4 for ; Wed, 25 Jun 2008 23:49:43 -0700 (PDT) Received: (qmail 24565 invoked by uid 0); 26 Jun 2008 06:49:42 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jun 2008 06:49:42 -0000 Message-ID: <48633C02.2070703@zonnet.nl> Date: Thu, 26 Jun 2008 08:49:38 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hadriel Kaplan References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> In-Reply-To: Cc: "sip@ietf.org" , "drage@alcatel-lucent.com" , "Markus.Isomaki@nokia.com" , "john.elwell@siemens.com" , Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, I did not intend to suggest to use the registration interval timer for = keep-alive, of course all the regular flow keep-alive mechanisms of = outbound could be used. The benefit is that we would reuse the efforts put in outbound, instead = of inventing yet another, only marginally different, mechanism for each = specific case. From the sending element point of view, sending a = REGISTER isn't very different from sending an OPTIONS; subsequent = keep-alives can then become STUN or double CRLF, until the registration = needs to be refreshed. Using REGISTER instead of OPTIONS also provides the means to use the = standard authentication mechanisms, besides reusing outbound (and = there's a few other reusable things, like Path headers, but let's keep = it simple for the moment) Regards, Jeroen Hadriel Kaplan wrote: > Hey Jeroen, > I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now TI= SPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR's= to be routed to. For those devices that need that ability, it makes sense= to use outbound of course, and its inherent keepalive, regardless of being= behind a NAT or not. And I don't think Christer's suggesting otherwise. > > But for IP-PBX's or proxies which do not themselves represent an AoR targ= et of requests, or do not represent one in the domain of the device they wa= nt to perform keepalive with, why would we want to make them add such regis= tration logic? What would be the gain over just simply sending OPTIONS at = that point? > > The beauty of a STUN or double-CRLF keepalive is, in my mind: it's trivia= l to construct, trivial to parse, very small and fixed size, can be separat= ed or handled at a lower layer, explicit in its use, and does not get stopp= ed by a SIP-layer overload control. In short: it's a transport connection-= layer keepalive, no more no less. And indicating it in the Via keeps it a = hop-link thing, backwards-compatible, little or no provisioning, and with n= o URI target addressing issues. > > -hadriel > > = >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Wednesday, June 25, 2008 5:56 PM >> To: Christer Holmberg >> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; john.elwell@siemens.com; >> drage@alcatel-lucent.com; sip@ietf.org >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use >> case >> >> No, not a B2BUA. Each element would have a virtual UA function "in >> parallel" to its regular function (e.g. being a proxy). And indeed, one >> way to implement this would be to keep either one (one way) or two >> (opposite ways) flows active between them. >> >> Like so: >> >> |-----------| |-----------| >> | Proxy | | Proxy | >> |-----------| |-----------| >> | UA | <---------->| UA | >> |-----------| |-----------| >> >> Each "UA" would implement both a simple registrar and a UAC performing >> registration. It could also be setup asymmetrically, with the (smaller) >> IP-PBX doing a single registration towards the (bigger) Service provider >> network. Registration expiry would denote a loss of connectivity. >> >> Regards, >> Jeroen >> >> >> Christer Holmberg wrote: >> = >>> Hi, >>> >>> So, you are proposing that each element should be a B2BUA, and both >>> = >> elements then register towards each other and use Outbound??? >> = >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>> Sent: 25. kes=E4kuuta 2008 22:57 >>> To: Hadriel Kaplan >>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; drage@alcatel- >>> = >> lucent.com; sip@ietf.org; Christer Holmberg >> = >>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use >>> = >> case >> = >>> Hadriel, Markus, >>> >>> Instead of standardizing keep-alives between proxies, how about we >>> = >> define a "virtual UA" on each element (similar to the one described in >> = >>> RFC3261 section 16.7 point 6) to be used to provide this functionality? >>> (using existing outbound functionality, perhaps both ways) >>> >>> Regards, >>> Jeroen >>> >>> Hadriel Kaplan wrote: >>> >>> = >>>> Yes I am of that same opinion - that any real "IP-PBX" or whatever big >>>> enough NOT to be doing Registration, and to instead do static >>>> = >> provisioning or DNS, would be given a static hole/DMZ address in their >> firewall/NAT. But some of my customers have told me otherwise. >> (interestingly mostly in APAC region) There's also some concern that whi= le >> a static entry is there for inbound TCP connections, the PBX creates >> outbound ones to the service provider which are ephemeral port sources a= nd >> need to live for very long durations (though why they can't just do TCP >> keepalive is beyond me, but I'm no expert). >> = >>>> But anyway, the big issue we've seen is that we need both the PBX and >>>> = >> the service provider box to detect failure before an active call/request >> attempt is made; to trigger alternate route selection without waiting for >> transport failure, and as a method to detect liveness again and revert. >> Today that's almost exclusively done with Options requests as far as I've >> seen, and lots of people don't seem to like that. >> = >>>> -hadriel >>>> >>>> >>>> >>>> >>>> = >>>>> -----Original Message----- >>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>> To: john.elwell@siemens.com; Hadriel Kaplan; >>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>> Cc: christer.holmberg@ericsson.com >>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy >>>>> use case >>>>> >>>>> Hi, >>>>> >>>>> I'm a bit sceptical about the need for keep-alives between proxies. >>>>> It is of course entirely possible that an enterprise PBX is connected >>>>> to (or peering with) a service provider proxy through a NAT and/or a >>>>> firewall. However, wouldn't such a NAT or firewall be under the >>>>> administration of either the enterprise itself or its ISP (who quite >>>>> often would be the SIP service provider), and the required port >>>>> forwardings or firewall rules could be set through administration. >>>>> This means that there would not be need for keepalive traffic to >>>>> implicitely keep the mapping/pinhole open. >>>>> >>>>> Or are there really deployment cases where there are SIP PBXs behind >>>>> unadministrated NATs or firewalls? >>>>> >>>>> Wouldn't we then need keepalives for SMTP as well, or how has the >>>>> e-mail infrastructure managed to solve this problem? >>>>> >>>>> Markus >>>>> >>>>> >>>>> >>>>> = >>>> _______________________________________________ >>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>>> >>>> >>>> = >>> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 00:03:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8213A687A; Thu, 26 Jun 2008 00:03:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0153A681A for ; Thu, 26 Jun 2008 00:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 iyZ8+V9I1s2s for ; Thu, 26 Jun 2008 00:03:34 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2BFC63A67B7 for ; Thu, 26 Jun 2008 00:03:34 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K3200F4Y6A04G@siemenscomms.co.uk> for sip@ietf.org; Thu, 26 Jun 2008 08:03:36 +0100 (BST) Date: Thu, 26 Jun 2008 08:03:34 +0100 From: "Elwell, John" In-reply-to: <4862BEE4.502@zonnet.nl> To: Jeroen van Bemmel , Christer Holmberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E9EF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Thread-Index: AcjXDj2NYxM8DC9aREuKcZiE9iFAtgAS1/5w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> Cc: sip@ietf.org, drage@alcatel-lucent.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jeroen, Yes, this is effectively what you have when an IPPBX is required to registe= r with a service provider. But in that case, there might also be a need to = implement sip-outbound if there are unadministered NATs/firewalls in the wa= y. Indeed, sip-outbound would operate between a virtual UA on the IPPBX sid= e and a registrar on the service provider side. What I am interested in gaining from this discussion is whether there are p= roxy-to-proxy cases where sip-outbound is not appropriate but keep-alive (o= r heartbeat) is needed. John > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = > Sent: 25 June 2008 22:56 > To: Christer Holmberg > Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; Elwell, John; = > drage@alcatel-lucent.com; sip@ietf.org > Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = > proxy-to-proxy use case > = > No, not a B2BUA. Each element would have a virtual UA function "in = > parallel" to its regular function (e.g. being a proxy). And = > indeed, one = > way to implement this would be to keep either one (one way) or two = > (opposite ways) flows active between them. > = > Like so: > = > |-----------| |-----------| > | Proxy | | Proxy | > |-----------| |-----------| > | UA | <---------->| UA | > |-----------| |-----------| > = > Each "UA" would implement both a simple registrar and a UAC = > performing = > registration. It could also be setup asymmetrically, with the = > (smaller) = > IP-PBX doing a single registration towards the (bigger) = > Service provider = > network. Registration expiry would denote a loss of connectivity. > = > Regards, > Jeroen > = > = > Christer Holmberg wrote: > > Hi, > > > > So, you are proposing that each element should be a B2BUA, = > and both elements then register towards each other and use Outbound??? > > > > Regards, > > > > Christer = > > > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = > > Sent: 25. kes=E4kuuta 2008 22:57 > > To: Hadriel Kaplan > > Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; = > drage@alcatel-lucent.com; sip@ietf.org; Christer Holmberg > > Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = > proxy-to-proxy use case > > > > Hadriel, Markus, > > > > Instead of standardizing keep-alives between proxies, how = > about we define a "virtual UA" on each element (similar to = > the one described in > > RFC3261 section 16.7 point 6) to be used to provide this = > functionality? = > > (using existing outbound functionality, perhaps both ways) > > > > Regards, > > Jeroen > > > > Hadriel Kaplan wrote: > > = > >> Yes I am of that same opinion - that any real "IP-PBX" or = > whatever big = > >> enough NOT to be doing Registration, and to instead do = > static provisioning or DNS, would be given a static hole/DMZ = > address in their firewall/NAT. But some of my customers have = > told me otherwise. (interestingly mostly in APAC region) = > There's also some concern that while a static entry is there = > for inbound TCP connections, the PBX creates outbound ones to = > the service provider which are ephemeral port sources and = > need to live for very long durations (though why they can't = > just do TCP keepalive is beyond me, but I'm no expert). > >> > >> But anyway, the big issue we've seen is that we need both = > the PBX and the service provider box to detect failure before = > an active call/request attempt is made; to trigger alternate = > route selection without waiting for transport failure, and as = > a method to detect liveness again and revert. Today that's = > almost exclusively done with Options requests as far as I've = > seen, and lots of people don't seem to like that. > >> > >> -hadriel > >> > >> > >> = > >> = > >>> -----Original Message----- > >>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > >>> Sent: Wednesday, June 25, 2008 3:11 PM > >>> To: john.elwell@siemens.com; Hadriel Kaplan; = > >>> drage@alcatel-lucent.com; sip@ietf.org > >>> Cc: christer.holmberg@ericsson.com > >>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = > proxy-to-proxy = > >>> use case > >>> > >>> Hi, > >>> > >>> I'm a bit sceptical about the need for keep-alives = > between proxies. = > >>> It is of course entirely possible that an enterprise PBX = > is connected = > >>> to (or peering with) a service provider proxy through a = > NAT and/or a = > >>> firewall. However, wouldn't such a NAT or firewall be under the = > >>> administration of either the enterprise itself or its ISP = > (who quite = > >>> often would be the SIP service provider), and the required port = > >>> forwardings or firewall rules could be set through = > administration. = > >>> This means that there would not be need for keepalive traffic to = > >>> implicitely keep the mapping/pinhole open. > >>> > >>> Or are there really deployment cases where there are SIP = > PBXs behind = > >>> unadministrated NATs or firewalls? > >>> > >>> Wouldn't we then need keepalives for SMTP as well, or how has the = > >>> e-mail infrastructure managed to solve this problem? > >>> > >>> Markus > >>> > >>> = > >>> = > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use = > >> sip-implementors@cs.columbia.edu for questions on current sip Use = > >> sipping@ietf.org for new developments on the application of sip > >> > >> = > >> = > > > > = > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 00:03:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1207228C0F0; Thu, 26 Jun 2008 00:03:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FED428C0EF for ; Thu, 26 Jun 2008 00:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 XaGyzeFJrrXv for ; Thu, 26 Jun 2008 00:03:45 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C8E6528C0DE for ; Thu, 26 Jun 2008 00:03:44 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K3200F5E6AB4G@siemenscomms.co.uk> for sip@ietf.org; Thu, 26 Jun 2008 08:03:47 +0100 (BST) Date: Thu, 26 Jun 2008 08:03:45 +0100 From: "Elwell, John" In-reply-to: A To: "Sanjay Sinha (sanjsinh)" , Jeroen van Bemmel , Christer Holmberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6E9F0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Thread-Index: AcjXDlB43EhLW0Q8QMSXW9rmugWAtgAMm2WQAAZprvA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4862BEE4.502@zonnet.nl> A Cc: sip@ietf.org, drage@alcatel-lucent.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is what sip-outbound is for. John = > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] = > Sent: 26 June 2008 05:03 > To: Jeroen van Bemmel; Christer Holmberg > Cc: sip@ietf.org; drage@alcatel-lucent.com; Elwell, John; = > Markus.Isomaki@nokia.com > Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = > proxy-to-proxy use case > = > In the asymmetric case, if the registration is established = > with a long duration, and for some reason if IP-PBX crashes = > before the registration expires, then SP n/w will not know = > about it until the registration expires, or it tries to send = > a request to that PBX. > If the registration interval is short, then this becomes = > similar to using short registration intervals to keep nat = > bindings open. > = > Sanjay > = > >-----Original Message----- > >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = > >Behalf Of Jeroen van Bemmel > >Sent: Wednesday, June 25, 2008 5:56 PM > >To: Christer Holmberg > >Cc: sip@ietf.org; drage@alcatel-lucent.com; = > >john.elwell@siemens.com; Markus.Isomaki@nokia.com > >Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = > >proxy-to-proxy use case > > > >No, not a B2BUA. Each element would have a virtual UA function = > >"in parallel" to its regular function (e.g. being a proxy). = > >And indeed, one way to implement this would be to keep either = > >one (one way) or two (opposite ways) flows active between them. > > > >Like so: > > > >|-----------| |-----------| > >| Proxy | | Proxy | > >|-----------| |-----------| > >| UA | <---------->| UA | > >|-----------| |-----------| > > > >Each "UA" would implement both a simple registrar and a UAC = > >performing registration. It could also be setup = > >asymmetrically, with the (smaller) IP-PBX doing a single = > >registration towards the (bigger) Service provider network. = > >Registration expiry would denote a loss of connectivity. > > > >Regards, > >Jeroen > > > > > >Christer Holmberg wrote: > >> Hi, > >> > >> So, you are proposing that each element should be a B2BUA, = > >and both elements then register towards each other and use = > Outbound??? > >> > >> Regards, > >> > >> Christer > >> > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: 25. kes=E4kuuta 2008 22:57 > >> To: Hadriel Kaplan > >> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; = > >> drage@alcatel-lucent.com; sip@ietf.org; Christer Holmberg > >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = > proxy-to-proxy = > >> use case > >> > >> Hadriel, Markus, > >> > >> Instead of standardizing keep-alives between proxies, how about we = > >> define a "virtual UA" on each element (similar to the one = > >described in > >> RFC3261 section 16.7 point 6) to be used to provide this = > >functionality? = > >> (using existing outbound functionality, perhaps both ways) > >> > >> Regards, > >> Jeroen > >> > >> Hadriel Kaplan wrote: > >> = > >>> Yes I am of that same opinion - that any real "IP-PBX" or = > whatever = > >>> big enough NOT to be doing Registration, and to instead do = > >static provisioning or DNS, would be given a static hole/DMZ = > >address in their firewall/NAT. But some of my customers have = > >told me otherwise. (interestingly mostly in APAC region) = > >There's also some concern that while a static entry is there = > >for inbound TCP connections, the PBX creates outbound ones to = > >the service provider which are ephemeral port sources and need = > >to live for very long durations (though why they can't just do = > >TCP keepalive is beyond me, but I'm no expert). > >>> > >>> But anyway, the big issue we've seen is that we need both = > >the PBX and the service provider box to detect failure before = > >an active call/request attempt is made; to trigger alternate = > >route selection without waiting for transport failure, and as = > >a method to detect liveness again and revert. Today that's = > >almost exclusively done with Options requests as far as I've = > >seen, and lots of people don't seem to like that. > >>> > >>> -hadriel > >>> > >>> > >>> = > >>> = > >>>> -----Original Message----- > >>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > >>>> Sent: Wednesday, June 25, 2008 3:11 PM > >>>> To: john.elwell@siemens.com; Hadriel Kaplan; = > >>>> drage@alcatel-lucent.com; sip@ietf.org > >>>> Cc: christer.holmberg@ericsson.com > >>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = > >proxy-to-proxy = > >>>> use case > >>>> > >>>> Hi, > >>>> > >>>> I'm a bit sceptical about the need for keep-alives between = > >proxies. = > >>>> It is of course entirely possible that an enterprise PBX is = > >>>> connected to (or peering with) a service provider proxy = > through a = > >>>> NAT and/or a firewall. However, wouldn't such a NAT or = > firewall be = > >>>> under the administration of either the enterprise itself = > >or its ISP = > >>>> (who quite often would be the SIP service provider), and the = > >>>> required port forwardings or firewall rules could be set = > >through administration. > >>>> This means that there would not be need for keepalive traffic to = > >>>> implicitely keep the mapping/pinhole open. > >>>> > >>>> Or are there really deployment cases where there are SIP = > >PBXs behind = > >>>> unadministrated NATs or firewalls? > >>>> > >>>> Wouldn't we then need keepalives for SMTP as well, or = > how has the = > >>>> e-mail infrastructure managed to solve this problem? > >>>> > >>>> Markus > >>>> > >>>> = > >>>> = > >>> _______________________________________________ > >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use = > >>> sip-implementors@cs.columbia.edu for questions on current sip Use = > >>> sipping@ietf.org for new developments on the application of sip > >>> > >>> = > >>> = > >> > >> = > >_______________________________________________ > >Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use = > >sip-implementors@cs.columbia.edu for questions on current sip = > >Use sipping@ietf.org for new developments on the application of sip > > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 00:05:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEB33A681A; Thu, 26 Jun 2008 00:05:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06603A687A for ; Thu, 26 Jun 2008 00:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_81=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 Ztdz0Vb23LuA for ; Thu, 26 Jun 2008 00:05:48 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 115943A681A for ; Thu, 26 Jun 2008 00:05:48 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C3B9A208A9; Thu, 26 Jun 2008 09:05:49 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-99-48633fcd0e2b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D0DB204E0; Thu, 26 Jun 2008 09:05:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 09:06:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 09:06:16 +0200 Message-ID: In-Reply-To: <48633C02.2070703@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case thread-index: AcjXWOOq/g0w+GVORVWYZCKxY/Qu5wAAVluQ References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> <48633C02.2070703@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "Hadriel Kaplan" X-OriginalArrivalTime: 26 Jun 2008 07:06:18.0972 (UTC) FILETIME=[21D5E1C0:01C8D75B] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, drage@alcatel-lucent.com, john.elwell@siemens.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jeroen, I don't understand what benefit it would be to establish outbound registrat= ions between all SIP entities that want to use the keep-alive/heartbeat. Ye= s, we would "re-use an existing mechanism", but in my opinion it would real= ly be an overkill,a hack - and anything but keep-it-simple... Also, how would the proxies know which proxies it should establish registra= tions which? Also, it wouldn't work in the use-case with UEs that don't register. Regards, Christer -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = Sent: 26. kes=E4kuuta 2008 9:50 To: Hadriel Kaplan Cc: Christer Holmberg; Markus.Isomaki@nokia.com; john.elwell@siemens.com; d= rage@alcatel-lucent.com; sip@ietf.org Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Hadriel, I did not intend to suggest to use the registration interval timer for keep= -alive, of course all the regular flow keep-alive mechanisms of outbound co= uld be used. The benefit is that we would reuse the efforts put in outbound, instead of = inventing yet another, only marginally different, mechanism for each specif= ic case. From the sending element point of view, sending a REGISTER isn't v= ery different from sending an OPTIONS; subsequent keep-alives can then beco= me STUN or double CRLF, until the registration needs to be refreshed. Using REGISTER instead of OPTIONS also provides the means to use the standa= rd authentication mechanisms, besides reusing outbound (and there's a few o= ther reusable things, like Path headers, but let's keep it simple for the m= oment) Regards, Jeroen Hadriel Kaplan wrote: > Hey Jeroen, > I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now TI= SPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR's= to be routed to. For those devices that need that ability, it makes sense= to use outbound of course, and its inherent keepalive, regardless of being= behind a NAT or not. And I don't think Christer's suggesting otherwise. > > But for IP-PBX's or proxies which do not themselves represent an AoR targ= et of requests, or do not represent one in the domain of the device they wa= nt to perform keepalive with, why would we want to make them add such regis= tration logic? What would be the gain over just simply sending OPTIONS at = that point? > > The beauty of a STUN or double-CRLF keepalive is, in my mind: it's trivia= l to construct, trivial to parse, very small and fixed size, can be separat= ed or handled at a lower layer, explicit in its use, and does not get stopp= ed by a SIP-layer overload control. In short: it's a transport connection-= layer keepalive, no more no less. And indicating it in the Via keeps it a = hop-link thing, backwards-compatible, little or no provisioning, and with n= o URI target addressing issues. > > -hadriel > > = >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Wednesday, June 25, 2008 5:56 PM >> To: Christer Holmberg >> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; = >> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >> use case >> >> No, not a B2BUA. Each element would have a virtual UA function "in = >> parallel" to its regular function (e.g. being a proxy). And indeed, = >> one way to implement this would be to keep either one (one way) or = >> two (opposite ways) flows active between them. >> >> Like so: >> >> |-----------| |-----------| >> | Proxy | | Proxy | >> |-----------| |-----------| >> | UA | <---------->| UA | >> |-----------| |-----------| >> >> Each "UA" would implement both a simple registrar and a UAC = >> performing registration. It could also be setup asymmetrically, with = >> the (smaller) IP-PBX doing a single registration towards the (bigger) = >> Service provider network. Registration expiry would denote a loss of con= nectivity. >> >> Regards, >> Jeroen >> >> >> Christer Holmberg wrote: >> = >>> Hi, >>> >>> So, you are proposing that each element should be a B2BUA, and both >>> = >> elements then register towards each other and use Outbound??? >> = >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>> Sent: 25. kes=E4kuuta 2008 22:57 >>> To: Hadriel Kaplan >>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; = >>> drage@alcatel- >>> = >> lucent.com; sip@ietf.org; Christer Holmberg >> = >>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>> use >>> = >> case >> = >>> Hadriel, Markus, >>> >>> Instead of standardizing keep-alives between proxies, how about we >>> = >> define a "virtual UA" on each element (similar to the one described = >> in >> = >>> RFC3261 section 16.7 point 6) to be used to provide this functionality? >>> (using existing outbound functionality, perhaps both ways) >>> >>> Regards, >>> Jeroen >>> >>> Hadriel Kaplan wrote: >>> >>> = >>>> Yes I am of that same opinion - that any real "IP-PBX" or whatever = >>>> big enough NOT to be doing Registration, and to instead do static >>>> = >> provisioning or DNS, would be given a static hole/DMZ address in = >> their firewall/NAT. But some of my customers have told me otherwise. >> (interestingly mostly in APAC region) There's also some concern that = >> while a static entry is there for inbound TCP connections, the PBX = >> creates outbound ones to the service provider which are ephemeral = >> port sources and need to live for very long durations (though why = >> they can't just do TCP keepalive is beyond me, but I'm no expert). >> = >>>> But anyway, the big issue we've seen is that we need both the PBX = >>>> and >>>> = >> the service provider box to detect failure before an active = >> call/request attempt is made; to trigger alternate route selection = >> without waiting for transport failure, and as a method to detect livenes= s again and revert. >> Today that's almost exclusively done with Options requests as far as = >> I've seen, and lots of people don't seem to like that. >> = >>>> -hadriel >>>> >>>> >>>> >>>> >>>> = >>>>> -----Original Message----- >>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>> Cc: christer.holmberg@ericsson.com >>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >>>>> proxy-to-proxy use case >>>>> >>>>> Hi, >>>>> >>>>> I'm a bit sceptical about the need for keep-alives between proxies. >>>>> It is of course entirely possible that an enterprise PBX is = >>>>> connected to (or peering with) a service provider proxy through a = >>>>> NAT and/or a firewall. However, wouldn't such a NAT or firewall be = >>>>> under the administration of either the enterprise itself or its = >>>>> ISP (who quite often would be the SIP service provider), and the = >>>>> required port forwardings or firewall rules could be set through admi= nistration. >>>>> This means that there would not be need for keepalive traffic to = >>>>> implicitely keep the mapping/pinhole open. >>>>> >>>>> Or are there really deployment cases where there are SIP PBXs = >>>>> behind unadministrated NATs or firewalls? >>>>> >>>>> Wouldn't we then need keepalives for SMTP as well, or how has the = >>>>> e-mail infrastructure managed to solve this problem? >>>>> >>>>> Markus >>>>> >>>>> >>>>> >>>>> = >>>> _______________________________________________ >>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use = >>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>> sipping@ietf.org for new developments on the application of sip >>>> >>>> >>>> >>>> = >>> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 00:24:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F883A6832; Thu, 26 Jun 2008 00:24:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DDD3A6832 for ; Thu, 26 Jun 2008 00:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_81=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 NNuXK9iEMWzp for ; Thu, 26 Jun 2008 00:24:19 -0700 (PDT) Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by core3.amsl.com (Postfix) with ESMTP id AF60D3A681A for ; Thu, 26 Jun 2008 00:24:18 -0700 (PDT) Received: (qmail 8620 invoked by uid 0); 26 Jun 2008 07:24:18 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jun 2008 07:24:18 -0000 Message-ID: <4863441E.1090704@zonnet.nl> Date: Thu, 26 Jun 2008 09:24:14 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> <48633C02.2070703@zonnet.nl> In-Reply-To: Cc: sip@ietf.org, drage@alcatel-lucent.com, john.elwell@siemens.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer, The only solution I can think of that would give less processing, would = be to simply open a TCP connection (or UDP flow with STUN) without = sending any request. Less "overkill", but it would open up a bunch of = security issues ( e.g. TCP connection resources being consumed by = unauthorized elements, leading to DoS; all the concerns with STUNning = before checking support, etc. ). So I don't see how sending at least one = SIP request could be avoided. REGISTER is as good as any. Which proxies to register with: that would of course have to be = provisioned somehow, this is no different from having to provision which = outbound proxy to use UEs that don't register: the idea is to make all such UEs register, so = there'd be no such case left Regards, Jeroen Christer Holmberg wrote: > Jeroen, > > I don't understand what benefit it would be to establish outbound registr= ations between all SIP entities that want to use the keep-alive/heartbeat. = Yes, we would "re-use an existing mechanism", but in my opinion it would re= ally be an overkill,a hack - and anything but keep-it-simple... > > Also, how would the proxies know which proxies it should establish regist= rations which? > > Also, it wouldn't work in the use-case with UEs that don't register. > > Regards, > > Christer > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = > Sent: 26. kes=E4kuuta 2008 9:50 > To: Hadriel Kaplan > Cc: Christer Holmberg; Markus.Isomaki@nokia.com; john.elwell@siemens.com;= drage@alcatel-lucent.com; sip@ietf.org > Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use c= ase > > Hadriel, > > I did not intend to suggest to use the registration interval timer for ke= ep-alive, of course all the regular flow keep-alive mechanisms of outbound = could be used. > > The benefit is that we would reuse the efforts put in outbound, instead o= f inventing yet another, only marginally different, mechanism for each spec= ific case. From the sending element point of view, sending a REGISTER isn't= very different from sending an OPTIONS; subsequent keep-alives can then be= come STUN or double CRLF, until the registration needs to be refreshed. > > Using REGISTER instead of OPTIONS also provides the means to use the stan= dard authentication mechanisms, besides reusing outbound (and there's a few= other reusable things, like Path headers, but let's keep it simple for the= moment) > > Regards, > Jeroen > > Hadriel Kaplan wrote: > = >> Hey Jeroen, >> I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now T= ISPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR'= s to be routed to. For those devices that need that ability, it makes sens= e to use outbound of course, and its inherent keepalive, regardless of bein= g behind a NAT or not. And I don't think Christer's suggesting otherwise. >> >> But for IP-PBX's or proxies which do not themselves represent an AoR tar= get of requests, or do not represent one in the domain of the device they w= ant to perform keepalive with, why would we want to make them add such regi= stration logic? What would be the gain over just simply sending OPTIONS at= that point? >> >> The beauty of a STUN or double-CRLF keepalive is, in my mind: it's trivi= al to construct, trivial to parse, very small and fixed size, can be separa= ted or handled at a lower layer, explicit in its use, and does not get stop= ped by a SIP-layer overload control. In short: it's a transport connection= -layer keepalive, no more no less. And indicating it in the Via keeps it a= hop-link thing, backwards-compatible, little or no provisioning, and with = no URI target addressing issues. >> >> -hadriel >> >> = >> = >>> -----Original Message----- >>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>> Sent: Wednesday, June 25, 2008 5:56 PM >>> To: Christer Holmberg >>> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; = >>> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>> use case >>> >>> No, not a B2BUA. Each element would have a virtual UA function "in = >>> parallel" to its regular function (e.g. being a proxy). And indeed, = >>> one way to implement this would be to keep either one (one way) or = >>> two (opposite ways) flows active between them. >>> >>> Like so: >>> >>> |-----------| |-----------| >>> | Proxy | | Proxy | >>> |-----------| |-----------| >>> | UA | <---------->| UA | >>> |-----------| |-----------| >>> >>> Each "UA" would implement both a simple registrar and a UAC = >>> performing registration. It could also be setup asymmetrically, with = >>> the (smaller) IP-PBX doing a single registration towards the (bigger) = >>> Service provider network. Registration expiry would denote a loss of co= nnectivity. >>> >>> Regards, >>> Jeroen >>> >>> >>> Christer Holmberg wrote: >>> = >>> = >>>> Hi, >>>> >>>> So, you are proposing that each element should be a B2BUA, and both >>>> = >>>> = >>> elements then register towards each other and use Outbound??? >>> = >>> = >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>> Sent: 25. kes=E4kuuta 2008 22:57 >>>> To: Hadriel Kaplan >>>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; = >>>> drage@alcatel- >>>> = >>>> = >>> lucent.com; sip@ietf.org; Christer Holmberg >>> = >>> = >>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>>> use >>>> = >>>> = >>> case >>> = >>> = >>>> Hadriel, Markus, >>>> >>>> Instead of standardizing keep-alives between proxies, how about we >>>> = >>>> = >>> define a "virtual UA" on each element (similar to the one described = >>> in >>> = >>> = >>>> RFC3261 section 16.7 point 6) to be used to provide this functionality? >>>> (using existing outbound functionality, perhaps both ways) >>>> >>>> Regards, >>>> Jeroen >>>> >>>> Hadriel Kaplan wrote: >>>> >>>> = >>>> = >>>>> Yes I am of that same opinion - that any real "IP-PBX" or whatever = >>>>> big enough NOT to be doing Registration, and to instead do static >>>>> = >>>>> = >>> provisioning or DNS, would be given a static hole/DMZ address in = >>> their firewall/NAT. But some of my customers have told me otherwise. >>> (interestingly mostly in APAC region) There's also some concern that = >>> while a static entry is there for inbound TCP connections, the PBX = >>> creates outbound ones to the service provider which are ephemeral = >>> port sources and need to live for very long durations (though why = >>> they can't just do TCP keepalive is beyond me, but I'm no expert). >>> = >>> = >>>>> But anyway, the big issue we've seen is that we need both the PBX = >>>>> and >>>>> = >>>>> = >>> the service provider box to detect failure before an active = >>> call/request attempt is made; to trigger alternate route selection = >>> without waiting for transport failure, and as a method to detect livene= ss again and revert. >>> Today that's almost exclusively done with Options requests as far as = >>> I've seen, and lots of people don't seem to like that. >>> = >>> = >>>>> -hadriel >>>>> >>>>> >>>>> >>>>> >>>>> = >>>>> = >>>>>> -----Original Message----- >>>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>>> Cc: christer.holmberg@ericsson.com >>>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >>>>>> proxy-to-proxy use case >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm a bit sceptical about the need for keep-alives between proxies. >>>>>> It is of course entirely possible that an enterprise PBX is = >>>>>> connected to (or peering with) a service provider proxy through a = >>>>>> NAT and/or a firewall. However, wouldn't such a NAT or firewall be = >>>>>> under the administration of either the enterprise itself or its = >>>>>> ISP (who quite often would be the SIP service provider), and the = >>>>>> required port forwardings or firewall rules could be set through adm= inistration. >>>>>> This means that there would not be need for keepalive traffic to = >>>>>> implicitely keep the mapping/pinhole open. >>>>>> >>>>>> Or are there really deployment cases where there are SIP PBXs = >>>>>> behind unadministrated NATs or firewalls? >>>>>> >>>>>> Wouldn't we then need keepalives for SMTP as well, or how has the = >>>>>> e-mail infrastructure managed to solve this problem? >>>>>> >>>>>> Markus >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>> _______________________________________________ >>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use = >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>>> >>>>> >>>>> = >>>>> = >>>> = >>>> = >> = >> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 00:28:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412D23A6803; Thu, 26 Jun 2008 00:28:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E653A6803 for ; Thu, 26 Jun 2008 00:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_81=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 hB94izqq3-4Q for ; Thu, 26 Jun 2008 00:28:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 189C43A6780 for ; Thu, 26 Jun 2008 00:28:11 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8BD8420A15; Thu, 26 Jun 2008 09:28:13 +0200 (CEST) X-AuditID: c1b4fb3c-ab095bb00000193b-7a-4863450db174 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5BE8C20479; Thu, 26 Jun 2008 09:28:13 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 09:28:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 09:28:40 +0200 Message-ID: In-Reply-To: <4863441E.1090704@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case thread-index: AcjXXbgkNCZCWPtmR2isAwGbomJfdQAACHwA References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> <48633C02.2070703@zonnet.nl> <4863441E.1090704@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" X-OriginalArrivalTime: 26 Jun 2008 07:28:42.0364 (UTC) FILETIME=[428F3BC0:01C8D75E] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, drage@alcatel-lucent.com, john.elwell@siemens.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, = >The only solution I can think of that would give less processing, would be= to simply open a TCP connection (or UDP flow = >with STUN) without sending any request. Less "overkill", but it would open= up a bunch of security issues ( e.g. TCP = >connection resources being consumed by unauthorized elements, leading to D= oS; all the concerns with STUNning before = >checking support, etc. ). So I don't see how sending at least one SIP requ= est could be avoided. REGISTER is as good as = >any. > >Which proxies to register with: that would of course have to be provisione= d somehow, this is no different from having to = >provision which outbound proxy to use There is a big difference. A UA will always send the requests via the outbo= und proxy, but a proxy can communicate with an unlimited number of other pr= oxies. Those proxies are normally found (unless a service route exists) usi= ng DNS when the proxy receives a request to forward. >UEs that don't register: the idea is to make all such UEs register, so the= re'd be no such case left As said earlier, at least 3GPP has a requirement for non-register emergency= calls. Regards, Christer Christer Holmberg wrote: > Jeroen, > > I don't understand what benefit it would be to establish outbound registr= ations between all SIP entities that want to use the keep-alive/heartbeat. = Yes, we would "re-use an existing mechanism", but in my opinion it would re= ally be an overkill,a hack - and anything but keep-it-simple... > > Also, how would the proxies know which proxies it should establish regist= rations which? > > Also, it wouldn't work in the use-case with UEs that don't register. > > Regards, > > Christer > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 26. kes=E4kuuta 2008 9:50 > To: Hadriel Kaplan > Cc: Christer Holmberg; Markus.Isomaki@nokia.com; = > john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org > Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = > use case > > Hadriel, > > I did not intend to suggest to use the registration interval timer for ke= ep-alive, of course all the regular flow keep-alive mechanisms of outbound = could be used. > > The benefit is that we would reuse the efforts put in outbound, instead o= f inventing yet another, only marginally different, mechanism for each spec= ific case. From the sending element point of view, sending a REGISTER isn't= very different from sending an OPTIONS; subsequent keep-alives can then be= come STUN or double CRLF, until the registration needs to be refreshed. > > Using REGISTER instead of OPTIONS also provides the means to use the = > standard authentication mechanisms, besides reusing outbound (and = > there's a few other reusable things, like Path headers, but let's keep = > it simple for the moment) > > Regards, > Jeroen > > Hadriel Kaplan wrote: > = >> Hey Jeroen, >> I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now T= ISPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR'= s to be routed to. For those devices that need that ability, it makes sens= e to use outbound of course, and its inherent keepalive, regardless of bein= g behind a NAT or not. And I don't think Christer's suggesting otherwise. >> >> But for IP-PBX's or proxies which do not themselves represent an AoR tar= get of requests, or do not represent one in the domain of the device they w= ant to perform keepalive with, why would we want to make them add such regi= stration logic? What would be the gain over just simply sending OPTIONS at= that point? >> >> The beauty of a STUN or double-CRLF keepalive is, in my mind: it's trivi= al to construct, trivial to parse, very small and fixed size, can be separa= ted or handled at a lower layer, explicit in its use, and does not get stop= ped by a SIP-layer overload control. In short: it's a transport connection= -layer keepalive, no more no less. And indicating it in the Via keeps it a= hop-link thing, backwards-compatible, little or no provisioning, and with = no URI target addressing issues. >> >> -hadriel >> >> = >> = >>> -----Original Message----- >>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>> Sent: Wednesday, June 25, 2008 5:56 PM >>> To: Christer Holmberg >>> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; = >>> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>> use case >>> >>> No, not a B2BUA. Each element would have a virtual UA function "in = >>> parallel" to its regular function (e.g. being a proxy). And indeed, = >>> one way to implement this would be to keep either one (one way) or = >>> two (opposite ways) flows active between them. >>> >>> Like so: >>> >>> |-----------| |-----------| >>> | Proxy | | Proxy | >>> |-----------| |-----------| >>> | UA | <---------->| UA | >>> |-----------| |-----------| >>> >>> Each "UA" would implement both a simple registrar and a UAC = >>> performing registration. It could also be setup asymmetrically, with = >>> the (smaller) IP-PBX doing a single registration towards the = >>> (bigger) Service provider network. Registration expiry would denote a l= oss of connectivity. >>> >>> Regards, >>> Jeroen >>> >>> >>> Christer Holmberg wrote: >>> = >>> = >>>> Hi, >>>> >>>> So, you are proposing that each element should be a B2BUA, and both >>>> = >>>> = >>> elements then register towards each other and use Outbound??? >>> = >>> = >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>> Sent: 25. kes=E4kuuta 2008 22:57 >>>> To: Hadriel Kaplan >>>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; >>>> drage@alcatel- >>>> = >>>> = >>> lucent.com; sip@ietf.org; Christer Holmberg >>> = >>> = >>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>>> use >>>> = >>>> = >>> case >>> = >>> = >>>> Hadriel, Markus, >>>> >>>> Instead of standardizing keep-alives between proxies, how about we >>>> = >>>> = >>> define a "virtual UA" on each element (similar to the one described = >>> in >>> = >>> = >>>> RFC3261 section 16.7 point 6) to be used to provide this functionality? >>>> (using existing outbound functionality, perhaps both ways) >>>> >>>> Regards, >>>> Jeroen >>>> >>>> Hadriel Kaplan wrote: >>>> >>>> = >>>> = >>>>> Yes I am of that same opinion - that any real "IP-PBX" or whatever = >>>>> big enough NOT to be doing Registration, and to instead do static >>>>> = >>>>> = >>> provisioning or DNS, would be given a static hole/DMZ address in = >>> their firewall/NAT. But some of my customers have told me otherwise. >>> (interestingly mostly in APAC region) There's also some concern that = >>> while a static entry is there for inbound TCP connections, the PBX = >>> creates outbound ones to the service provider which are ephemeral = >>> port sources and need to live for very long durations (though why = >>> they can't just do TCP keepalive is beyond me, but I'm no expert). >>> = >>> = >>>>> But anyway, the big issue we've seen is that we need both the PBX = >>>>> and >>>>> = >>>>> = >>> the service provider box to detect failure before an active = >>> call/request attempt is made; to trigger alternate route selection = >>> without waiting for transport failure, and as a method to detect livene= ss again and revert. >>> Today that's almost exclusively done with Options requests as far as = >>> I've seen, and lots of people don't seem to like that. >>> = >>> = >>>>> -hadriel >>>>> >>>>> >>>>> >>>>> >>>>> = >>>>> = >>>>>> -----Original Message----- >>>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>>> Cc: christer.holmberg@ericsson.com >>>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >>>>>> proxy-to-proxy use case >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm a bit sceptical about the need for keep-alives between proxies. >>>>>> It is of course entirely possible that an enterprise PBX is = >>>>>> connected to (or peering with) a service provider proxy through a = >>>>>> NAT and/or a firewall. However, wouldn't such a NAT or firewall = >>>>>> be under the administration of either the enterprise itself or = >>>>>> its ISP (who quite often would be the SIP service provider), and = >>>>>> the required port forwardings or firewall rules could be set through= administration. >>>>>> This means that there would not be need for keepalive traffic to = >>>>>> implicitely keep the mapping/pinhole open. >>>>>> >>>>>> Or are there really deployment cases where there are SIP PBXs = >>>>>> behind unadministrated NATs or firewalls? >>>>>> >>>>>> Wouldn't we then need keepalives for SMTP as well, or how has the = >>>>>> e-mail infrastructure managed to solve this problem? >>>>>> >>>>>> Markus >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>> _______________________________________________ >>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use = >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>>> >>>>> >>>>> = >>>>> = >>>> = >>>> = >> = >> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 00:34:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22613A6832; Thu, 26 Jun 2008 00:34:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9B83A6832 for ; Thu, 26 Jun 2008 00:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViqluoddLvUU for ; Thu, 26 Jun 2008 00:34:54 -0700 (PDT) Received: from smtp6.versatel.nl (smtp6.versatel.nl [62.58.50.97]) by core3.amsl.com (Postfix) with ESMTP id 22BFB3A6803 for ; Thu, 26 Jun 2008 00:34:53 -0700 (PDT) Received: (qmail 18413 invoked by uid 0); 26 Jun 2008 07:34:54 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jun 2008 07:34:54 -0000 Message-ID: <48634699.8030503@zonnet.nl> Date: Thu, 26 Jun 2008 09:34:49 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Elwell, John" References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9EF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E9EF@GBNTHT12009MSX.gb002.siemens.net> Cc: sip@ietf.org, Markus.Isomaki@nokia.com, drage@alcatel-lucent.com, Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John, The problem with "not appropriate" is that it's subjective and = ambiguous. I think we understand "not strictly needed" (or "overkill" as = some say), e.g. when there is no NAT device in between. A case I can imagine where outbound wouldn't work, is if the proxies in = question are connected indirectly (i.e. not hop-by-hop). Then the = outbound keep-alive mechanism doesn't work, and you'd need some SIP = request instead (or some elaborate scheme to pass on keep-alive = information across multiple hops in some other way) Regards, Jeroen Elwell, John wrote: > Jeroen, > > Yes, this is effectively what you have when an IPPBX is required to regis= ter with a service provider. But in that case, there might also be a need t= o implement sip-outbound if there are unadministered NATs/firewalls in the = way. Indeed, sip-outbound would operate between a virtual UA on the IPPBX s= ide and a registrar on the service provider side. > > What I am interested in gaining from this discussion is whether there are= proxy-to-proxy cases where sip-outbound is not appropriate but keep-alive = (or heartbeat) is needed. > > John > > = >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = >> Sent: 25 June 2008 22:56 >> To: Christer Holmberg >> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; Elwell, John; = >> drage@alcatel-lucent.com; sip@ietf.org >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = >> proxy-to-proxy use case >> >> No, not a B2BUA. Each element would have a virtual UA function "in = >> parallel" to its regular function (e.g. being a proxy). And = >> indeed, one = >> way to implement this would be to keep either one (one way) or two = >> (opposite ways) flows active between them. >> >> Like so: >> >> |-----------| |-----------| >> | Proxy | | Proxy | >> |-----------| |-----------| >> | UA | <---------->| UA | >> |-----------| |-----------| >> >> Each "UA" would implement both a simple registrar and a UAC = >> performing = >> registration. It could also be setup asymmetrically, with the = >> (smaller) = >> IP-PBX doing a single registration towards the (bigger) = >> Service provider = >> network. Registration expiry would denote a loss of connectivity. >> >> Regards, >> Jeroen >> >> >> Christer Holmberg wrote: >> = >>> Hi, >>> >>> So, you are proposing that each element should be a B2BUA, = >>> = >> and both elements then register towards each other and use Outbound??? >> = >>> Regards, >>> >>> Christer = >>> >>> -----Original Message----- >>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] = >>> Sent: 25. kes=E4kuuta 2008 22:57 >>> To: Hadriel Kaplan >>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; = >>> = >> drage@alcatel-lucent.com; sip@ietf.org; Christer Holmberg >> = >>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = >>> = >> proxy-to-proxy use case >> = >>> Hadriel, Markus, >>> >>> Instead of standardizing keep-alives between proxies, how = >>> = >> about we define a "virtual UA" on each element (similar to = >> the one described in >> = >>> RFC3261 section 16.7 point 6) to be used to provide this = >>> = >> functionality? = >> = >>> (using existing outbound functionality, perhaps both ways) >>> >>> Regards, >>> Jeroen >>> >>> Hadriel Kaplan wrote: >>> = >>> = >>>> Yes I am of that same opinion - that any real "IP-PBX" or = >>>> = >> whatever big = >> = >>>> enough NOT to be doing Registration, and to instead do = >>>> = >> static provisioning or DNS, would be given a static hole/DMZ = >> address in their firewall/NAT. But some of my customers have = >> told me otherwise. (interestingly mostly in APAC region) = >> There's also some concern that while a static entry is there = >> for inbound TCP connections, the PBX creates outbound ones to = >> the service provider which are ephemeral port sources and = >> need to live for very long durations (though why they can't = >> just do TCP keepalive is beyond me, but I'm no expert). >> = >>>> But anyway, the big issue we've seen is that we need both = >>>> = >> the PBX and the service provider box to detect failure before = >> an active call/request attempt is made; to trigger alternate = >> route selection without waiting for transport failure, and as = >> a method to detect liveness again and revert. Today that's = >> almost exclusively done with Options requests as far as I've = >> seen, and lots of people don't seem to like that. >> = >>>> -hadriel >>>> >>>> >>>> = >>>> = >>>> = >>>>> -----Original Message----- >>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>> Cc: christer.holmberg@ericsson.com >>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >>>>> = >> proxy-to-proxy = >> = >>>>> use case >>>>> >>>>> Hi, >>>>> >>>>> I'm a bit sceptical about the need for keep-alives = >>>>> = >> between proxies. = >> = >>>>> It is of course entirely possible that an enterprise PBX = >>>>> = >> is connected = >> = >>>>> to (or peering with) a service provider proxy through a = >>>>> = >> NAT and/or a = >> = >>>>> firewall. However, wouldn't such a NAT or firewall be under the = >>>>> administration of either the enterprise itself or its ISP = >>>>> = >> (who quite = >> = >>>>> often would be the SIP service provider), and the required port = >>>>> forwardings or firewall rules could be set through = >>>>> = >> administration. = >> = >>>>> This means that there would not be need for keepalive traffic to = >>>>> implicitely keep the mapping/pinhole open. >>>>> >>>>> Or are there really deployment cases where there are SIP = >>>>> = >> PBXs behind = >> = >>>>> unadministrated NATs or firewalls? >>>>> >>>>> Wouldn't we then need keepalives for SMTP as well, or how has the = >>>>> e-mail infrastructure managed to solve this problem? >>>>> >>>>> Markus >>>>> >>>>> = >>>>> = >>>>> = >>>> _______________________________________________ >>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use = >>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>> sipping@ietf.org for new developments on the application of sip >>>> >>>> = >>>> = >>>> = >>> = >>> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 00:52:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12643A6803; Thu, 26 Jun 2008 00:52:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558833A67AE for ; Thu, 26 Jun 2008 00:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_81=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 6mtR01z28Foc for ; Thu, 26 Jun 2008 00:52:46 -0700 (PDT) Received: from smtp6.versatel.nl (smtp6.versatel.nl [62.58.50.97]) by core3.amsl.com (Postfix) with ESMTP id 30A693A6832 for ; Thu, 26 Jun 2008 00:52:46 -0700 (PDT) Received: (qmail 26489 invoked by uid 0); 26 Jun 2008 07:52:45 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.2.155]) ([87.212.11.198]) (envelope-sender ) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jun 2008 07:52:45 -0000 Message-ID: <48634AC8.30201@zonnet.nl> Date: Thu, 26 Jun 2008 09:52:40 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christer Holmberg References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> <48633C02.2070703@zonnet.nl> <4863441E.1090704@zonnet.nl> In-Reply-To: Cc: sip@ietf.org, drage@alcatel-lucent.com, john.elwell@siemens.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer, We're mixing different cases here. The 3GPP non-register emergency call = scenario is for an endpoint, I was talking about the proxy-to-proxy case = (I believe the 3GPP case can be addressed using standard mechanisms = available today, it's only about authorization policies and = identification of what calls are emergency calls). It doesn't make sense for a proxy to keep-alive connections with = arbitrary other proxies. Either it has a limited set of peers (such as = in case of an IP-PBX peering with a service provider), or it routes = using DNS based on the domain in the request URI (or top Route header). = For the latter case, the act of sending the INVITE itself will detect = reachability. So I suggest to limit the proxy-to-proxy use-case for keep-alive to = proxies that route towards a limited set of next hops (instead of DNS on = domain). According to RFC3261, such proxies would insert a Route header = (with loose routing) Regards, Jeroen Christer Holmberg wrote: > Hi, = > > = >> The only solution I can think of that would give less processing, would = be to simply open a TCP connection (or UDP flow = >> with STUN) without sending any request. Less "overkill", but it would op= en up a bunch of security issues ( e.g. TCP = >> connection resources being consumed by unauthorized elements, leading to= DoS; all the concerns with STUNning before = >> checking support, etc. ). So I don't see how sending at least one SIP re= quest could be avoided. REGISTER is as good as = >> any. >> >> Which proxies to register with: that would of course have to be provisio= ned somehow, this is no different from having to = >> provision which outbound proxy to use >> = > > There is a big difference. A UA will always send the requests via the out= bound proxy, but a proxy can communicate with an unlimited number of other = proxies. Those proxies are normally found (unless a service route exists) u= sing DNS when the proxy receives a request to forward. > > = >> UEs that don't register: the idea is to make all such UEs register, so t= here'd be no such case left >> = > > As said earlier, at least 3GPP has a requirement for non-register emergen= cy calls. > > Regards, > > Christer > > > > > > Christer Holmberg wrote: > = >> Jeroen, >> >> I don't understand what benefit it would be to establish outbound regist= rations between all SIP entities that want to use the keep-alive/heartbeat.= Yes, we would "re-use an existing mechanism", but in my opinion it would r= eally be an overkill,a hack - and anything but keep-it-simple... >> >> Also, how would the proxies know which proxies it should establish regis= trations which? >> >> Also, it wouldn't work in the use-case with UEs that don't register. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 26. kes=E4kuuta 2008 9:50 >> To: Hadriel Kaplan >> Cc: Christer Holmberg; Markus.Isomaki@nokia.com; = >> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >> use case >> >> Hadriel, >> >> I did not intend to suggest to use the registration interval timer for k= eep-alive, of course all the regular flow keep-alive mechanisms of outbound= could be used. >> >> The benefit is that we would reuse the efforts put in outbound, instead = of inventing yet another, only marginally different, mechanism for each spe= cific case. From the sending element point of view, sending a REGISTER isn'= t very different from sending an OPTIONS; subsequent keep-alives can then b= ecome STUN or double CRLF, until the registration needs to be refreshed. >> >> Using REGISTER instead of OPTIONS also provides the means to use the = >> standard authentication mechanisms, besides reusing outbound (and = >> there's a few other reusable things, like Path headers, but let's keep = >> it simple for the moment) >> >> Regards, >> Jeroen >> >> Hadriel Kaplan wrote: >> = >> = >>> Hey Jeroen, >>> I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now = TISPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR= 's to be routed to. For those devices that need that ability, it makes sen= se to use outbound of course, and its inherent keepalive, regardless of bei= ng behind a NAT or not. And I don't think Christer's suggesting otherwise. >>> >>> But for IP-PBX's or proxies which do not themselves represent an AoR ta= rget of requests, or do not represent one in the domain of the device they = want to perform keepalive with, why would we want to make them add such reg= istration logic? What would be the gain over just simply sending OPTIONS a= t that point? >>> >>> The beauty of a STUN or double-CRLF keepalive is, in my mind: it's triv= ial to construct, trivial to parse, very small and fixed size, can be separ= ated or handled at a lower layer, explicit in its use, and does not get sto= pped by a SIP-layer overload control. In short: it's a transport connectio= n-layer keepalive, no more no less. And indicating it in the Via keeps it = a hop-link thing, backwards-compatible, little or no provisioning, and with= no URI target addressing issues. >>> >>> -hadriel >>> >>> = >>> = >>> = >>>> -----Original Message----- >>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>> Sent: Wednesday, June 25, 2008 5:56 PM >>>> To: Christer Holmberg >>>> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; = >>>> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>>> use case >>>> >>>> No, not a B2BUA. Each element would have a virtual UA function "in = >>>> parallel" to its regular function (e.g. being a proxy). And indeed, = >>>> one way to implement this would be to keep either one (one way) or = >>>> two (opposite ways) flows active between them. >>>> >>>> Like so: >>>> >>>> |-----------| |-----------| >>>> | Proxy | | Proxy | >>>> |-----------| |-----------| >>>> | UA | <---------->| UA | >>>> |-----------| |-----------| >>>> >>>> Each "UA" would implement both a simple registrar and a UAC = >>>> performing registration. It could also be setup asymmetrically, with = >>>> the (smaller) IP-PBX doing a single registration towards the = >>>> (bigger) Service provider network. Registration expiry would denote a = loss of connectivity. >>>> >>>> Regards, >>>> Jeroen >>>> >>>> >>>> Christer Holmberg wrote: >>>> = >>>> = >>>> = >>>>> Hi, >>>>> >>>>> So, you are proposing that each element should be a B2BUA, and both >>>>> = >>>>> = >>>>> = >>>> elements then register towards each other and use Outbound??? >>>> = >>>> = >>>> = >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>>> Sent: 25. kes=E4kuuta 2008 22:57 >>>>> To: Hadriel Kaplan >>>>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; >>>>> drage@alcatel- >>>>> = >>>>> = >>>>> = >>>> lucent.com; sip@ietf.org; Christer Holmberg >>>> = >>>> = >>>> = >>>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>>>> use >>>>> = >>>>> = >>>>> = >>>> case >>>> = >>>> = >>>> = >>>>> Hadriel, Markus, >>>>> >>>>> Instead of standardizing keep-alives between proxies, how about we >>>>> = >>>>> = >>>>> = >>>> define a "virtual UA" on each element (similar to the one described = >>>> in >>>> = >>>> = >>>> = >>>>> RFC3261 section 16.7 point 6) to be used to provide this functionalit= y? >>>>> (using existing outbound functionality, perhaps both ways) >>>>> >>>>> Regards, >>>>> Jeroen >>>>> >>>>> Hadriel Kaplan wrote: >>>>> >>>>> = >>>>> = >>>>> = >>>>>> Yes I am of that same opinion - that any real "IP-PBX" or whatever = >>>>>> big enough NOT to be doing Registration, and to instead do static >>>>>> = >>>>>> = >>>>>> = >>>> provisioning or DNS, would be given a static hole/DMZ address in = >>>> their firewall/NAT. But some of my customers have told me otherwise. >>>> (interestingly mostly in APAC region) There's also some concern that = >>>> while a static entry is there for inbound TCP connections, the PBX = >>>> creates outbound ones to the service provider which are ephemeral = >>>> port sources and need to live for very long durations (though why = >>>> they can't just do TCP keepalive is beyond me, but I'm no expert). >>>> = >>>> = >>>> = >>>>>> But anyway, the big issue we've seen is that we need both the PBX = >>>>>> and >>>>>> = >>>>>> = >>>>>> = >>>> the service provider box to detect failure before an active = >>>> call/request attempt is made; to trigger alternate route selection = >>>> without waiting for transport failure, and as a method to detect liven= ess again and revert. >>>> Today that's almost exclusively done with Options requests as far as = >>>> I've seen, and lots of people don't seem to like that. >>>> = >>>> = >>>> = >>>>>> -hadriel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>>> = >>>>>>> -----Original Message----- >>>>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>>>> Cc: christer.holmberg@ericsson.com >>>>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >>>>>>> proxy-to-proxy use case >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm a bit sceptical about the need for keep-alives between proxies. >>>>>>> It is of course entirely possible that an enterprise PBX is = >>>>>>> connected to (or peering with) a service provider proxy through a = >>>>>>> NAT and/or a firewall. However, wouldn't such a NAT or firewall = >>>>>>> be under the administration of either the enterprise itself or = >>>>>>> its ISP (who quite often would be the SIP service provider), and = >>>>>>> the required port forwardings or firewall rules could be set throug= h administration. >>>>>>> This means that there would not be need for keepalive traffic to = >>>>>>> implicitely keep the mapping/pinhole open. >>>>>>> >>>>>>> Or are there really deployment cases where there are SIP PBXs = >>>>>>> behind unadministrated NATs or firewalls? >>>>>>> >>>>>>> Wouldn't we then need keepalives for SMTP as well, or how has the = >>>>>>> e-mail infrastructure managed to solve this problem? >>>>>>> >>>>>>> Markus >>>>>>> >>>>>>> >>>>>>> >>>>>>> = >>>>>>> = >>>>>>> = >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use = >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>>> = >>>>> = >>>>> = >>>>> = >>> = >>> = >>> = >> = >> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 01:05:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E143A67AE; Thu, 26 Jun 2008 01:05:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E866F3A6780 for ; Thu, 26 Jun 2008 01:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_81=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 NM1ecMXKyp1L for ; Thu, 26 Jun 2008 01:05:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BFAFC3A67DF for ; Thu, 26 Jun 2008 01:05:35 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6DAE8207B9; Thu, 26 Jun 2008 10:05:37 +0200 (CEST) X-AuditID: c1b4fb3c-ae89cbb00000193b-01-48634dd16e44 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3912A206F4; Thu, 26 Jun 2008 10:05:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 10:06:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 10:06:05 +0200 Message-ID: In-Reply-To: <48634AC8.30201@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case thread-index: AcjXYbQiSDX58ZUlRnujAgoBuoPUUwAAQiFQ References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl> <4862BEE4.502@zonnet.nl> <48633C02.2070703@zonnet.nl> <4863441E.1090704@zonnet.nl> <48634AC8.30201@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" X-OriginalArrivalTime: 26 Jun 2008 08:06:06.0288 (UTC) FILETIME=[7C0ADD00:01C8D763] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, drage@alcatel-lucent.com, john.elwell@siemens.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, = >We're mixing different cases here. The 3GPP non-register emergency call sc= enario is for an endpoint, I was talking about = >the proxy-to-proxy case (I believe the 3GPP case can be addressed using st= andard mechanisms available today, it's only = >about authorization policies and identification of what calls are emergenc= y calls). > >It doesn't make sense for a proxy to keep-alive connections with arbitrary= other proxies. Either it has a limited set of = >peers (such as in case of an IP-PBX peering with a service provider), or i= t routes using DNS based on the domain in the = >request URI (or top Route header). = >For the latter case, the act of sending the INVITE itself will detect reac= hability. > >So I suggest to limit the proxy-to-proxy use-case for keep-alive to proxie= s that route towards a limited set of next hops = >(instead of DNS on domain). According to RFC3261, such proxies would inser= t a Route header (with loose routing) Ok. Thanks for the clarification. So, if I understand you correctly you either: 1. Propose that proxy-to-proxy should not be part of the scope of the draft 2. Proxy-to-proxy could be part of the scope of the draft, but we would not= necessarily use the same mechanism for UA-to-proxy and proxy-to-proxy. Correct? Regards, Christer Christer Holmberg wrote: > Hi, > > = >> The only solution I can think of that would give less processing, = >> would be to simply open a TCP connection (or UDP flow with STUN) = >> without sending any request. Less "overkill", but it would open up a = >> bunch of security issues ( e.g. TCP connection resources being = >> consumed by unauthorized elements, leading to DoS; all the concerns with= STUNning before checking support, etc. ). So I don't see how sending at le= ast one SIP request could be avoided. REGISTER is as good as any. >> >> Which proxies to register with: that would of course have to be = >> provisioned somehow, this is no different from having to provision = >> which outbound proxy to use >> = > > There is a big difference. A UA will always send the requests via the out= bound proxy, but a proxy can communicate with an unlimited number of other = proxies. Those proxies are normally found (unless a service route exists) u= sing DNS when the proxy receives a request to forward. > > = >> UEs that don't register: the idea is to make all such UEs register, = >> so there'd be no such case left >> = > > As said earlier, at least 3GPP has a requirement for non-register emergen= cy calls. > > Regards, > > Christer > > > > > > Christer Holmberg wrote: > = >> Jeroen, >> >> I don't understand what benefit it would be to establish outbound regist= rations between all SIP entities that want to use the keep-alive/heartbeat.= Yes, we would "re-use an existing mechanism", but in my opinion it would r= eally be an overkill,a hack - and anything but keep-it-simple... >> >> Also, how would the proxies know which proxies it should establish regis= trations which? >> >> Also, it wouldn't work in the use-case with UEs that don't register. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 26. kes=E4kuuta 2008 9:50 >> To: Hadriel Kaplan >> Cc: Christer Holmberg; Markus.Isomaki@nokia.com; = >> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >> use case >> >> Hadriel, >> >> I did not intend to suggest to use the registration interval timer for k= eep-alive, of course all the regular flow keep-alive mechanisms of outbound= could be used. >> >> The benefit is that we would reuse the efforts put in outbound, instead = of inventing yet another, only marginally different, mechanism for each spe= cific case. From the sending element point of view, sending a REGISTER isn'= t very different from sending an OPTIONS; subsequent keep-alives can then b= ecome STUN or double CRLF, until the registration needs to be refreshed. >> >> Using REGISTER instead of OPTIONS also provides the means to use the = >> standard authentication mechanisms, besides reusing outbound (and = >> there's a few other reusable things, like Path headers, but let's = >> keep it simple for the moment) >> >> Regards, >> Jeroen >> >> Hadriel Kaplan wrote: >> = >> = >>> Hey Jeroen, >>> I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now = TISPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR= 's to be routed to. For those devices that need that ability, it makes sen= se to use outbound of course, and its inherent keepalive, regardless of bei= ng behind a NAT or not. And I don't think Christer's suggesting otherwise. >>> >>> But for IP-PBX's or proxies which do not themselves represent an AoR ta= rget of requests, or do not represent one in the domain of the device they = want to perform keepalive with, why would we want to make them add such reg= istration logic? What would be the gain over just simply sending OPTIONS a= t that point? >>> >>> The beauty of a STUN or double-CRLF keepalive is, in my mind: it's triv= ial to construct, trivial to parse, very small and fixed size, can be separ= ated or handled at a lower layer, explicit in its use, and does not get sto= pped by a SIP-layer overload control. In short: it's a transport connectio= n-layer keepalive, no more no less. And indicating it in the Via keeps it = a hop-link thing, backwards-compatible, little or no provisioning, and with= no URI target addressing issues. >>> >>> -hadriel >>> >>> = >>> = >>> = >>>> -----Original Message----- >>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>> Sent: Wednesday, June 25, 2008 5:56 PM >>>> To: Christer Holmberg >>>> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; = >>>> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>>> use case >>>> >>>> No, not a B2BUA. Each element would have a virtual UA function "in = >>>> parallel" to its regular function (e.g. being a proxy). And indeed, = >>>> one way to implement this would be to keep either one (one way) or = >>>> two (opposite ways) flows active between them. >>>> >>>> Like so: >>>> >>>> |-----------| |-----------| >>>> | Proxy | | Proxy | >>>> |-----------| |-----------| >>>> | UA | <---------->| UA | >>>> |-----------| |-----------| >>>> >>>> Each "UA" would implement both a simple registrar and a UAC = >>>> performing registration. It could also be setup asymmetrically, = >>>> with the (smaller) IP-PBX doing a single registration towards the >>>> (bigger) Service provider network. Registration expiry would denote a = loss of connectivity. >>>> >>>> Regards, >>>> Jeroen >>>> >>>> >>>> Christer Holmberg wrote: >>>> = >>>> = >>>> = >>>>> Hi, >>>>> >>>>> So, you are proposing that each element should be a B2BUA, and = >>>>> both >>>>> = >>>>> = >>>>> = >>>> elements then register towards each other and use Outbound??? >>>> = >>>> = >>>> = >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>>> Sent: 25. kes=E4kuuta 2008 22:57 >>>>> To: Hadriel Kaplan >>>>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; >>>>> drage@alcatel- >>>>> = >>>>> = >>>>> = >>>> lucent.com; sip@ietf.org; Christer Holmberg >>>> = >>>> = >>>> = >>>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = >>>>> proxy-to-proxy use >>>>> = >>>>> = >>>>> = >>>> case >>>> = >>>> = >>>> = >>>>> Hadriel, Markus, >>>>> >>>>> Instead of standardizing keep-alives between proxies, how about we >>>>> = >>>>> = >>>>> = >>>> define a "virtual UA" on each element (similar to the one described = >>>> in >>>> = >>>> = >>>> = >>>>> RFC3261 section 16.7 point 6) to be used to provide this functionalit= y? >>>>> (using existing outbound functionality, perhaps both ways) >>>>> >>>>> Regards, >>>>> Jeroen >>>>> >>>>> Hadriel Kaplan wrote: >>>>> >>>>> = >>>>> = >>>>> = >>>>>> Yes I am of that same opinion - that any real "IP-PBX" or = >>>>>> whatever big enough NOT to be doing Registration, and to instead = >>>>>> do static >>>>>> = >>>>>> = >>>>>> = >>>> provisioning or DNS, would be given a static hole/DMZ address in = >>>> their firewall/NAT. But some of my customers have told me otherwise. >>>> (interestingly mostly in APAC region) There's also some concern = >>>> that while a static entry is there for inbound TCP connections, the = >>>> PBX creates outbound ones to the service provider which are = >>>> ephemeral port sources and need to live for very long durations = >>>> (though why they can't just do TCP keepalive is beyond me, but I'm no = expert). >>>> = >>>> = >>>> = >>>>>> But anyway, the big issue we've seen is that we need both the PBX = >>>>>> and >>>>>> = >>>>>> = >>>>>> = >>>> the service provider box to detect failure before an active = >>>> call/request attempt is made; to trigger alternate route selection = >>>> without waiting for transport failure, and as a method to detect liven= ess again and revert. >>>> Today that's almost exclusively done with Options requests as far = >>>> as I've seen, and lots of people don't seem to like that. >>>> = >>>> = >>>> = >>>>>> -hadriel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>>> = >>>>>>> -----Original Message----- >>>>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>>>> Cc: christer.holmberg@ericsson.com >>>>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >>>>>>> proxy-to-proxy use case >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm a bit sceptical about the need for keep-alives between proxies. >>>>>>> It is of course entirely possible that an enterprise PBX is = >>>>>>> connected to (or peering with) a service provider proxy through = >>>>>>> a NAT and/or a firewall. However, wouldn't such a NAT or = >>>>>>> firewall be under the administration of either the enterprise = >>>>>>> itself or its ISP (who quite often would be the SIP service = >>>>>>> provider), and the required port forwardings or firewall rules coul= d be set through administration. >>>>>>> This means that there would not be need for keepalive traffic to = >>>>>>> implicitely keep the mapping/pinhole open. >>>>>>> >>>>>>> Or are there really deployment cases where there are SIP PBXs = >>>>>>> behind unadministrated NATs or firewalls? >>>>>>> >>>>>>> Wouldn't we then need keepalives for SMTP as well, or how has = >>>>>>> the e-mail infrastructure managed to solve this problem? >>>>>>> >>>>>>> Markus >>>>>>> >>>>>>> >>>>>>> >>>>>>> = >>>>>>> = >>>>>>> = >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use = >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>>> = >>>>> = >>>>> = >>>>> = >>> = >>> = >>> = >> = >> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 01:08:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7473A67AE; Thu, 26 Jun 2008 01:08:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536B43A67AE for ; Thu, 26 Jun 2008 01:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLf7iy25N9O1 for ; Thu, 26 Jun 2008 01:08:01 -0700 (PDT) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id 28BAE3A6780 for ; Thu, 26 Jun 2008 01:08:01 -0700 (PDT) X-AuditID: cb5bdd58-a78fabb000000d33-ad-48634e622323 Received: from blr-ec-aa03.wipro.com (unknown [10.201.18.42]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id 3742F558004 for ; Thu, 26 Jun 2008 13:38:02 +0530 (IST) Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 13:38:02 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 13:38:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 13:37:58 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE0709F404@BLR-EC-MBX02.wipro.com> In-Reply-To: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] can SDP contain 2 'M' lines Thread-Index: AcjXV9FLfTuYBAsDTjmu+sfIx4IT/wAC9hpQ References: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> From: To: , X-OriginalArrivalTime: 26 Jun 2008 08:08:02.0062 (UTC) FILETIME=[C10C92E0:01C8D763] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] can SDP contain 2 'M' lines X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0533618839==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0533618839== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D763.C0E9EA3B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D763.C0E9EA3B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, each m line start a new media section in the SDP. You can take a look at SDP RFC. =20 Best Regards,=20 Ashish Saxena=20 877-5570=20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar Reddy Sent: Thursday, June 26, 2008 12:04 PM To: sip@ietf.org Subject: [Sip] can SDP contain 2 'M' lines Hi All, In SDP can we have two 'M' lines for re-INVITE i.e. for call hold. if yes what is RFC / draft Any response is highly appreciated Regards Sudhir=20 ------_=_NextPart_001_01C8D763.C0E9EA3B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, each m line start a new media section in = the SDP. You=20 can take a look at SDP RFC.
 

Best = Regards,
Ashish Saxena
877-5570

 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar=20 Reddy
Sent: Thursday, June 26, 2008 12:04 PM
To:=20 sip@ietf.org
Subject: [Sip] can SDP contain 2 'M'=20 lines

Hi All,

In SDP can we have two 'M' lines for re-INVITE = i.e.=20 for call hold.

if yes what is RFC / draft

Any response is = highly=20 appreciated

Regards
Sudhir ------_=_NextPart_001_01C8D763.C0E9EA3B-- --===============0533618839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0533618839==-- From sip-bounces@ietf.org Thu Jun 26 01:10:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5C43A67DF; Thu, 26 Jun 2008 01:10:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6081E3A67DF for ; Thu, 26 Jun 2008 01:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_81=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 vrNF-D8hx+dz for ; Thu, 26 Jun 2008 01:10:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9CB633A6780 for ; Thu, 26 Jun 2008 01:10:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 62AAC21109; Thu, 26 Jun 2008 10:10:49 +0200 (CEST) X-AuditID: c1b4fb3e-af19abb000004ec0-8f-48634f09daf2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3F7922104C; Thu, 26 Jun 2008 10:10:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 10:11:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 10:11:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case thread-index: AcjXYbQiSDX58ZUlRnujAgoBuoPUUwAAQiFQAABKNbA= References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6DEA6@GBNTHT12009MSX.gb002.siemens.net> <4862A324.6020703@zonnet.nl><4862BEE4.502@zonnet.nl><48633C02.2070703@zonnet.nl><4863441E.1090704@zonnet.nl><48634AC8.30201@zonnet.nl> From: "Christer Holmberg" To: "Christer Holmberg" , "Jeroen van Bemmel" X-OriginalArrivalTime: 26 Jun 2008 08:11:18.0600 (UTC) FILETIME=[3631E480:01C8D764] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, john.elwell@siemens.com, drage@alcatel-lucent.com, Markus.Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Another thing. As currently defined in the draft, when the "keep" parameter is used for no= n-registration calls (no matter whether it's UA-to-proxy or proxy-to-proxy)= the duration is only for the lifetime of the call. When the "keep" parameter is used for registration calls, the duration is f= or the lifetime of the registration (as for Outbound). Regards, Christer = -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris= ter Holmberg Sent: 26. kes=E4kuuta 2008 11:06 To: Jeroen van Bemmel Cc: sip@ietf.org; drage@alcatel-lucent.com; john.elwell@siemens.com; Markus= .Isomaki@nokia.com Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case Hi, = >We're mixing different cases here. The 3GPP non-register emergency call = >scenario is for an endpoint, I was talking about the proxy-to-proxy = >case (I believe the 3GPP case can be addressed using standard mechanisms a= vailable today, it's only about authorization policies and identification o= f what calls are emergency calls). > >It doesn't make sense for a proxy to keep-alive connections with = >arbitrary other proxies. Either it has a limited set of peers (such as = >in case of an IP-PBX peering with a service provider), or it routes using = DNS based on the domain in the request URI (or top Route header). >For the latter case, the act of sending the INVITE itself will detect reac= hability. > >So I suggest to limit the proxy-to-proxy use-case for keep-alive to = >proxies that route towards a limited set of next hops (instead of DNS = >on domain). According to RFC3261, such proxies would insert a Route = >header (with loose routing) Ok. Thanks for the clarification. So, if I understand you correctly you either: 1. Propose that proxy-to-proxy should not be part of the scope of the draft= 2. Proxy-to-proxy could be part of the scope of the draft, but we would no= t necessarily use the same mechanism for UA-to-proxy and proxy-to-proxy. Correct? Regards, Christer Christer Holmberg wrote: > Hi, > > = >> The only solution I can think of that would give less processing, = >> would be to simply open a TCP connection (or UDP flow with STUN) = >> without sending any request. Less "overkill", but it would open up a = >> bunch of security issues ( e.g. TCP connection resources being = >> consumed by unauthorized elements, leading to DoS; all the concerns with= STUNning before checking support, etc. ). So I don't see how sending at le= ast one SIP request could be avoided. REGISTER is as good as any. >> >> Which proxies to register with: that would of course have to be = >> provisioned somehow, this is no different from having to provision = >> which outbound proxy to use >> = > > There is a big difference. A UA will always send the requests via the out= bound proxy, but a proxy can communicate with an unlimited number of other = proxies. Those proxies are normally found (unless a service route exists) u= sing DNS when the proxy receives a request to forward. > > = >> UEs that don't register: the idea is to make all such UEs register, = >> so there'd be no such case left >> = > > As said earlier, at least 3GPP has a requirement for non-register emergen= cy calls. > > Regards, > > Christer > > > > > > Christer Holmberg wrote: > = >> Jeroen, >> >> I don't understand what benefit it would be to establish outbound regist= rations between all SIP entities that want to use the keep-alive/heartbeat.= Yes, we would "re-use an existing mechanism", but in my opinion it would r= eally be an overkill,a hack - and anything but keep-it-simple... >> >> Also, how would the proxies know which proxies it should establish regis= trations which? >> >> Also, it wouldn't work in the use-case with UEs that don't register. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 26. kes=E4kuuta 2008 9:50 >> To: Hadriel Kaplan >> Cc: Christer Holmberg; Markus.Isomaki@nokia.com; = >> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >> use case >> >> Hadriel, >> >> I did not intend to suggest to use the registration interval timer for k= eep-alive, of course all the regular flow keep-alive mechanisms of outbound= could be used. >> >> The benefit is that we would reuse the efforts put in outbound, instead = of inventing yet another, only marginally different, mechanism for each spe= cific case. From the sending element point of view, sending a REGISTER isn'= t very different from sending an OPTIONS; subsequent keep-alives can then b= ecome STUN or double CRLF, until the registration needs to be refreshed. >> >> Using REGISTER instead of OPTIONS also provides the means to use the = >> standard authentication mechanisms, besides reusing outbound (and = >> there's a few other reusable things, like Path headers, but let's = >> keep it simple for the moment) >> >> Regards, >> Jeroen >> >> Hadriel Kaplan wrote: >> = >> = >>> Hey Jeroen, >>> I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now = TISPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR= 's to be routed to. For those devices that need that ability, it makes sen= se to use outbound of course, and its inherent keepalive, regardless of bei= ng behind a NAT or not. And I don't think Christer's suggesting otherwise. >>> >>> But for IP-PBX's or proxies which do not themselves represent an AoR ta= rget of requests, or do not represent one in the domain of the device they = want to perform keepalive with, why would we want to make them add such reg= istration logic? What would be the gain over just simply sending OPTIONS a= t that point? >>> >>> The beauty of a STUN or double-CRLF keepalive is, in my mind: it's triv= ial to construct, trivial to parse, very small and fixed size, can be separ= ated or handled at a lower layer, explicit in its use, and does not get sto= pped by a SIP-layer overload control. In short: it's a transport connectio= n-layer keepalive, no more no less. And indicating it in the Via keeps it = a hop-link thing, backwards-compatible, little or no provisioning, and with= no URI target addressing issues. >>> >>> -hadriel >>> >>> = >>> = >>> = >>>> -----Original Message----- >>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>> Sent: Wednesday, June 25, 2008 5:56 PM >>>> To: Christer Holmberg >>>> Cc: Hadriel Kaplan; Markus.Isomaki@nokia.com; = >>>> john.elwell@siemens.com; drage@alcatel-lucent.com; sip@ietf.org >>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy = >>>> use case >>>> >>>> No, not a B2BUA. Each element would have a virtual UA function "in = >>>> parallel" to its regular function (e.g. being a proxy). And indeed, = >>>> one way to implement this would be to keep either one (one way) or = >>>> two (opposite ways) flows active between them. >>>> >>>> Like so: >>>> >>>> |-----------| |-----------| >>>> | Proxy | | Proxy | >>>> |-----------| |-----------| >>>> | UA | <---------->| UA | >>>> |-----------| |-----------| >>>> >>>> Each "UA" would implement both a simple registrar and a UAC = >>>> performing registration. It could also be setup asymmetrically, = >>>> with the (smaller) IP-PBX doing a single registration towards the >>>> (bigger) Service provider network. Registration expiry would denote a = loss of connectivity. >>>> >>>> Regards, >>>> Jeroen >>>> >>>> >>>> Christer Holmberg wrote: >>>> = >>>> = >>>> = >>>>> Hi, >>>>> >>>>> So, you are proposing that each element should be a B2BUA, and = >>>>> both >>>>> = >>>>> = >>>>> = >>>> elements then register towards each other and use Outbound??? >>>> = >>>> = >>>> = >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>>> Sent: 25. kes=E4kuuta 2008 22:57 >>>>> To: Hadriel Kaplan >>>>> Cc: Markus.Isomaki@nokia.com; john.elwell@siemens.com; >>>>> drage@alcatel- >>>>> = >>>>> = >>>>> = >>>> lucent.com; sip@ietf.org; Christer Holmberg >>>> = >>>> = >>>> = >>>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: = >>>>> proxy-to-proxy use >>>>> = >>>>> = >>>>> = >>>> case >>>> = >>>> = >>>> = >>>>> Hadriel, Markus, >>>>> >>>>> Instead of standardizing keep-alives between proxies, how about we >>>>> = >>>>> = >>>>> = >>>> define a "virtual UA" on each element (similar to the one described = >>>> in >>>> = >>>> = >>>> = >>>>> RFC3261 section 16.7 point 6) to be used to provide this functionalit= y? >>>>> (using existing outbound functionality, perhaps both ways) >>>>> >>>>> Regards, >>>>> Jeroen >>>>> >>>>> Hadriel Kaplan wrote: >>>>> >>>>> = >>>>> = >>>>> = >>>>>> Yes I am of that same opinion - that any real "IP-PBX" or = >>>>>> whatever big enough NOT to be doing Registration, and to instead = >>>>>> do static >>>>>> = >>>>>> = >>>>>> = >>>> provisioning or DNS, would be given a static hole/DMZ address in = >>>> their firewall/NAT. But some of my customers have told me otherwise. >>>> (interestingly mostly in APAC region) There's also some concern = >>>> that while a static entry is there for inbound TCP connections, the = >>>> PBX creates outbound ones to the service provider which are = >>>> ephemeral port sources and need to live for very long durations = >>>> (though why they can't just do TCP keepalive is beyond me, but I'm no = expert). >>>> = >>>> = >>>> = >>>>>> But anyway, the big issue we've seen is that we need both the PBX = >>>>>> and >>>>>> = >>>>>> = >>>>>> = >>>> the service provider box to detect failure before an active = >>>> call/request attempt is made; to trigger alternate route selection = >>>> without waiting for transport failure, and as a method to detect liven= ess again and revert. >>>> Today that's almost exclusively done with Options requests as far = >>>> as I've seen, and lots of people don't seem to like that. >>>> = >>>> = >>>> = >>>>>> -hadriel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>>> = >>>>>>> -----Original Message----- >>>>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>>>> Sent: Wednesday, June 25, 2008 3:11 PM >>>>>>> To: john.elwell@siemens.com; Hadriel Kaplan; = >>>>>>> drage@alcatel-lucent.com; sip@ietf.org >>>>>>> Cc: christer.holmberg@ericsson.com >>>>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: = >>>>>>> proxy-to-proxy use case >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm a bit sceptical about the need for keep-alives between proxies. >>>>>>> It is of course entirely possible that an enterprise PBX is = >>>>>>> connected to (or peering with) a service provider proxy through = >>>>>>> a NAT and/or a firewall. However, wouldn't such a NAT or = >>>>>>> firewall be under the administration of either the enterprise = >>>>>>> itself or its ISP (who quite often would be the SIP service = >>>>>>> provider), and the required port forwardings or firewall rules coul= d be set through administration. >>>>>>> This means that there would not be need for keepalive traffic to = >>>>>>> implicitely keep the mapping/pinhole open. >>>>>>> >>>>>>> Or are there really deployment cases where there are SIP PBXs = >>>>>>> behind unadministrated NATs or firewalls? >>>>>>> >>>>>>> Wouldn't we then need keepalives for SMTP as well, or how has = >>>>>>> the e-mail infrastructure managed to solve this problem? >>>>>>> >>>>>>> Markus >>>>>>> >>>>>>> >>>>>>> >>>>>>> = >>>>>>> = >>>>>>> = >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use = >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> = >>>>>> = >>>>> = >>>>> = >>>>> = >>> = >>> = >>> = >> = >> = > > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 01:25:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063EA3A6839; Thu, 26 Jun 2008 01:25:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302083A6839 for ; Thu, 26 Jun 2008 01:25:54 -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 U-oCNEPubFgz for ; Thu, 26 Jun 2008 01:25:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C5DFC3A67C0 for ; Thu, 26 Jun 2008 01:25:49 -0700 (PDT) Received: (qmail invoked by alias); 26 Jun 2008 08:25:50 -0000 Received: from unknown (EHLO [10.183.181.77]) [192.100.124.156] by mail.gmx.net (mp013) with SMTP; 26 Jun 2008 10:25:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18zeVhURc4zFdidw/fpX1FmkQAX3b2I1Btos28dUO rbzVAZW4SsCFgA Message-ID: <4863528C.6040309@gmx.net> Date: Thu, 26 Jun 2008 11:25:48 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Elwell, John" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: sip@ietf.org, Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Comments inline: Elwell, John wrote: > Hannes, > > >> -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: 25 June 2008 14:00 >> To: Elwell, John; Paul Kyzivat >> Cc: sip@ietf.org; Dan Wing >> Subject: RE: [Sip] Toward the Evolution of SIP and Related >> Working Groups >> >> >> Consider the following scenario: >> >> +-----------+ +-----------+ >> |SIP | |SIP | >> +------>|Proxy |<---------->|Proxy |<------+ >> | |Server X | TLS |Server Y | | >> | +-----------+ +-----------+ | >> | | >> | TLS or TLS or | >> | SIP Digest SIP Digest | >> | | >> | | >> v v >> +-----------+ +-----------+ >> |SIP | |SIP | >> |User Agent | RTP |User Agent | >> |Alice | <=================================> |Bob | >> +-----------+ +-----------+ >> >> >> When there are no further proxies between X and Y then Y has the >> information that Alice was authenticated by X. Proxy Y would pass that >> info on to Bob. Bob trusts Y. >> >> Obviously, the two VoIP providers may have a far more complicated >> infrastructure with multiple proxies but they all belong to the same >> domain and could be seen from external as just one box. >> >> The same would not work when there are more proxies between X and Y. >> However, these guys that prefer such a deployment belong more to the >> chain of trust camp rather than the end-to-end / email alike peering >> camp. It is rather unlikely that you get their support for getting SIP >> Identity to work in their networks. >> >> So, do we have an indication that some folks plan to use SIP Identity >> for their deployment? >> > [JRE] Well, what about enterprise via service provider to enterprise? As > an enterprise provider, I would like to be able to use SIP identity, but > a precondition is that it gets through that intermediate service > provider(s). > > Why would like to pick a service provider in the first place? Why are they deploying B2BUAs? If you really want todo that then pick one that does not damage your security. You are the customer and you decide. If you want to pick such as service provider then why does the chain of trust not work for you? Hopefully you trust the provider you have chosen. .... just trying to figure out what the typical deployment cases are and why we don't see any of this in XMPP. > >> Wouldn't it be better to rely on something like SIP CERT for a better >> end-to-end security mechanism (ignoring for a moment that SIP >> CERT also >> uses SIP Identity for "simplified deployment" reasons whereby >> one has to >> state that the usage of SIP Identity for SUBSCRIBE/NOTIFY might have >> different B2BUA aspects). >> > [JRE] You have lost me there. What is SIP CERT? Can you point me at a > draft? > http://tools.ietf.org/html/draft-ietf-sip-certs-06 Ciao Hannes > John > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 02:10:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0485F3A68BB; Thu, 26 Jun 2008 02:10:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712393A68BB for ; Thu, 26 Jun 2008 02:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 ZQm9V2ozYYBp for ; Thu, 26 Jun 2008 02:10:48 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id EF12A3A67A8 for ; Thu, 26 Jun 2008 02:10:47 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K3200M1OC5TX3@siemenscomms.co.uk> for sip@ietf.org; Thu, 26 Jun 2008 10:10:48 +0100 (BST) Date: Thu, 26 Jun 2008 10:10:34 +0100 From: "Elwell, John" In-reply-to: <4863528C.6040309@gmx.net> To: Hannes Tschofenig Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D6EAB4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXZktqxoM0l3xgSqStTf7PGMjg8QABLgSw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> <4863528C.6040309@gmx.net> Cc: sip@ietf.org, Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hannes, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: 26 June 2008 09:26 > To: Elwell, John > Cc: Tschofenig, Hannes (NSN - FI/Espoo); Paul Kyzivat; > sip@ietf.org; Dan Wing > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > Comments inline: > > Elwell, John wrote: > > Hannes, > > > > > >> -----Original Message----- > >> From: Tschofenig, Hannes (NSN - FI/Espoo) > >> [mailto:hannes.tschofenig@nsn.com] > >> Sent: 25 June 2008 14:00 > >> To: Elwell, John; Paul Kyzivat > >> Cc: sip@ietf.org; Dan Wing > >> Subject: RE: [Sip] Toward the Evolution of SIP and Related > >> Working Groups > >> > >> > >> Consider the following scenario: > >> > >> +-----------+ +-----------+ > >> |SIP | |SIP | > >> +------>|Proxy |<---------->|Proxy |<------+ > >> | |Server X | TLS |Server Y | | > >> | +-----------+ +-----------+ | > >> | | > >> | TLS or TLS or | > >> | SIP Digest SIP Digest | > >> | | > >> | | > >> v v > >> +-----------+ +-----------+ > >> |SIP | |SIP | > >> |User Agent | RTP |User Agent | > >> |Alice | <=================================> |Bob | > >> +-----------+ +-----------+ > >> > >> > >> When there are no further proxies between X and Y then Y has the > >> information that Alice was authenticated by X. Proxy Y > would pass that > >> info on to Bob. Bob trusts Y. > >> > >> Obviously, the two VoIP providers may have a far more complicated > >> infrastructure with multiple proxies but they all belong > to the same > >> domain and could be seen from external as just one box. > >> > >> The same would not work when there are more proxies > between X and Y. > >> However, these guys that prefer such a deployment belong > more to the > >> chain of trust camp rather than the end-to-end / email > alike peering > >> camp. It is rather unlikely that you get their support for > getting SIP > >> Identity to work in their networks. > >> > >> So, do we have an indication that some folks plan to use > SIP Identity > >> for their deployment? > >> > > [JRE] Well, what about enterprise via service provider to > enterprise? As > > an enterprise provider, I would like to be able to use SIP > identity, but > > a precondition is that it gets through that intermediate service > > provider(s). > > > > > Why would like to pick a service provider in the first place? Why are > they deploying B2BUAs? > > If you really want todo that then pick one that does not damage your > security. You are the customer and you decide. > > If you want to pick such as service provider then why does > the chain of > trust not work for you? Hopefully you trust the provider you > have chosen. [JRE] I might trust my service provider, but I might not trust (or even know of) the peer enterprise's service provider. And what if the two service providers use indirect peering rather than direct peering? That is the problem, there can be just too many domains along the path of a call, particularly a call that gets forwarded. It seems too hard to figure out for every possible scenario how to get hop-by-hop to work, when an end-domain-to-end-domain solution would always work if there is no interference from intermediate domains. > > .... just trying to figure out what the typical deployment > cases are and > why we don't see any of this in XMPP. > > > > >> Wouldn't it be better to rely on something like SIP CERT > for a better > >> end-to-end security mechanism (ignoring for a moment that SIP > >> CERT also > >> uses SIP Identity for "simplified deployment" reasons whereby > >> one has to > >> state that the usage of SIP Identity for SUBSCRIBE/NOTIFY > might have > >> different B2BUA aspects). > >> > > [JRE] You have lost me there. What is SIP CERT? Can you > point me at a > > draft? > > > http://tools.ietf.org/html/draft-ietf-sip-certs-06 [JRE] I don't understand - how does sip-certs provide end-to-end authentication? It might help me to locate a certificate that is used in some authentication mechanism such as Identity, but it doesn't itself provide an authentication mechanism. John > > Ciao > Hannes > > > John > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 02:39:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5030F3A6905; Thu, 26 Jun 2008 02:39:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D3D3A692B for ; Thu, 26 Jun 2008 02:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wmuRkqXmB+SQ for ; Thu, 26 Jun 2008 02:39:01 -0700 (PDT) Received: from submit-tmp.sysedata.no (submit-tmp.sysedata.no [195.159.29.133]) by core3.amsl.com (Postfix) with ESMTP id 6A7363A6905 for ; Thu, 26 Jun 2008 02:39:01 -0700 (PDT) Received: from [82.196.214.14] (helo=[192.168.1.133]) by submit-tmp.sysedata.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KBnwU-0004xu-79; Thu, 26 Jun 2008 11:39:02 +0200 Message-ID: <486363D6.7070908@db.org> Date: Thu, 26 Jun 2008 11:39:34 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Sudhir Kumar Reddy References: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> In-Reply-To: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> X-Whitelisted: Cc: sip@ietf.org Subject: Re: [Sip] can SDP contain 2 'M' lines X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sudhir Kumar Reddy wrote: > Hi All, > > In SDP can we have two 'M' lines for re-INVITE i.e. for call hold. > > if yes what is RFC / draft > > Any response is highly appreciated > yes, please see details here: http://www.ietf.org/rfc/rfc4566.txt http://www.ietf.org/rfc/rfc3264.txt /alfred _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 03:26:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3C03A6910; Thu, 26 Jun 2008 03:26:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C07F3A6910 for ; Thu, 26 Jun 2008 03:26:19 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb7eIDzJWo-Q for ; Thu, 26 Jun 2008 03:26:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 588343A68EC for ; Thu, 26 Jun 2008 03:26:14 -0700 (PDT) Received: (qmail invoked by alias); 26 Jun 2008 10:26:16 -0000 Received: from unknown (EHLO [10.183.181.77]) [192.100.124.156] by mail.gmx.net (mp037) with SMTP; 26 Jun 2008 12:26:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19UYn9MR1tU8m0hInRreHroUyCh+H9fchu7mOfhlt LSkLKWocQ76eX2 Message-ID: <48636EC6.6010908@gmx.net> Date: Thu, 26 Jun 2008 13:26:14 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Elwell, John" References: <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> <4863528C.6040309@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6EAB4@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D6EAB4@GBNTHT12009MSX.gb002.siemens.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >> http://tools.ietf.org/html/draft-ietf-sip-certs-06 >> > [JRE] I don't understand - how does sip-certs provide end-to-end > authentication? It might help me to locate a certificate that is used in > some authentication mechanism such as Identity, but it doesn't itself > provide an authentication mechanism. > > John Two of the current proposals to fix SIP Identity combine it with DTLS-SRTP. An alternative is to use SIP CERT with DTLS-SRTP. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 05:35:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4273A6ABC; Thu, 26 Jun 2008 05:35:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192133A6ABB for ; Thu, 26 Jun 2008 05:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.042 X-Spam-Level: X-Spam-Status: No, score=-5.042 tagged_above=-999 required=5 tests=[AWL=1.557, 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 4tMAdd9qLha9 for ; Thu, 26 Jun 2008 05:35:26 -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 5CA803A6AB7 for ; Thu, 26 Jun 2008 05:35:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,708,1204531200"; d="scan'208";a="45041466" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2008 05:35:29 -0700 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 m5QCZTLV017970; Thu, 26 Jun 2008 05:35:29 -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.13.8) with ESMTP id m5QCZSK1009815; Thu, 26 Jun 2008 12:35:29 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 08:35:29 -0400 Received: from [10.86.248.191] ([10.86.248.191]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 08:35:28 -0400 Message-ID: <48638D3E.4020908@cisco.com> Date: Thu, 26 Jun 2008 08:36:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hannes Tschofenig References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> <4863528C.6040309@gmx.net> In-Reply-To: <4863528C.6040309@gmx.net> X-OriginalArrivalTime: 26 Jun 2008 12:35:28.0644 (UTC) FILETIME=[1D8EAC40:01C8D789] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=395; t=1214483729; x=1215347729; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=1BO7n6N089mj5+cEW19qCEKtIwCUnx/hBXapHlgcHQ4=; b=aXFxrzjz6S3GNwjX577UyrthPcYsRalfew4dGM1Z10wMv7jy83ap7i7S7n /bfuQ/BobGh727Gu26hanbf3V7iMgM0kAiX3aPp+mqCpjPfZJgOfi/hQU52N s2vRcQpQsZ; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, "Elwell, John" , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hannes Tschofenig wrote: > If you want to pick such as service provider then why does the chain of > trust not work for you? Hopefully you trust the provider you have chosen. Well, that seems obvious. If the SP is willing to trust *me*, then it is probably willing to trust its other customers. If I am not willing to trust its other customers, then I can't trust it. Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From c.nielson@denmarktheagency.com Thu Jun 26 05:36:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762273A686D; Thu, 26 Jun 2008 05:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.95 X-Spam-Level: X-Spam-Status: No, score=-66.95 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, 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 mAe0DF01dAP8; Thu, 26 Jun 2008 05:36:13 -0700 (PDT) Received: from r190-134-20-128.dialup.adsl.anteldata.net.uy (r190-134-20-128.dialup.adsl.anteldata.net.uy [190.134.20.128]) by core3.amsl.com (Postfix) with SMTP id 785DB28C0F9; Thu, 26 Jun 2008 05:35:49 -0700 (PDT) X-Originating-IP: 74.116.80.10 by smtp.190.134.20.128; Thu, 26 Jun 2008 08:35:54 -0500 Message-ID: From: "Charlene Hager" Reply-To: "Charlene Hager" To: send-archive@ietf.org Subject: Rolex replica is a ultimate gift Date: Thu, 26 Jun 2008 08:35:54 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://howuxipepop40.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://howuxipepop40.blogspot.com/ From sip-bounces@ietf.org Thu Jun 26 05:48:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A94928C0DE; Thu, 26 Jun 2008 05:48:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F7F3A6AC7 for ; Thu, 26 Jun 2008 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 Hjns3TViEnaL for ; Thu, 26 Jun 2008 05:48:07 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 513ED3A6AC8 for ; Thu, 26 Jun 2008 05:48:07 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K3200D1HM8451@siemenscomms.co.uk> for sip@ietf.org; Thu, 26 Jun 2008 13:48:05 +0100 (BST) Date: Thu, 26 Jun 2008 13:45:40 +0100 From: "Elwell, John" In-reply-to: <48636EC6.6010908@gmx.net> To: Hannes Tschofenig Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0D9E7B8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXd5urJVIu1Z1cSzmzhbAuAV4X0wADao5Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> <4863528C.6040309@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6EAB4@GBNTHT12009MSX.gb002.siemens.net> <48636EC6.6010908@gmx.net> Cc: sip@ietf.org, Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hannes, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: 26 June 2008 11:26 > To: Elwell, John > Cc: sip@ietf.org; Paul Kyzivat; Dan Wing > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > >> http://tools.ietf.org/html/draft-ietf-sip-certs-06 > >> > > [JRE] I don't understand - how does sip-certs provide end-to-end > > authentication? It might help me to locate a certificate > that is used in > > some authentication mechanism such as Identity, but it > doesn't itself > > provide an authentication mechanism. > > > > John > > Two of the current proposals to fix SIP Identity combine it with > DTLS-SRTP. An alternative is to use SIP CERT with DTLS-SRTP. [JRE] So you propose having certificates in the UAs, and have these deployed using sip-certs? I wonder whether this meets the requirement: "R-CERTS: The key management protocol MUST NOT require that end-users obtain credentials (certificates or private keys) from a third- party trust anchor." Does the credential server count as a third party trust anchor? If so, we would not meet this requirement. But assuming the server is in the same domain as the UAs it supplies credentials to, it is probably not considered third party and probably meets the spirit of the requirement. Also, I think there would need to be some adaptation of sip-certs. For example, sip-certs explicitly says it is for use with S/MIME. Also, as you pointed out, this too relies on RFC 4474 (but in a NOTIFY). Maybe HTTPS would be more appropriate for this part. If Bob has several UAs, each would receive the same private key and cert from the credentials server. I don't know whether this has any implications for DTLS-SRTP (c.f., self-signed certs, which would doubtless be different in each UA). Similarly to some of the other alternatives, this would provide an authenticated identity for DTLS-SRTP, but not for calls that don't use DTLS-SRTP, and also not for SIP requests not related to calls such as MESSAGE, SUBSCRIBE, NOTIFY, and also not for mid-dialog requests that don't include SDP (where the certificate fingerprint resides), such as BYE, offerless UPDATE, the dreaded INFO. Intermediate domains would need to pass SUBSCRIBE/NOTIFY requests - this might be almost as big an ask as requiring them not to interfere with an RFC 4474 certificate. Alternatively, perhaps enterprises etc. that insist on intermediaries for calls might open their doors to direct peering for SUBSCRIBE/NOTIY. I can still see issues with the actual identity. For example, with an E.164 number, I send +1234@mydomain.com in From or PAI, but by the time it reaches you it has been changed to +1234@serviceprovider.net, so your UA would send the SUBSCRIBE request to +1234@mydomain.com, and that would somehow need to reach +1234@mydomain.com. But yes, this is an alternative approach worthy of further exploration. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 05:58:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87CF3A6949; Thu, 26 Jun 2008 05:58:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9A63A6949 for ; Thu, 26 Jun 2008 05:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwkpireKGD-i for ; Thu, 26 Jun 2008 05:58:41 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 493A13A6909 for ; Thu, 26 Jun 2008 05:58:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5QCwdgn027502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 14:58:39 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5QCwYth009909; Thu, 26 Jun 2008 14:58:39 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 14:58:36 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 14:58:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 15:58:33 +0300 Message-ID: In-Reply-To: <48638D3E.4020908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Identity Thread-Index: AcjXiSiUwkn5+tR0RaeaxNPjg9fzXQAAPWTA References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net><4863528C.6040309@gmx.net> <48638D3E.4020908@cisco.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Paul Kyzivat" , "Hannes Tschofenig" X-OriginalArrivalTime: 26 Jun 2008 12:58:35.0411 (UTC) FILETIME=[58228630:01C8D78C] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-15994.007 X-TM-AS-Result: No--18.086000-8.000000-31 Cc: sip@ietf.org, "Elwell, John" , Dan Wing Subject: [Sip] SIP Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org [changed the title since we drifted a bit away from the original question] I am trying to figure out where the problems are: The SIPit 21 report http://www.ietf.org/mail-archive/web/sip/current/msg21291.html indicated that SIP Identity was available with 12% of the implementations. (Not sure what that actually means since one would have to look at the details.) The SIPit 22 report http://www.ietf.org/mail-archive/web/sip/current/msg23285.html says 16% identity (But there were no Identity servers at the event) Maybe this means that nobody showed up that has implemented the Authentication Service but I hope that someone has implemented it somewhere. ~15 % is not a large number; but it's a start. Now, it would be interesting to hear whether these guys have actually ever turned it on and used it. What was their experience? Did they indeed encounter problems with certain SBC configurations? Would more folks use it when some of the weaknesses on the E.164 number usage are documented? Would more folks use it when combined with DTLS-SRTP (as proposed in two documents)? How would a change to the signature algorithm impact the situation? Ciao Hannes >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of ext Paul Kyzivat >Sent: 26 June, 2008 15:36 >To: Hannes Tschofenig >Cc: sip@ietf.org; Elwell, John; Dan Wing >Subject: Re: [Sip] Toward the Evolution of SIP and Related >Working Groups > > > >Hannes Tschofenig wrote: > >> If you want to pick such as service provider then why does the chain >> of trust not work for you? Hopefully you trust the provider >you have chosen. > >Well, that seems obvious. If the SP is willing to trust *me*, >then it is probably willing to trust its other customers. If I >am not willing to trust its other customers, then I can't trust it. > > Paul >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 08:24:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3CD28C162; Thu, 26 Jun 2008 08:24:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D990128C162 for ; Thu, 26 Jun 2008 08:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 IgEPrZlYe9Sk for ; Thu, 26 Jun 2008 08:24:30 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 064C028C160 for ; Thu, 26 Jun 2008 08:24:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,709,1204531200"; d="scan'208";a="16813575" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2008 08:24:27 -0700 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 m5QFORCZ022223; Thu, 26 Jun 2008 08:24:27 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5QFOQc8028925; Thu, 26 Jun 2008 15:24:26 GMT From: "Dan Wing" To: "'Elwell, John'" , "'Hannes Tschofenig'" References: <485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com><5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com><08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net><05d001c8d628$98c91510$c2f0200a@cisco.com><48614E77.9010904@alcatel-lucent.com><071b01c8d63f$2e39e910$c2f0200a@cisco.com><4861675E.1010507@alcatel-lucent.com><076c01c8d643$85c210a0$c2f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net><4862347B.8080405@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net><0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net><4863528C.6040309@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0D6EAB4@GBNTHT12009MSX.gb002.siemens.net><48636EC6.6010908@gmx.net> <0D5F89FAC29E 2C41B98A6A762007F5D0 D9E7B8@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 26 Jun 2008 08:24:26 -0700 Message-ID: <087101c8d7a0$b8a43e90$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjXd5urJVIu1Z1cSzmzhbAuAV4X0wADao5QAAbWGQA= In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0D9E7B8@GBNTHT12009MSX.gb002.siemens.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=514; t=1214493867; x=1215357867; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=wIx6F608dKiAuMpzSajKkW1ql3T8BGwsXDdAGfSiM1w=; b=s5o54X/vAC5lV3PEb2MDKZdkBaUutY2/RsY3EI5McYcO4yAkFZDUguDEPW u7XVXxHh+pb/5Nql9vl05Mnwq6pxG7m9K9A/oFbveq6zOdpwtmESBMbfx6dQ 73oWUysxTb5FLgiaMppyo8Ad0Ts6UeENGP/t2fL2J9rNm+SsD0NXQ=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John Elwell wrote: > I can still see issues with the actual identity. For example, with an > E.164 number, I send +1234@mydomain.com in From or PAI, but > by the time it reaches you it has been changed to > +1234@serviceprovider.net, so your > UA would send the SUBSCRIBE request to +1234@mydomain.com, and that > would somehow need to reach +1234@mydomain.com. Which brings us back into draft-wing-sip-e164-rrc-01.txt territory. (Not a bad thing, in my mind; I just wanted to point it out). -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 08:47:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5236228C178; Thu, 26 Jun 2008 08:47:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972D428C134 for ; Thu, 26 Jun 2008 08:47:04 -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 bX2iOo-QJJhN for ; Thu, 26 Jun 2008 08:47:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 8239928C178 for ; Thu, 26 Jun 2008 08:47:00 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so66866rvf.49 for ; Thu, 26 Jun 2008 08:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:mime-version:content-type; bh=GOjeogVo60bhqjj0MBH8Me7KZFOVhP7sTG3CcI5LRI0=; b=ld2OtMBAICcIiwINT4JXDBbNGw507BGWNQc/zu86Nbl1BQzt8V3FqY5jrgzODjslxM 4Zh5chy2B30hIyjRh7eByBKpaEpOdqMOVB5LQfVaeETSOXGIipm1AS+i5Er6vbaUdVf+ Wj8lXPR9RsAMv3eS4V791Sf1TGvuYXUw6qrN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type; b=TrX3ySzHid8oAMaB9jDVY5ts9D0pzOKjZyqlvVK0On11Fick7t0LjjorE+f9uUIL1V 6dpbSmEZoWtmdBQXAsguaUP35u/z3eVZx4WyL4ynvMc6RWPWKidFG7As6D7czpr9GrqI 3x75WWxu14WKae0+/LZWrp68MHsY+3W5g6Y1Q= Received: by 10.141.162.16 with SMTP id p16mr21905rvo.243.1214495222913; Thu, 26 Jun 2008 08:47:02 -0700 (PDT) Received: by 10.141.194.21 with HTTP; Thu, 26 Jun 2008 08:47:02 -0700 (PDT) Message-ID: <6c1120b40806260847o3c847e77h6f491e3c992b8e75@mail.gmail.com> Date: Thu, 26 Jun 2008 16:47:02 +0100 From: "rvmithra@gmail.com" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] Client sending 'a=inactive' when put on hold X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rvmithra@gmail.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1173877142==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1173877142== Content-Type: multipart/alternative; boundary="----=_Part_5818_6908651.1214495222903" ------=_Part_5818_6908651.1214495222903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Is there any Softphone client which sends media attributes: 'a= inactive' when the call is put on hold? Tried SJ phone, Xlite, BT softphone and all of these send 'a=sendonly'. The client should be capable of reg with SER. This is to test the msg handling by a SBC, so SIPp can't be used as i need to check the RTP flow as well. Cheers, Vishnu ------=_Part_5818_6908651.1214495222903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
   Is there any Softphone client which sends media attributes: 'a= inactive'
   when the call is put on hold?
   Tried SJ phone, Xlite, BT softphone and all of these send 'a=sendonly'.
   The client should be capable of reg with SER. This is to test the msg
   handling by a SBC, so SIPp can't be used as i need to check the RTP flow as
   well.

   Cheers,
   Vishnu
 
------=_Part_5818_6908651.1214495222903-- --===============1173877142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1173877142==-- From sip-bounces@ietf.org Thu Jun 26 08:57:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CE03A6A90; Thu, 26 Jun 2008 08:57:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F3F3A6943; Thu, 26 Jun 2008 08:57:34 -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_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 PvpsYi9bIUKh; Thu, 26 Jun 2008 08:57:33 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 5101A3A6979; Thu, 26 Jun 2008 08:57:33 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 26 Jun 2008 17:57:35 +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); Thu, 26 Jun 2008 17:57:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 17:56:44 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD402CA8FB4@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progress on draft-jesske-sipping-etsi-ngn-reason-03 Thread-Index: AcjXpTpzm2BVB7zxQUKPPgODM8AD4g== From: "Jesske, R" To: , X-OriginalArrivalTime: 26 Jun 2008 15:57:34.0560 (UTC) FILETIME=[592A9E00:01C8D7A5] Subject: [Sip] Progress on draft-jesske-sipping-etsi-ngn-reason-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0153206829==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0153206829== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D7A5.3C93B30E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D7A5.3C93B30E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, at the moment I'm looking for comments on the = http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-03.txt, to = progress the work on that.=20 The reason in responses will be used within the IMS so progress of this = draft is needed. =20 Also I've got the comment that the work should be shifted to SIP WG. =20 Thoughts? Comments? =20 Best Regards =20 Roland =20 = =20 Deutsche Telekom AG=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:=20 Deutsche Telekom AG Aufsichtsrat: Prof. Dr Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Karl-Gerhard Eick (stellvertretender Vorsit-zender), Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794,=20 Sitz der Gesellschaft: Bonn=20 WEEE-Reg.-Nr.: DE50478376=20 ***************************************************************=20 Deutsche Telekom AG=20 Supervisory Board: Prof. Dr Ulrich Lehner (Chairman)=20 Board of Management: Ren=E9 Obermann (Chairman),=20 Dr. Karl-Gerhard Eick (Deputy Chairman),=20 Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Commercial register: Amtsgericht Bonn HRB 6794,=20 corporate seat: Bonn=20 WEEEreg.no: DE50478376=20 =20 ------_=_NextPart_001_01C8D7A5.3C93B30E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
at the = moment I'm=20 looking for comments on the http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-03.txt= ,=20 to progress the work on that. 
The = reason in=20 responses will be used within the IMS so progress of this draft is=20 needed.
 
Also = I've got the=20 comment that the work should be shifted to SIP WG.
 
Thoughts?=20 Comments?
 
Best=20 Regards
 
Roland
 
 
 

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

http://www.telekom.de=20

Registerrechtliche Unternehmensangaben:=20
Deutsche Telekom=20 AG
Aufsichtsrat: Prof. Dr Ulrich Lehner=20 (Vorsitzender)
Vorstand: Ren=E9 Obermann=20 (Vorsitzender),
Dr.=20 Karl-Gerhard Eick (stellvertretender Vorsit-zender),
Hamid Akhavan, = Reinhard=20 Clemens, Timotheus H=F6ttges, Thomas Sattelberger
Handelsregister: Amtsgericht Bonn HRB 6794,
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.:=20 DE50478376
***************************************************************= =20
Deutsche Telekom AG
Supervisory=20 Board: Prof. Dr Ulrich Lehner=20 (Chairman)
Board of Management: = Ren=E9 Obermann=20 (Chairman),
Dr. Karl-Gerhard Eick (Deputy=20 Chairman),
Hamid Akhavan, Reinhard = Clemens,=20 Timotheus H=F6ttges,  Thomas = Sattelberger
Commercial=20 register: Amtsgericht Bonn HRB 6794,
corporate seat:=20 Bonn
WEEEreg.no: = DE50478376

 
------_=_NextPart_001_01C8D7A5.3C93B30E-- --===============0153206829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0153206829==-- From sip-bounces@ietf.org Thu Jun 26 09:31:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C3E28C11B; Thu, 26 Jun 2008 09:31:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93EFA3A69C9; Thu, 26 Jun 2008 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 T5LsLp5j09WH; Thu, 26 Jun 2008 09:31:23 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 427303A6ADC; Thu, 26 Jun 2008 09:30:46 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5QGUiA17763; Thu, 26 Jun 2008 16:30:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 11:27:53 -0500 Message-ID: In-Reply-To: <9886E5FCA6D76549A3011068483A4BD402CA8FB4@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 Thread-Index: AcjXpTpzm2BVB7zxQUKPPgODM8AD4gAAmbew References: <9886E5FCA6D76549A3011068483A4BD402CA8FB4@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: "Jesske, R" , , Subject: Re: [Sip] [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0056878540==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0056878540== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D7A9.F4541B90" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D7A9.F4541B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the requirements in this document are agreed in SIPPING WG (the doc = seems really sparse in terms of requirements at this point), THEN the = work could progress to the SIP WG. But, we first need to agree = requirements.=20 =20 I see your applicability section and earlier there's reference to the = TISPAN requirements document (which is expired). Can you pull the = specific requirements from that document into this one or at least let's = discuss on the list? In scanning that requirements document, it's not = clear to me which requirement this header is intended to meet. If it is = intended to support many of those simulation services, then that should = be stated. And, so I believe this brings us to the question as to = whether we are going to support those simulation services?=20 =20 Given that many of those services are being developed in BLISS, would it = not be prudent to wait until we see the details of those services to = suggest that we need this header? Or has that already been discussed = and I've missed it? If so, please provide us a pointer to that = discussion. In that case, we could agree that SIPPING WG does not need = to spend much time on the requirements and we could more easily agree = that this could move to SIP WG to be completed. Or, are there other = requirements for this header? =20 =20 And, just for clarification, are their plans to progress that other = general requirements document or should the WG treat that document as we = did in the past the 3GPP requirements document as a working document, = from which to pull specific requirements and solution proposals? My = inclination would be the latter, but we need feedback from the WG = (including ETSI/TISPAN/IMS folks, of course).=20 =20 And, just a note, I bcc'ed SIP WG on this thread, since I would prefer = this thread stay only in SIPPING WG for now, in particular just to keep = down the volume on the SIP list, which is already really busy. =20 Thanks, Mary.=20 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf Of Jesske, R Sent: Thursday, June 26, 2008 10:57 AM To: sipping@ietf.org; sip@ietf.org Subject: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 Dear all, at the moment I'm looking for comments on the = http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-03.txt, to = progress the work on that.=20 The reason in responses will be used within the IMS so progress of this = draft is needed. =20 Also I've got the comment that the work should be shifted to SIP WG. =20 Thoughts? Comments? =20 Best Regards =20 Roland =20 =20 =20 Deutsche Telekom AG=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:=20 Deutsche Telekom AG Aufsichtsrat: Prof. Dr Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Karl-Gerhard Eick (stellvertretender Vorsit-zender), Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794,=20 Sitz der Gesellschaft: Bonn=20 WEEE-Reg.-Nr.: DE50478376=20 ***************************************************************=20 Deutsche Telekom AG=20 Supervisory Board: Prof. Dr Ulrich Lehner (Chairman)=20 Board of Management: Ren=E9 Obermann (Chairman),=20 Dr. Karl-Gerhard Eick (Deputy Chairman),=20 Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Commercial register: Amtsgericht Bonn HRB 6794,=20 corporate seat: Bonn=20 WEEEreg.no: DE50478376=20 =20 ------_=_NextPart_001_01C8D7A9.F4541B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If the requirements in this document are = agreed in=20 SIPPING WG (the doc seems really sparse in terms of requirements at this = point),=20 THEN the work could progress to the SIP WG. But, we first need to agree=20 requirements.
 
I see your applicability section and earlier = there's=20 reference to the TISPAN requirements document (which is expired). Can = you pull=20 the specific requirements from that document into this one or at least = let's=20 discuss on the list?  In scanning that requirements document, it's = not=20 clear to me which requirement this header is intended to meet. If it is = intended=20 to support many of those simulation services, then that should be = stated. And,=20 so I believe this brings us to the question as to whether we are going = to=20 support those simulation services?
 
Given that many of those services are being = developed=20 in BLISS, would it not be prudent to wait until we see the details of = those=20 services to suggest that we need this header?  Or has that already = been=20 discussed and I've missed it? If so, please provide us a pointer to that = discussion.  In that case, we could agree that SIPPING WG does not = need to=20 spend much time on the requirements and we could more easily agree that = this=20 could move to SIP WG to be completed.  Or, are there other = requirements for=20 this header? 
 
And, just for clarification, are their plans = to=20 progress that other general requirements document or should the WG treat = that=20 document as we did in the past the 3GPP requirements document as a = working=20 document, from which to pull specific requirements and solution = proposals? =20 My inclination would be the latter, but we need feedback from the WG = (including=20 ETSI/TISPAN/IMS folks, of course).
 
And, just a note, I bcc'ed SIP WG on this = thread, since=20 I would prefer this thread stay only in SIPPING WG for now, in = particular just=20 to keep down the volume on the SIP list, which is already really=20 busy.
 
Thanks,
Mary.

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Jesske, = R
Sent:=20 Thursday, June 26, 2008 10:57 AM
To: sipping@ietf.org;=20 sip@ietf.org
Subject: [Sipping] Progress on=20 draft-jesske-sipping-etsi-ngn-reason-03

Dear=20 all,
at the = moment I'm=20 looking for comments on the http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-03.txt= ,=20 to progress the work on that. 
The = reason in=20 responses will be used within the IMS so progress of this draft is=20 needed.
 
Also = I've got the=20 comment that the work should be shifted to SIP WG.
 
Thoughts?=20 Comments?
 
Best=20 Regards
 
Roland
 
 
 

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

http://www.telekom.de=20

Registerrechtliche Unternehmensangaben:=20
Deutsche Telekom=20 AG
Aufsichtsrat: Prof. Dr Ulrich Lehner=20 (Vorsitzender)
Vorstand: Ren=E9 Obermann=20 (Vorsitzender),
Dr.=20 Karl-Gerhard Eick (stellvertretender Vorsit-zender),
Hamid Akhavan, = Reinhard=20 Clemens, Timotheus H=F6ttges, Thomas Sattelberger
Handelsregister: Amtsgericht Bonn HRB 6794,
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.:=20 DE50478376
***************************************************************= =20
Deutsche Telekom AG
Supervisory=20 Board: Prof. Dr Ulrich Lehner=20 (Chairman)
Board of Management: = Ren=E9 Obermann=20 (Chairman),
Dr. Karl-Gerhard Eick (Deputy=20 Chairman),
Hamid Akhavan, Reinhard = Clemens,=20 Timotheus H=F6ttges,  Thomas = Sattelberger
Commercial=20 register: Amtsgericht Bonn HRB 6794,
corporate seat:=20 Bonn
WEEEreg.no: = DE50478376

 
------_=_NextPart_001_01C8D7A9.F4541B90-- --===============0056878540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0056878540==-- From sip-bounces@ietf.org Thu Jun 26 09:32:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D123A695F; Thu, 26 Jun 2008 09:32:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932F93A69EF for ; Thu, 26 Jun 2008 09:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 QJ+gHmft1LlW for ; Thu, 26 Jun 2008 09:32:50 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AFC723A695F for ; Thu, 26 Jun 2008 09:32:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,709,1204531200"; d="scan'208";a="16832992" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2008 09:32:54 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5QGWs43025042; Thu, 26 Jun 2008 09:32:54 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5QGWrLj019228; Thu, 26 Jun 2008 16:32:53 GMT From: "Dan Wing" To: "'Sudhir Kumar Reddy'" , References: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> Date: Thu, 26 Jun 2008 09:32:52 -0700 Message-ID: <002201c8d7aa$47de9200$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjXVrL6BXON93YcRI+r/WrM/OqSJQAUzlKw In-Reply-To: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=509; t=1214497974; x=1215361974; c=relaxed/simple; s=sjdkim4002; 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[Sip]=20can=20SDP=20contain=202=20'M'=2 0lines |Sender:=20; bh=RJu2b3cvES8todPAqL73FjNMH2EDvzG3LTCml/KY6YU=; b=dAPMiEGXt/jfn2RtkTVsDDi0Xv5Ow+ytwzdmere5q4f6iOx+tXOjzX7n7d ZRs8iSRx7A/XgMSD+bb0lN9CHouP1pKUpscKN6q8mQsR1Tht83B2CzzAZIxG uEW+YdJzqU; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] can SDP contain 2 'M' lines X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Sudhir Kumar Reddy > Sent: Wednesday, June 25, 2008 11:34 PM > To: sip@ietf.org > Subject: [Sip] can SDP contain 2 'M' lines > > Hi All, > > In SDP can we have two 'M' lines for re-INVITE i.e. for call hold. > > if yes what is RFC / draft I have seen two responses that answer your first question and say 'yes'. However, multiple m= lines are not used to put a call on hold. -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 09:35:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE993A6A42; Thu, 26 Jun 2008 09:35:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706F83A6A3A for ; Thu, 26 Jun 2008 09:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 hARHFZc3tCCN for ; Thu, 26 Jun 2008 09:35:46 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id DBE5F3A6818 for ; Thu, 26 Jun 2008 09:35:45 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5QGZkP26291 for ; Thu, 26 Jun 2008 16:35:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 11:33:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 Thread-Index: AcjXpTpzm2BVB7zxQUKPPgODM8AD4gAAmbewAACZifA= References: <9886E5FCA6D76549A3011068483A4BD402CA8FB4@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: Subject: Re: [Sip] [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936807513==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0936807513== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D7AA.AB0E21DC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D7AA.AB0E21DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, =20 Just to get this queued since I've not yet seen a posting to SIP WG on this topic, my attempt at bcc'ing SIP and keeping this discussion on SIPPING only didn't work (I think I forgot to delete SIP in the too ;( =20 =20 But, please note that I would prefer (barring any disagreement from SIP chairs) to keep this discussion on the SIPPING WG mailing list for now. =20 Thanks, Mary.=20 ------_=_NextPart_001_01C8D7AA.AB0E21DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
Just to get this queued since I've not yet = seen a=20 posting to SIP WG on this topic, my attempt at bcc'ing SIP and keeping = this=20 discussion on SIPPING only didn't work (I think I forgot to delete SIP = in the=20 too ;( 
 
But, please note that I would prefer (barring = any=20 disagreement from SIP chairs) to keep this discussion on the SIPPING WG = mailing=20 list for now.
 
Thanks,
Mary.
------_=_NextPart_001_01C8D7AA.AB0E21DC-- --===============0936807513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0936807513==-- From sip-bounces@ietf.org Thu Jun 26 10:19:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCE03A6954; Thu, 26 Jun 2008 10:19:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28933A6947 for ; Thu, 26 Jun 2008 10:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Z7IAy6NEqL0X for ; Thu, 26 Jun 2008 10:19:23 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A33DB3A68E3 for ; Thu, 26 Jun 2008 10:19:23 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5QHID6q004245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Jun 2008 12:18:15 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <48638D3E.4020908@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 26 Jun 2008 12:18:08 -0500 References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> <4863528C.6040309@gmx.net> <48638D3E.4020908@cisco.com> X-Mailer: Apple Mail (2.924) Cc: sip@ietf.org, "Elwell, John" , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jun 26, 2008, at 7:36 AM, Paul Kyzivat wrote: > > > Hannes Tschofenig wrote: > >> If you want to pick such as service provider then why does the >> chain of trust not work for you? Hopefully you trust the provider >> you have chosen. > > Well, that seems obvious. If the SP is willing to trust *me*, then > it is probably willing to trust its other customers. If I am not > willing to trust its other customers, then I can't trust it. > I believe that my service provider has illegally collaborated with a rogue government organization to turn over call records in violation of federal law, and that when they got caught doing it, were able to lobby for special protections. They enjoy a legally-protected near monopoly when they ought to be up against the wall for treason, having conspired to violate the national constitution. I might have to do business with the, but why the heck should I trust them? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 10:20:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637593A6947; Thu, 26 Jun 2008 10:20:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D666C3A6947 for ; Thu, 26 Jun 2008 10:20:49 -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.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 kQXRtNGThjgm for ; Thu, 26 Jun 2008 10:20:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id BDE6E3A68E3 for ; Thu, 26 Jun 2008 10:20:45 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m5QHJq7D001670 for ; Thu, 26 Jun 2008 12:20:45 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 12:19:48 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 19:19:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 19:19:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800209BEAD@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] [Sipping] Progress ondraft-jesske-sipping-etsi-ngn-reason-03 Thread-Index: AcjXpTpzm2BVB7zxQUKPPgODM8AD4gAAmbewAACZifAAAad/0A== References: <9886E5FCA6D76549A3011068483A4BD402CA8FB4@S4DE8PSAAQB.mitte.t-com.de> From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 26 Jun 2008 17:19:46.0660 (UTC) FILETIME=[D4ED5A40:01C8D7B0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Sip] [Sipping] Progress ondraft-jesske-sipping-etsi-ngn-reason-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1061096297==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1061096297== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D7B0.D482ADBD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D7B0.D482ADBD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable (As SIP WG co chair) =20 Please respond to this thread on the SIPPING list. =20 As Mary has indicated, SIPPING have to agree the requirements and then SIP can consider how best to develop the extensions. =20 regards =20 Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 26, 2008 5:33 PM To: sip@ietf.org Subject: Re: [Sip] [Sipping] Progress ondraft-jesske-sipping-etsi-ngn-reason-03 =09 =09 Hi folks, =20 Just to get this queued since I've not yet seen a posting to SIP WG on this topic, my attempt at bcc'ing SIP and keeping this discussion on SIPPING only didn't work (I think I forgot to delete SIP in the too ;( =20 =20 But, please note that I would prefer (barring any disagreement from SIP chairs) to keep this discussion on the SIPPING WG mailing list for now. =20 Thanks, Mary.=20 ------_=_NextPart_001_01C8D7B0.D482ADBD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
(As SIP WG co chair)
 
Please respond to this thread on the SIPPING=20 list.
 
As Mary has indicated, SIPPING have to agree = the=20 requirements and then SIP can consider how best to develop the=20 extensions.
 
regards
 
Keith

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent:=20 Thursday, June 26, 2008 5:33 PM
To: = sip@ietf.org
Subject:=20 Re: [Sip] [Sipping] Progress=20 ondraft-jesske-sipping-etsi-ngn-reason-03

Hi folks,
 
Just to get this queued since I've not yet = seen a=20 posting to SIP WG on this topic, my attempt at bcc'ing SIP and keeping = this=20 discussion on SIPPING only didn't work (I think I forgot to delete SIP = in the=20 too ;( 
 
But, please note that I would prefer = (barring any=20 disagreement from SIP chairs) to keep this discussion on the SIPPING = WG=20 mailing list for now.
 
Thanks,
Mary. =
------_=_NextPart_001_01C8D7B0.D482ADBD-- --===============1061096297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1061096297==-- From sip-bounces@ietf.org Thu Jun 26 11:22:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20403A69C9; Thu, 26 Jun 2008 11:22:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267413A69EF for ; Thu, 26 Jun 2008 11:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.649 X-Spam-Level: X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 mD8c1AnBa01n for ; Thu, 26 Jun 2008 11:22:50 -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 4C4903A69C9 for ; Thu, 26 Jun 2008 11:22:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,709,1204531200"; d="scan'208";a="45214184" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2008 11:22:53 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5QIMrLO029596; Thu, 26 Jun 2008 11:22:53 -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.13.8) with ESMTP id m5QIMic0023976; Thu, 26 Jun 2008 18:22:53 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.1830); Thu, 26 Jun 2008 14:22:50 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 14:22:50 -0400 Message-ID: <4863DEA9.2090202@cisco.com> Date: Thu, 26 Jun 2008 14:23:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dean Willis References: <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> <4863528C.6040309@gmx.net> <48638D3E.4020908@cisco.com> In-Reply-To: X-OriginalArrivalTime: 26 Jun 2008 18:22:50.0410 (UTC) FILETIME=[A437C8A0:01C8D7B9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1150; t=1214504573; x=1215368573; c=relaxed/simple; s=sjdkim2002; 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[Sip]=20Toward=20the=20Evolution=20of=2 0SIP=20and=20Related=20Working=20Groups |Sender:=20; bh=dMvmjCUCiR+U0LMSBzFv6AUdOHqCROMkN5EP68mEe2U=; b=LEg9+ygWzrmWURxb1ZMrnxa43eO1qClqHCgNy58uiG+nyjSokwF0w+6aqi WEsWKEUkyy7Qps3zlvS0z49TGm0BjEOUik+Q/K+jfE2cNEeMydsA028Apf8V a0pzp2yMVh; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, "Elwell, John" , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Amen! Paul (That was legally protected religious speech - about as religious as you will ever get from me.) Dean Willis wrote: > > On Jun 26, 2008, at 7:36 AM, Paul Kyzivat wrote: > >> >> >> Hannes Tschofenig wrote: >> >>> If you want to pick such as service provider then why does the chain >>> of trust not work for you? Hopefully you trust the provider you have >>> chosen. >> >> Well, that seems obvious. If the SP is willing to trust *me*, then it >> is probably willing to trust its other customers. If I am not willing >> to trust its other customers, then I can't trust it. >> > > I believe that my service provider has illegally collaborated with a > rogue government organization to turn over call records in violation of > federal law, and that when they got caught doing it, were able to lobby > for special protections. They enjoy a legally-protected near monopoly > when they ought to be up against the wall for treason, having conspired > to violate the national constitution. > > I might have to do business with the, but why the heck should I trust them? > > -- > Dean > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 26 14:24:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096AF3A69D3; Thu, 26 Jun 2008 14:24:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDAC23A69D8 for ; Thu, 26 Jun 2008 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 sLEwkIaBWH76 for ; Thu, 26 Jun 2008 13:59:07 -0700 (PDT) Received: from outbound-mail-103.bluehost.com (outbound-mail-103.bluehost.com [69.89.22.13]) by core3.amsl.com (Postfix) with SMTP id 50ACC3A688D for ; Thu, 26 Jun 2008 13:59:07 -0700 (PDT) Received: (qmail 29939 invoked by uid 0); 26 Jun 2008 20:59:05 -0000 Received: from unknown (HELO box6.bluehost.com) (69.89.30.146) by outboundproxy3.bluehost.com with SMTP; 26 Jun 2008 20:59:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sinnreich.net; h=Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding:X-Identified-User:DomainKey-Status; b=tg9/ozZmFwPIa8AZdm2sAENBKny23KYFqagYD/XGa4u4tGUajaPF3SXWRRfkeYIxWX7QAmaenNnzIJUPcCxcx21blYqHsZ4UZEJvs+zJ/7W1uJ3ks9YMMN4ZCbz/ZA1Q; Received: from 99-204-237-228.area1.spcsdns.net ([99.204.237.228]) by box6.bluehost.com with esmtpa (Exim 4.68) (envelope-from ) id 1KByYZ-0001Bj-Hc; Thu, 26 Jun 2008 14:59:04 -0600 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 26 Jun 2008 13:58:52 -0700 From: "henry@sinnreich.net" To: Paul Kyzivat , Dean Willis Message-ID: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXz3AprkQaKud8JEKExRf2iorQfA== In-Reply-To: <4863DEA9.2090202@cisco.com> Mime-version: 1.0 X-Identified-User: {32212:box6.bluehost.com:sinnreic:sinnreich.net} {sentby:smtp auth 99.204.237.228 authed with henry@sinnreich.net} DomainKey-Status: no signature X-Mailman-Approved-At: Thu, 26 Jun 2008 14:24:09 -0700 Cc: sip@ietf.org, "Elwell, John" , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Trusting service providers? >> I believe that my service provider has illegally collaborated with a >> rogue government organization to turn over call records Here is what happens elsewhere as well, in this instance without any government involvement: Germany fuming at Telekom's spy scandal http://www.upi.com/Emerging_Threats/2008/05/27/Germany_fuming_at_Telekoms_sp y_scandal/UPI-56191211919425/ Henry On 6/26/08 11:23 AM, "Paul Kyzivat" wrote: > Amen! > > Paul > > (That was legally protected religious speech - about as religious as you > will ever get from me.) > > Dean Willis wrote: >> >> On Jun 26, 2008, at 7:36 AM, Paul Kyzivat wrote: >> >>> >>> >>> Hannes Tschofenig wrote: >>> >>>> If you want to pick such as service provider then why does the chain >>>> of trust not work for you? Hopefully you trust the provider you have >>>> chosen. >>> >>> Well, that seems obvious. If the SP is willing to trust *me*, then it >>> is probably willing to trust its other customers. If I am not willing >>> to trust its other customers, then I can't trust it. >>> >> >> I believe that my service provider has illegally collaborated with a >> rogue government organization to turn over call records in violation of >> federal law, and that when they got caught doing it, were able to lobby >> for special protections. They enjoy a legally-protected near monopoly >> when they ought to be up against the wall for treason, having conspired >> to violate the national constitution. >> >> I might have to do business with the, but why the heck should I trust them? >> >> -- >> Dean >> >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 00:00:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DB63A6A93; Fri, 27 Jun 2008 00:00:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477233A68F8 for ; Fri, 27 Jun 2008 00:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 E7dVCHBS2JrS for ; Fri, 27 Jun 2008 00:00:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 7175B3A6407 for ; Fri, 27 Jun 2008 00:00:39 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m5R6xvUH017756 for ; Fri, 27 Jun 2008 02:00:40 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 02:00:22 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 09:00:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Jun 2008 09:00:20 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800209BF0A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF meeting scheduling Thread-Index: AcjYG3FVU/xEi5INT+SRbVg00Wx7zA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 27 Jun 2008 07:00:20.0725 (UTC) FILETIME=[76B77A50:01C8D823] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Sip] IETF meeting scheduling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) I would ask you to be aware that the current scheduling of the various WG in Dublin is subject to considerable change. Due to the need to schedule 3 BOFs and at least one WG getting their request in late, things are going to have to move around a lot. You can expect that the RAI sessions will be wall to wall, including Friday morning. Please make sure your travel arrangements accommodate this. Regards Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 00:27:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBD93A67E9; Fri, 27 Jun 2008 00:27:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CEA3A67E9 for ; Fri, 27 Jun 2008 00:27:27 -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 1RLwlQ-06qUe for ; Fri, 27 Jun 2008 00:27:26 -0700 (PDT) Received: from fafnir.androme.com (fafnir.androme.com [62.58.96.158]) by core3.amsl.com (Postfix) with ESMTP id C5EA73A6407 for ; Fri, 27 Jun 2008 00:27:25 -0700 (PDT) Received: by fafnir.androme.com (Postfix, from userid 1003) id C4619B9859E; Fri, 27 Jun 2008 09:27:28 +0200 (CEST) Message-ID: <48649660.2070003@androme.com> Date: Fri, 27 Jun 2008 09:27:28 +0200 From: Sigrid Thijs User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: rvmithra@gmail.com References: <6c1120b40806260847o3c847e77h6f491e3c992b8e75@mail.gmail.com> In-Reply-To: <6c1120b40806260847o3c847e77h6f491e3c992b8e75@mail.gmail.com> Cc: sip@ietf.org Subject: Re: [Sip] Client sending 'a=inactive' when put on hold X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, rvmithra@gmail.com wrote: > Hi, > > Is there any Softphone client which sends media attributes: 'a= inactive' > when the call is put on hold? The Intellivic Softphone uses 'inactive' to put a call on hold. You can download a demo version at http://demo.intellivic.com. kind regards, Sigrid > Tried SJ phone, Xlite, BT softphone and all of these send 'a=sendonly'. > The client should be capable of reg with SER. This is to test the msg > handling by a SBC, so SIPp can't be used as i need to check the RTP > flow as > well. > > Cheers, > Vishnu > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 01:29:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FFD23A6832; Fri, 27 Jun 2008 01:29:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35523A67D1; Fri, 27 Jun 2008 01:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.260, 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 cqQhaF30YFAC; Fri, 27 Jun 2008 01:29:43 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 6F36D3A6807; Fri, 27 Jun 2008 01:29:41 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Fri, 27 Jun 2008 10:29:43 +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); Fri, 27 Jun 2008 10:29:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Jun 2008 10:28:55 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD402CA9134@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 Thread-Index: AcjXpTpzm2BVB7zxQUKPPgODM8AD4gAAmbewACGQE+A= References: <9886E5FCA6D76549A3011068483A4BD402CA8FB4@S4DE8PSAAQB.mitte.t-com.de> From: "Jesske, R" To: , , X-OriginalArrivalTime: 27 Jun 2008 08:29:42.0835 (UTC) FILETIME=[F2C88830:01C8D82F] Subject: Re: [Sip] [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0248312944==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0248312944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D82F.D56738FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D82F.D56738FA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Mary, Thank for your advice. I think the most important is to say that the Reason header already = exists in RFC3326. The draft draft-jesske-sipping-etsi-ngn-reason-03 = clarifies the use of the Reason Header within Responses. because RFC = 3326 says: =20 Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. Note that the Reason header field is usually not needed in responses because the status code and the reason phrase already provide sufficient information. This section is the problem we see and this needs to be clarified. =20 With regard to the TISPAN requirements document, meanwhile the most are = fulfilled and many of the services are deployed. =20 With regard to the use of the Reason Header I will stripp of the main = Requirement wich fits. This is the interoperability between the = PSTN/ISDN network and SIP networks. So the TISPAN requirements document = says: =20 REQ-GEN-1: =20 All simulation services must provide interoperability with the =20 PSTN/ISDN. By interoperability we mean that, in the case that a =20 simulation or supplementary service is provided to one of the users =20 when one of the endpoints is located in the PSTN and the other is =20 located in the NGN IMS network, the user should receive the service =20 without any degradation as if the service were provided in the native = =20 network. =20 =20 So the Reason header within responses will help to fulfil this there are = certain cause values that are very specific for services. Like the = example within the draft pointing to the Closed User Group service. =20 So I will add some requirements to the draft for the certain cases = described within the draft. =20 Best Regards =20 Roland =20 =20 =20 _____ =20 Von: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 26. Juni 2008 18:28 An: Jesske, Roland; sipping@ietf.org; sip@ietf.org Betreff: Re: [Sipping] Progress on = draft-jesske-sipping-etsi-ngn-reason-03 If the requirements in this document are agreed in SIPPING WG (the doc = seems really sparse in terms of requirements at this point), THEN the = work could progress to the SIP WG. But, we first need to agree = requirements.=20 =20 I see your applicability section and earlier there's reference to the = TISPAN requirements document (which is expired). Can you pull the = specific requirements from that document into this one or at least let's = discuss on the list? In scanning that requirements document, it's not = clear to me which requirement this header is intended to meet. If it is = intended to support many of those simulation services, then that should = be stated. And, so I believe this brings us to the question as to = whether we are going to support those simulation services?=20 =20 Given that many of those services are being developed in BLISS, would it = not be prudent to wait until we see the details of those services to = suggest that we need this header? Or has that already been discussed = and I've missed it? If so, please provide us a pointer to that = discussion. In that case, we could agree that SIPPING WG does not need = to spend much time on the requirements and we could more easily agree = that this could move to SIP WG to be completed. Or, are there other = requirements for this header? =20 =20 And, just for clarification, are their plans to progress that other = general requirements document or should the WG treat that document as we = did in the past the 3GPP requirements document as a working document, = from which to pull specific requirements and solution proposals? My = inclination would be the latter, but we need feedback from the WG = (including ETSI/TISPAN/IMS folks, of course).=20 =20 And, just a note, I bcc'ed SIP WG on this thread, since I would prefer = this thread stay only in SIPPING WG for now, in particular just to keep = down the volume on the SIP list, which is already really busy. =20 Thanks, Mary.=20 _____ =20 From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf Of Jesske, R Sent: Thursday, June 26, 2008 10:57 AM To: sipping@ietf.org; sip@ietf.org Subject: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03 Dear all, at the moment I'm looking for comments on the = http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-03.txt, to = progress the work on that.=20 The reason in responses will be used within the IMS so progress of this = draft is needed. =20 Also I've got the comment that the work should be shifted to SIP WG. =20 Thoughts? Comments? =20 Best Regards =20 Roland =20 = =20 Deutsche Telekom AG=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:=20 Deutsche Telekom AG Aufsichtsrat: Prof. Dr Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Karl-Gerhard Eick (stellvertretender Vorsit-zender), Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794,=20 Sitz der Gesellschaft: Bonn=20 WEEE-Reg.-Nr.: DE50478376=20 ***************************************************************=20 Deutsche Telekom AG=20 Supervisory Board: Prof. Dr Ulrich Lehner (Chairman)=20 Board of Management: Ren=E9 Obermann (Chairman),=20 Dr. Karl-Gerhard Eick (Deputy Chairman),=20 Hamid Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas = Sattelberger=20 Commercial register: Amtsgericht Bonn HRB 6794,=20 corporate seat: Bonn=20 WEEEreg.no: DE50478376=20 =20 ------_=_NextPart_001_01C8D82F.D56738FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Mary,
Thank for your advice.
I think the most important is to say that the = Reason header=20 already exists in RFC3326. The draft = draft-jesske-sipping-etsi-ngn-reason-03=20 clarifies the use of the Reason Header within Responses. because RFC = 3326=20 says:
 
   =
Initially, the Reason header field defined here appears to be most
   useful for BYE and CANCEL requests, but it can appear in any request
   within a dialog, in any CANCEL request and in any response whose
   status code explicitly allows the presence of this header field.

   Note that the Reason header field is usually not needed in responses
   because the status code and the reason phrase already provide
   sufficient information.
This section is the problem we see and this = needs to be=20 clarified.
 
With regard to the TISPAN requirements = document, meanwhile=20 the most are fulfilled and many of the services are=20 deployed.
 
With regard to the use of the Reason Header I = will stripp=20 of the main Requirement wich fits. This is the interoperability between = the=20 PSTN/ISDN network and SIP networks. So the TISPAN requirements document=20 says:
 
REQ-GEN-1:  =20
   All simulation services must provide interoperability with the =20
   PSTN/ISDN. By interoperability we mean that, in the case that a =20
   simulation or supplementary service is provided to one of the users =20
   when one of the endpoints is located in the PSTN and the other is =20
   located in the NGN IMS network, the user should receive the service =20
   without any degradation as if the service were provided in the native =
=20
   network.
 
So the=20 Reason header within responses will help to fulfil this there are = certain cause=20 values that are very specific for services. Like the example within the = draft=20 pointing to the Closed User Group service.
 
So I=20 will add some requirements to the draft for the certain cases described = within=20 the draft.
 
Best=20 Regards
 
Roland
 
 
 

Von: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] Im Auftrag von Mary=20 Barnes
Gesendet: Donnerstag, 26. Juni 2008 = 18:28
An:=20 Jesske, Roland; sipping@ietf.org; sip@ietf.org
Betreff: Re:=20 [Sipping] Progress on=20 draft-jesske-sipping-etsi-ngn-reason-03

If the requirements in this document = are agreed=20 in SIPPING WG (the doc seems really sparse in terms of requirements at = this=20 point), THEN the work could progress to the SIP WG. But, we first need = to=20 agree requirements.
 
I see your applicability section and = earlier there's=20 reference to the TISPAN requirements document (which is expired). Can = you pull=20 the specific requirements from that document into this one or at least = let's=20 discuss on the list?  In scanning that requirements document, = it's not=20 clear to me which requirement this header is intended to meet. If it = is=20 intended to support many of those simulation services, then that = should be=20 stated. And, so I believe this brings us to the question as to whether = we are=20 going to support those simulation services?
 
Given that many of those services are being = developed=20 in BLISS, would it not be prudent to wait until we see the details of = those=20 services to suggest that we need this header?  Or has that = already been=20 discussed and I've missed it? If so, please provide us a pointer to = that=20 discussion.  In that case, we could agree that SIPPING WG does = not need=20 to spend much time on the requirements and we could more easily agree = that=20 this could move to SIP WG to be completed.  Or, are there other=20 requirements for this header? 
 
And, just for clarification, are their = plans to=20 progress that other general requirements document or should the WG = treat that=20 document as we did in the past the 3GPP requirements document as a = working=20 document, from which to pull specific requirements and solution=20 proposals?  My inclination would be the latter, but we need = feedback from=20 the WG (including ETSI/TISPAN/IMS folks, of course). =
 
And, just a note, I bcc'ed SIP WG on this = thread,=20 since I would prefer this thread stay only in SIPPING WG for now, in=20 particular just to keep down the volume on the SIP list, which is = already=20 really busy.
 
Thanks,
Mary.

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Jesske,=20 R
Sent: Thursday, June 26, 2008 10:57 AM
To:=20 sipping@ietf.org; sip@ietf.org
Subject: [Sipping] Progress = on=20 draft-jesske-sipping-etsi-ngn-reason-03

Dear = all,
at = the moment I'm=20 looking for comments on the http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-03.txt= ,=20 to progress the work on that. 
The = reason in=20 responses will be used within the IMS so progress of this draft = is=20 needed.
 
Also = I've got the=20 comment that the work should be shifted to SIP WG.
 
Thoughts?=20 Comments?
 
Best = Regards
 
Roland
 
 
 

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

http://www.telekom.de=20

Registerrechtliche Unternehmensangaben:=20
Deutsche Telekom=20 AG
Aufsichtsrat: Prof. Dr Ulrich Lehner=20 (Vorsitzender)
Vorstand: Ren=E9 Obermann=20 (Vorsitzender),
Dr. Karl-Gerhard Eick (stellvertretender = Vorsit-zender),
Hamid=20 Akhavan, Reinhard Clemens, Timotheus H=F6ttges, Thomas Sattelberger=20
Handelsregister: Amtsgericht Bonn HRB = 6794,=20
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.: DE50478376
***************************************************************= =20
Deutsche Telekom AG
Supervisory=20 Board: Prof. Dr Ulrich Lehner=20 (Chairman)
Board of Management: = Ren=E9=20 Obermann (Chairman),
Dr. Karl-Gerhard = Eick (Deputy=20 Chairman),
Hamid Akhavan, Reinhard = Clemens,=20 Timotheus H=F6ttges,  Thomas = Sattelberger
Commercial=20 register: Amtsgericht Bonn HRB 6794,
corporate seat:=20 Bonn
WEEEreg.no: = DE50478376

 
------_=_NextPart_001_01C8D82F.D56738FA-- --===============0248312944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0248312944==-- From sip-bounces@ietf.org Fri Jun 27 10:09:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791633A679F; Fri, 27 Jun 2008 10:09:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F07B3A67E6 for ; Fri, 27 Jun 2008 10:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 P5+DPgTMxaXp for ; Fri, 27 Jun 2008 10:09:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 729683A6768 for ; Fri, 27 Jun 2008 10:09:17 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 27 Jun 2008 12:34:23 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 27 Jun 2008 12:34:23 -0400 From: Hadriel Kaplan To: "sip@ietf.org" Date: Fri, 27 Jun 2008 12:34:50 -0400 Thread-Topic: Re: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjYc7glGx+CVH6rRwCdj9wJAVSi0Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > >> A typical example is emergency calls. > > > > I don't get this one. You don't need to send keep-alive packets to make > > an outbound call (be it urgent or not). You need to send keepalives to keep the signaling path open, so that the other side can send back requests during the duration of the call. (in fact, the PSAP could send an UPDATE every 30 seconds to force that in case there is no keepalive) > Also frequent UDP keep-alives are a total non-starter for mobile handsets, due > to excessive battery consumption. Yet mobile handsets are probably the most > common way to do emergency calls nowadays, for obvious availability reasons. Christer's talking about unregistered devices making an emergency call, and keeping that call alive and usable. (since at least in the US, we have requirements to allow mobile sets and landlines to be able to make emergency calls regardless of paid service subscription) I assume battery usage for SIP requests during an emergency call is not an issue, since it's already sending RTP the whole time, no? -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 10:12:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F323A69AD; Fri, 27 Jun 2008 10:12:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E1C3A6958 for ; Fri, 27 Jun 2008 10:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 ElOHMZh8kneq for ; Fri, 27 Jun 2008 10:12:24 -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 362063A6936 for ; Fri, 27 Jun 2008 10:12:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,716,1204531200"; d="scan'208";a="83804907" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2008 09:05:13 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5RG5CxT024650; Fri, 27 Jun 2008 09:05:12 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5RG5B76026204; Fri, 27 Jun 2008 16:05:11 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Paul Kyzivat'" , "'Hannes Tschofenig'" References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com><485FEDBA.9090304@cisco.com><549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com><5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com><08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net><05d001c8d628$98c91510$c2f0200a@cisco.com><48614E77.9010904@alcatel-lucent.com><071b01c8d63f$2e39e910$c2f0200a@cisco.com><4861675E.1010507@alcatel-lucent.com><076c01c8d643$85c210a0$c2f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net><4862347B.8080405@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net><0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net><4863528C.6040309@gmx.net><48638D3E.4020908@cisco.com> Date: Fri, 27 Jun 2008 09:05:11 -0700 Message-ID: <160201c8d86f$945afea0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjXiSiUwkn5+tR0RaeaxNPjg9fzXQAAPWTAADZ/NwAAAtw98A== In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2311; t=1214582712; x=1215446712; c=relaxed/simple; s=sjdkim2002; 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=20SIP=20Identity |Sender:=20; bh=ocOWIZBt8Y2+X0mQP+c5zi+lBhVjXAHDWB9tVYGsgPM=; b=J3LJZPfFo3AIH3DyVqmUejCGmiOa4OOZIcfBx2ZvAGQPvb9noYiUzV1qxi choIS9fHDMd6EJ6n8S/SYa6GYHgIBwgi3vQZSHl1RDKDuuUitgjQEkQYqLrv XTJqfwFr/F; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, "'Elwell, John'" Subject: Re: [Sip] SIP Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Agreed. -d > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, June 27, 2008 8:06 AM > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Paul Kyzivat; > Hannes Tschofenig > Cc: sip@ietf.org; Elwell, John; Dan Wing > Subject: RE: SIP Identity > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Tschofenig, Hannes (NSN - FI/Espoo) > > > > I am trying to figure out where the problems are: > > > > Now, it would be interesting to hear whether these guys > have actually > > ever turned it on and used it. What was their experience? Did they > > indeed encounter problems with certain SBC configurations? > > I am fairly confident in saying that there could not be an > SBC that wouldn't break 4474 signatures, since it's basically > inherent in the definition of an SBC to modify some of the > things that 4474 signs. (ie, if it's not modifying them, it's > not really acting in an SBC "mode" anymore) > Except of course when the SBC is the signer/verifier. > > > > Would more folks use it when some of the weaknesses on the > E.164 number > > usage are documented? > > I doubt it. Plenty of weaknesses of RTP have been > "documented", which haven't driven SRTP's uptake. It will > take actual real-world cases of abuse to drive it, IMHO. But > by then it will be late. First there's the problem of making > it work across already deployed infrastructure, which 4474 > doesn't, and there can be no "flag day". Given how long it > takes us to standardize things, get them into code/hardware, > and get people to upgrade, we're talking years. That's why I > want to work on it now, just in case we need it in the next few years. > > > > How would a change to the signature algorithm impact the situation? > > By making it work across deployed infrastructure. More and > more Enterprise-SP SIP Trunks are getting added every day, > and inter-SP peering is continually growing. If an Identity > algorithm has a lot of false positives (signatures broken but > the request is really ok), it won't be much use and people > will ignore it. No algorithm has a chance of use if legit calls fail. > > -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 11:07:00 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A43A3A6A5E; Fri, 27 Jun 2008 11:07:00 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCAD53A69AD for ; Fri, 27 Jun 2008 11:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.646 X-Spam-Level: X-Spam-Status: No, score=-6.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 5kQ8-pkU0tqJ for ; Fri, 27 Jun 2008 11:06:59 -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 C0BD03A68E8 for ; Fri, 27 Jun 2008 11:06:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,716,1204520400"; d="scan'208";a="12489732" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Jun 2008 14:07:03 -0400 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 m5RI73i3003056; Fri, 27 Jun 2008 14:07: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.13.8) with ESMTP id m5RI73F4006940; Fri, 27 Jun 2008 18:07:03 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.1830); Fri, 27 Jun 2008 14:07:02 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 14:07:02 -0400 Message-ID: <48652C75.6050501@cisco.com> Date: Fri, 27 Jun 2008 14:07:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hadriel Kaplan References: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> In-Reply-To: X-OriginalArrivalTime: 27 Jun 2008 18:07:02.0400 (UTC) FILETIME=[9992B000:01C8D880] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1178; t=1214590023; x=1215454023; 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[Sip]=20SIP=20Identity=20WG=20name |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=Iu27lXK+p7W/W2mSY6UXvbJvEuA+V0caXu8DPRCJGHU=; b=eWuUk0nPEQH7uO32thyNlHYgNbjDrSozRV4WFqHGw3MGXdTrVYk9dhLjd4 cnW2HTuF5C6GIJvm2Uh5myQaF1bGZKDrctA283zaDqZi+zNxxug95IsHUAtY /SJzPpp8K8; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] SIP Identity WG name X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Another vote for INSIPID :) Hadriel Kaplan wrote: > I don't know if people care, but since email is free: it would be nice to decide on a name for this potential group, and RETIRE is kinda a downer. > > Potential names: > RETIRE - "REal Time Identity and Role Expression" > SIGNED - "Sip Identity for Generic Name and E.164 Deployments" > SIGN - "Sip Identity for Global Names" > RISE - "Roles and Identities in SIP Environments" > > Or if you prefer a tounge-in-cheek approach: > RESIGN - "Roles and Establishment for SIP Identities of Generic Nature" (which would be pronounced either as the act of signing again as in "re-sign", or of retiring as in "resign") > INSIPID - "INternet SIP IDentities" (which could be pronounced either as "in SIP-ID", or the word insipid) > > So far we have 3 votes for INSIPID and 1 vote for SIGNED. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 11:13:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFEA3A6900; Fri, 27 Jun 2008 11:13:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C603A6883; Fri, 27 Jun 2008 11:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, J_CHICKENPOX_27=0.6, MIME_BASE64_TEXT=1.753, 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 qzbvA0WBGtZR; Fri, 27 Jun 2008 11:13:42 -0700 (PDT) Received: from smtp10.bis.na.blackberry.com (smtp10.bis.na.blackberry.com [216.9.248.57]) by core3.amsl.com (Postfix) with ESMTP id CD5683A6896; Fri, 27 Jun 2008 11:13:09 -0700 (PDT) Received: from bxe189.bisx.prod.on.blackberry (bxe189.bisx.prod.on.blackberry [172.20.225.222]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m5RHjUvZ013248; Fri, 27 Jun 2008 18:13:13 GMT X-rim-org-msg-ref-id: 74184705 Message-ID: <74184705-1214590393-cardhu_decombobulator_blackberry.rim.net-1580487272-@bxe189.bisx.prod.on.blackberry> X-Priority: Normal References: <306BBCCB-30D8-41C5-9137-4E5F64C6F591@softarmor.com> <48652C75.6050501@cisco.com> In-Reply-To: <48652C75.6050501@cisco.com> Sensitivity: Normal Importance: Normal To: "Paul Kyzivat" , sip-bounces@ietf.org, "Hadriel Kaplan" From: "=?utf-8?B?RGFuIFlvcms=?=" Date: Fri, 27 Jun 2008 18:14:23 +0000 MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] SIP Identity WG name X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dyork@voxeo.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I like SIGNED. I agree that RETIRE wasn't the right name. My 2 cents, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com -----Original Message----- From: Paul Kyzivat Date: Fri, 27 Jun 2008 14:07:49 To:Hadriel Kaplan Cc:"sip@ietf.org" Subject: Re: [Sip] SIP Identity WG name Another vote for INSIPID :) Hadriel Kaplan wrote: > I don't know if people care, but since email is free: it would be nice to decide on a name for this potential group, and RETIRE is kinda a downer. > > Potential names: > RETIRE - "REal Time Identity and Role Expression" > SIGNED - "Sip Identity for Generic Name and E.164 Deployments" > SIGN - "Sip Identity for Global Names" > RISE - "Roles and Identities in SIP Environments" > > Or if you prefer a tounge-in-cheek approach: > RESIGN - "Roles and Establishment for SIP Identities of Generic Nature" (which would be pronounced either as the act of signing again as in "re-sign", or of retiring as in "resign") > INSIPID - "INternet SIP IDentities" (which could be pronounced either as "in SIP-ID", or the word insipid) > > So far we have 3 votes for INSIPID and 1 vote for SIGNED. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 11:34:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2883A6B04; Fri, 27 Jun 2008 11:34:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B453A6B04 for ; Fri, 27 Jun 2008 11:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.266, 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 8Eh-AOe9L3Xz for ; Fri, 27 Jun 2008 11:34:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0E2893A683C for ; Fri, 27 Jun 2008 11:34:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 27 Jun 2008 14:33:16 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 27 Jun 2008 14:33:16 -0400 From: Hadriel Kaplan To: Hannes Tschofenig , "Elwell, John" Date: Fri, 27 Jun 2008 14:33:41 -0400 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXZipKtZPN4grjQgmb+fT3O/KHuQAS5tAg Message-ID: References: <408DFED6-302C-4525-BCD5-1E43B68369BE@softarmor.com> <485FEDBA.9090304@cisco.com> <549C8D7E-8F0D-43C8-B6C3-B61D5D0DE238@softarmor.com> <5744EABA-0861-4B95-BD91-2C4F0AC92BFE@softarmor.com> <08d401c8d57a$dc7216d0$c2f0200a@cisco.com> <4860AD84.60004@gmx.net> <05d001c8d628$98c91510$c2f0200a@cisco.com> <48614E77.9010904@alcatel-lucent.com> <071b01c8d63f$2e39e910$c2f0200a@cisco.com> <4861675E.1010507@alcatel-lucent.com> <076c01c8d643$85c210a0$c2f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E4AA@GBNTHT12009MSX.gb002.siemens.net> <4862347B.8080405@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0D6E76C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0D6E9B6@GBNTHT12009MSX.gb002.siemens.net> <4863528C.6040309@gmx.net> In-Reply-To: <4863528C.6040309@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > >> > > [JRE] Well, what about enterprise via service provider to enterprise? As > > an enterprise provider, I would like to be able to use SIP identity, but > > a precondition is that it gets through that intermediate service > > provider(s). > > > Why would like to pick a service provider in the first place? Want the top 10 reasons? (in no particular order) 1) Because most of their calls still go to/from the PSTN. 2) Because most of their calls are still addressed to/from using E.164 - they have no idea it's going to end up at another SIP-enabled Enterprise. 3) Because voice means business/money for many Enterprises - if it doesn't work they want someone to go fix it, someone to yell at, someone to monitor it, etc. 4) Because the target destination Enterprise may not allow incoming calls from anyone but *their* SP. 5) Because their SP has defined qos guarantees for VoIP traffic, if it's SIP-routed through them. (in some ways one could argue SIP has accomplished what RSVP was meant to do but did not) 6) Because SIP has significant interop issues, and the Enterprise knows their stuff works with the SP. 7) Because the IT guys can justify it more easily to execs, and won't get fired if the SP screws up. (if there even *is* an IT dept.) 8) Because email has NOT been a shining example for how VoIP could work. 9) Because they have constrained-resource WAN links and want to use low-bandwidth codecs over that, but want to let the SP transcode it to whatever will work with the far end. 10) Because if it ain't broke, they don't want to fix it. (ie, if it works it works) > Why are > they deploying B2BUAs? Who, the SP or the Enterprise? The answer is usually "control" ultimately, in some form or other. > If you really want todo that then pick one that does not damage your > security. You are the customer and you decide. Damage your security how, and according to who's definition of security? You think end-end is somehow inherently secure. But neither end trusts the other. They trust the middles (specifically their respective next-middles) more than the other ends. That's the rub. > If you want to pick such as service provider then why does the chain of > trust not work for you? Hopefully you trust the provider you have chosen. I trust my provider, but not their peers as much, and less their peers' peers. If I am using myprovider.com and I get a call from them saying it's from bob@myprovider.com I would be confident that's true. I have much less confidence when I get a call from my provider saying the caller is admin@paypal.com. But this topic isn't really about me or us anyway, imho. Most SP customers blindly trust their SP's, imo - IETF'ers are an exception not the rule. It's about an SP wanting to live-up to the trust its customers put in it. They'd like to know that when they get calls from one of their peer SPs, they can trust calls that didn't originate at that peer. They essentially had that in the PSTN, because they could ferret out trouble-makers over time, there's a forced hierarchy of providers, and the cost of calls and linking into SS7 self-limited many issues. Whether that holds true for SIP remains to be seen. I'd like to be ready before we find otherwise. > .... just trying to figure out what the typical deployment cases are and > why we don't see any of this in XMPP. If people only used SIP for free IM, with email-type user@domain FQDN URIs only, and had one dominant vendor implementation, I bet the deployment landscape would be quite similar to XMPP. It's not the protocol that causes it. (Well, that's not totally true, but close enough) -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 12:10:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDBD728C18E; Fri, 27 Jun 2008 12:10:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577DB28C182 for ; Fri, 27 Jun 2008 12:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_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 1buiK5pokxS3 for ; Fri, 27 Jun 2008 12:10:55 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with ESMTP id 9611728C196 for ; Fri, 27 Jun 2008 12:10:51 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Jun 2008 12:10:57 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 m5RJ7VG3008210; Fri, 27 Jun 2008 12:07:31 -0700 (PDT) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m5RJAhI0011435; Fri, 27 Jun 2008 12:10:53 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Jun 2008 04:10:42 +0900 Received: from 10.58.20.192 ([10.58.20.192]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Jun 2008 19:10:40 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 27 Jun 2008 12:10:39 -0700 From: Henry Sinnreich To: Hadriel Kaplan , Hannes Tschofenig , "Elwell, John" Message-ID: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXZipKtZPN4grjQgmb+fT3O/KHuQAS5tAgADXtuQ0= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 27 Jun 2008 19:10:42.0492 (UTC) FILETIME=[7E8677C0:01C8D889] Cc: "sip@ietf.org" , Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > 1) Because most of their calls still go to/from the PSTN. I wonder if this may still be true: - All employees have cell phones - The most active talkers use the Blackberry - Hard working folks in cubes (like myself :-)) have a desktop phone but consider it a nuisance and never use it. I prefer to IM so as not to make noise and to have privacy. This leaves very few types of workers using the PSTN, probably in call centers and those in support functions. Does anyone have a report with numbers on this? > 3) Because voice means business/money for many Enterprises I wonder about this too. Except for the marketing and support folks, talking on the phone lowers productivity. Productive employees use multimedia communications with document/desktop sharing, document routing, etc. Using voice at work (at some cost to the enterprise) seems to me just a bad habit or bad legacy, and is rather the exception, not the rule. BTW: Don't you have a plain cell phone, iPhone or Blackberry? Henry On 6/27/08 11:33 AM, "Hadriel Kaplan" wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Hannes Tschofenig >>>> >>> [JRE] Well, what about enterprise via service provider to enterprise? As >>> an enterprise provider, I would like to be able to use SIP identity, but >>> a precondition is that it gets through that intermediate service >>> provider(s). >>> >> Why would like to pick a service provider in the first place? > > Want the top 10 reasons? (in no particular order) > 1) Because most of their calls still go to/from the PSTN. > 2) Because most of their calls are still addressed to/from using E.164 - they > have no idea it's going to end up at another SIP-enabled Enterprise. > 3) Because voice means business/money for many Enterprises - if it doesn't > work they want someone to go fix it, someone to yell at, someone to monitor > it, etc. > 4) Because the target destination Enterprise may not allow incoming calls from > anyone but *their* SP. > 5) Because their SP has defined qos guarantees for VoIP traffic, if it's > SIP-routed through them. (in some ways one could argue SIP has accomplished > what RSVP was meant to do but did not) > 6) Because SIP has significant interop issues, and the Enterprise knows their > stuff works with the SP. > 7) Because the IT guys can justify it more easily to execs, and won't get > fired if the SP screws up. (if there even *is* an IT dept.) > 8) Because email has NOT been a shining example for how VoIP could work. > 9) Because they have constrained-resource WAN links and want to use > low-bandwidth codecs over that, but want to let the SP transcode it to > whatever will work with the far end. > 10) Because if it ain't broke, they don't want to fix it. (ie, if it works it > works) > > >> Why are >> they deploying B2BUAs? > > Who, the SP or the Enterprise? The answer is usually "control" ultimately, in > some form or other. > > >> If you really want todo that then pick one that does not damage your >> security. You are the customer and you decide. > > Damage your security how, and according to who's definition of security? You > think end-end is somehow inherently secure. But neither end trusts the other. > They trust the middles (specifically their respective next-middles) more than > the other ends. That's the rub. > > >> If you want to pick such as service provider then why does the chain of >> trust not work for you? Hopefully you trust the provider you have chosen. > > I trust my provider, but not their peers as much, and less their peers' peers. > If I am using myprovider.com and I get a call from them saying it's from > bob@myprovider.com I would be confident that's true. I have much less > confidence when I get a call from my provider saying the caller is > admin@paypal.com. > > But this topic isn't really about me or us anyway, imho. Most SP customers > blindly trust their SP's, imo - IETF'ers are an exception not the rule. It's > about an SP wanting to live-up to the trust its customers put in it. They'd > like to know that when they get calls from one of their peer SPs, they can > trust calls that didn't originate at that peer. They essentially had that in > the PSTN, because they could ferret out trouble-makers over time, there's a > forced hierarchy of providers, and the cost of calls and linking into SS7 > self-limited many issues. Whether that holds true for SIP remains to be seen. > I'd like to be ready before we find otherwise. > > >> .... just trying to figure out what the typical deployment cases are and >> why we don't see any of this in XMPP. > > If people only used SIP for free IM, with email-type user@domain FQDN URIs > only, and had one dominant vendor implementation, I bet the deployment > landscape would be quite similar to XMPP. It's not the protocol that causes > it. (Well, that's not totally true, but close enough) > > -hadriel > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 12:14:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC973A6958; Fri, 27 Jun 2008 12:14:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB5C3A6958 for ; Fri, 27 Jun 2008 12:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+sVZgcwFt2M for ; Fri, 27 Jun 2008 12:14:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 849483A68B4 for ; Fri, 27 Jun 2008 12:14:25 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5RJESPo013434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Jun 2008 14:14:30 -0500 Message-Id: <6BC58314-BA5B-4706-9659-A869FD87D1FC@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 14:14:23 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] Major problems with subscriber database X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Apparently the SIP list's (and IETF list's) subscriber database got scrambled badly. The admins restored a backup, but it was apparently a very old (like, 2 year old) backup. So a lot of people that have unsubscribed in that period are now getting SIP mail, and a lot of people who subscribed (or changed addresses, like Robert Sparks) in that period have become unsubscribed. The admins are working on it. I think that the list is currently "frozen", so it may be pointless to try and subscribe or unsubscribe at this time. It may be a day or two before the situation settles down. I'm sorry. They're working on it. And above all (on the cover in large friendly letters) Don't Panic! -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 12:31:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C8B3A68DF; Fri, 27 Jun 2008 12:31:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D0B3A689B for ; Fri, 27 Jun 2008 12:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, FRT_ADOBE2=2.455] Received: 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+UICx45sOtV for ; Fri, 27 Jun 2008 12:31:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3C3323A67F6 for ; Fri, 27 Jun 2008 12:31:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 27 Jun 2008 15:31:01 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 27 Jun 2008 15:31:01 -0400 From: Hadriel Kaplan To: Henry Sinnreich , Hannes Tschofenig , "Elwell, John" Date: Fri, 27 Jun 2008 15:31:28 -0400 Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXZipKtZPN4grjQgmb+fT3O/KHuQAS5tAgADXtuQ0AAC9mAA== 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 MIME-Version: 1.0 Cc: "sip@ietf.org" , Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Friday, June 27, 2008 3:11 PM > To: Hadriel Kaplan; Hannes Tschofenig; Elwell, John > Cc: sip@ietf.org; Paul Kyzivat; Dan Wing > Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups > > > 1) Because most of their calls still go to/from the PSTN. > > I wonder if this may still be true: > - All employees have cell phones All cell phones *are* on the PSTN, for all intents and purposes to which the email was about. > > 3) Because voice means business/money for many Enterprises > > I wonder about this too. Except for the marketing and support folks, > talking And sales, and brick-and-mortar retailers, and food delivery, and repair shops, and hotels, and restaurants, and financial trading floors, and most things found in thick yellow books or on business cards. I'm not saying commerce doesn't happen in other ways (duh), just that it also happens over voice. I have no idea if it's more/less than email or http or whatever (and I bet the answer to that is regionally-specific), just that it's darn big. > Using voice at work (at some cost to the enterprise) seems to me just a > bad > habit or bad legacy, and is rather the exception, not the rule. > > BTW: Don't you have a plain cell phone, iPhone or Blackberry? See above - cell phones *are* the PSTN, at least so far they are. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 12:54:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8532128C1DB; Fri, 27 Jun 2008 12:54:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E09728C1DB for ; Fri, 27 Jun 2008 12:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.89 X-Spam-Level: X-Spam-Status: No, score=-4.89 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 NFRLUcausk0E for ; Fri, 27 Jun 2008 12:54:31 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by core3.amsl.com (Postfix) with ESMTP id E129F28C1BF for ; Fri, 27 Jun 2008 12:54:26 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Jun 2008 12:54:31 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 m5RJsRE0012681; Fri, 27 Jun 2008 12:54:27 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m5RJsJqJ009024; Fri, 27 Jun 2008 12:54:20 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 12:54:18 -0700 Received: from 10.58.20.192 ([10.58.20.192]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Jun 2008 19:54:18 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 27 Jun 2008 12:54:17 -0700 From: Henry Sinnreich To: Hadriel Kaplan , Hannes Tschofenig , "Elwell, John" Message-ID: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXZipKtZPN4grjQgmb+fT3O/KHuQAS5tAgADXtuQ0AAC9mAAABVrfL In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 27 Jun 2008 19:54:18.0953 (UTC) FILETIME=[960EBB90:01C8D88F] Cc: "sip@ietf.org" , Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > See above - cell phones *are* the PSTN, at least so far they are. Any IMS folks here to agree with this? :-) Henry On 6/27/08 12:31 PM, "Hadriel Kaplan" wrote: > > >> -----Original Message----- >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Friday, June 27, 2008 3:11 PM >> To: Hadriel Kaplan; Hannes Tschofenig; Elwell, John >> Cc: sip@ietf.org; Paul Kyzivat; Dan Wing >> Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups >> >>> 1) Because most of their calls still go to/from the PSTN. >> >> I wonder if this may still be true: >> - All employees have cell phones > > All cell phones *are* on the PSTN, for all intents and purposes to which the > email was about. > >>> 3) Because voice means business/money for many Enterprises >> >> I wonder about this too. Except for the marketing and support folks, >> talking > > And sales, and brick-and-mortar retailers, and food delivery, and repair > shops, and hotels, and restaurants, and financial trading floors, and most > things found in thick yellow books or on business cards. I'm not saying > commerce doesn't happen in other ways (duh), just that it also happens over > voice. I have no idea if it's more/less than email or http or whatever (and I > bet the answer to that is regionally-specific), just that it's darn big. > > >> Using voice at work (at some cost to the enterprise) seems to me just a >> bad >> habit or bad legacy, and is rather the exception, not the rule. >> >> BTW: Don't you have a plain cell phone, iPhone or Blackberry? > > See above - cell phones *are* the PSTN, at least so far they are. > > -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 14:13:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF6C28C1B1; Fri, 27 Jun 2008 14:13:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6581A3A687C; Fri, 27 Jun 2008 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 8bNM43XLaFdc; Fri, 27 Jun 2008 14:13:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 94CD43A676A; Fri, 27 Jun 2008 14:13:26 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5RLDUhj014227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Jun 2008 16:13:31 -0500 Message-Id: <93765586-1DAE-4EBB-8450-8184DC29A6E5@softarmor.com> From: Dean Willis To: sip@ietf.org, SIPPING LIST , ietf-announce@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 16:13:24 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] Outage on SIP Mailing List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The SIP mailing list went insane last night and started running on a roughly 3-year old copy of its subscriber list. The database problem has supposedly been corrected, but there may be subscribers who are not in the correct state. If you want to receive SIP mailing list messages and aren't getting them, please re-subscribe. If you want to NOT receive SIP mailing list messages and ARE getting them, please unsubscribe. You can manage subscriptions through the email. By email, send a request to sip-request@ietf.org with either "subscribe" or "unsubscribe" (don't type the quotes) in the body, as appropriate. Supposedly, there's also a web interface for this, but I can't seem to find it at the moment. Have a nice day. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 14:30:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1EF13A6ACE; Fri, 27 Jun 2008 14:30:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F40F3A6ACE; Fri, 27 Jun 2008 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 PCqE1bd-TL24; Fri, 27 Jun 2008 14:30:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 910783A6813; Fri, 27 Jun 2008 14:30:07 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5RLU6w6014335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Jun 2008 16:30:12 -0500 Message-Id: <1999E300-22C4-4984-B49D-B4EEF310F446@softarmor.com> From: Dean Willis To: sip@ietf.org, SIPPING LIST Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 16:30:01 -0500 References: <486559D2.8060601@alcatel-lucent.com> X-Mailer: Apple Mail (2.924) Subject: [Sip] Update: Outage on SIP Mailing List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The Web interface for managing subscriptions to SIP was found for me by Vijay Gurbani: https://www.ietf.org/mailman/listinfo/sip Thanks, Vijay -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 14:43:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FC028C20C; Fri, 27 Jun 2008 14:43:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1F03A67E3 for ; Fri, 27 Jun 2008 14:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.803 X-Spam-Level: X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_18=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 BeK9nE51ESri for ; Fri, 27 Jun 2008 14:43:47 -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 5A9983A6781 for ; Fri, 27 Jun 2008 14:42:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,717,1204531200"; d="scan'208";a="119445059" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2008 14:41:55 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5RLft3P005141; Fri, 27 Jun 2008 14:41:55 -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.13.8) with ESMTP id m5RLftYE023965; Fri, 27 Jun 2008 21:41:55 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 14:41:55 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.80.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 14:41:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jun 2008 21:13:04 -0500 To: "'Sudhir Kumar Reddy'" , From: "James M. Polk" In-Reply-To: <002201c8d7aa$47de9200$c2f0200a@cisco.com> References: <52db68bc0806252333q5bb1a424g682e9e083a7b6b98@mail.gmail.com> <002201c8d7aa$47de9200$c2f0200a@cisco.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Jun 2008 21:41:55.0212 (UTC) FILETIME=[9E49ACC0:01C8D89E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1444; t=1214602915; x=1215466915; 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[Sip]=20can=20SDP=20contain=202=20'M'=2 0lines |Sender:=20; bh=QEgp8BXAkm8TFS+cW+46Bq4QPVrU8clZ8SV+lYDNTFg=; b=iXV/THZcrkNSGiqPWzHw9SaPagsVuSc9YXnkmy/XZP951BmKTmUAcMFnpT ZTLeNsivwLwKsJcVys4FtFDRSJucCKZ0+kfVdtDLvmJO4DYbguytXyvV52gI HvCmXNFtLA; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Dan Wing Subject: Re: [Sip] can SDP contain 2 'M' lines X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 11:32 AM 6/26/2008, Dan Wing wrote: > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Sudhir Kumar Reddy > > Sent: Wednesday, June 25, 2008 11:34 PM > > To: sip@ietf.org > > Subject: [Sip] can SDP contain 2 'M' lines > > > > Hi All, > > > > In SDP can we have two 'M' lines for re-INVITE i.e. for call hold. > > > > if yes what is RFC / draft > >I have seen two responses that answer your first question and say 'yes'. >However, multiple m= lines are not used to put a call on hold. indeed 1 (the same) m= line in sdp (offer) of reINVITE; same Call-ID, From and To tag as original INVITE; R-URI to same UA; (though I'm not sure if this R-URI can be to the Contact address in original 200 OK); same c= line; *different* (1) or *new* a= line from a=sendrecv to a=sendonly the answer will be a=recvonly (1) omitting a=sendrecv is ok in the original offer, since it is implied unless a direction tag is explicitly different in any offer. see RFCs 3264 and 4566 for more details James >-d > >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 27 17:34:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E54328C1E5; Fri, 27 Jun 2008 17:34:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0AB3A688E; Fri, 27 Jun 2008 17:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[AWL=1.988, 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 VHkIc7e+8GE5; Fri, 27 Jun 2008 17:34:15 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by core3.amsl.com (Postfix) with SMTP id 89FDD3A6858; Fri, 27 Jun 2008 17:34:15 -0700 (PDT) Received: from source ([63.240.6.3]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Jun 2008 17:34:20 PDT Received: from D01SMTP04.Mi8.com ([172.16.1.243]) by Outbound02.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 20:37:18 -0400 Received: from D01SMTP04.Mi8.com ([172.16.1.243]) by D01SMTP04.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 20:37:18 -0400 Received: from mail pickup service by D01SMTP04.Mi8.com with Microsoft SMTPSVC; Fri, 27 Jun 2008 20:37:13 -0400 Received: from psmtp.com ([64.18.1.123]) by D01SMTP04.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 17:33:47 -0400 Received: from source ([208.65.145.245]) (using TLSv1) by exprod6mx223.postini.com ([64.18.5.10]) with SMTP; Fri, 27 Jun 2008 14:30:46 PDT Received: from unknown [64.170.98.32] (EHLO mail.ietf.org) by p02c12m041.mxlogic.net (mxl_mta-5.6.0-1) with ESMTP id 50c55684.3596962736.99515.00-003.p02c12m041.mxlogic.net (envelope-from ); Fri, 27 Jun 2008 15:30:45 -0600 (MDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C4B28C1EF; Fri, 27 Jun 2008 14:30:10 -0700 (PDT) X-Original-To: sipping@core3.amsl.com Delivered-To: sipping@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F40F3A6ACE; Fri, 27 Jun 2008 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCqE1bd-TL24; Fri, 27 Jun 2008 14:30:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 910783A6813; Fri, 27 Jun 2008 14:30:07 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5RLU6w6014335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Jun 2008 16:30:12 -0500 Message-Id: <1999E300-22C4-4984-B49D-B4EEF310F446@softarmor.com> From: Dean Willis To: sip@ietf.org, SIPPING LIST Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 16:30:01 -0500 References: <486559D2.8060601@alcatel-lucent.com> X-Mailer: Apple Mail (2.924) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Archive: X-Spam: [F=0.0161475387; B=0.500(0); spf=0.500; CM=0.500; MH=0.500(2008062756); R=0.128(108527133554); S=0.100(2008062001); SS=0.500; SC=none] X-MAIL-FROM: X-SOURCE-IP: [64.170.98.32] X-AnalysisOut: [v=1.0 c=1 a=smK5YCbt1HsA:10 a=qHw2lLH2h6gA:10 a=8DnW6Uiazk] X-AnalysisOut: [Wc0BlsFzIHow==:17 a=48vgC7mUAAAA:8 a=n3Gpj8DZGxWHyn7jNS0A:] X-AnalysisOut: [9 a=zGOCf-akqKAbBudobeDtpNz-ElMA:4 a=lZB815dzVvQA:10 a=uVa] X-AnalysisOut: [wpVqKyvgA:10] X-pstn-neptune: 10/1/0.10/43 X-pstn-levels: (S:99.90000/99.90000 CV:99.0000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-OriginalArrivalTime: 27 Jun 2008 21:33:48.0182 (UTC) FILETIME=[7BFECB60:01C8D89D] Subject: [Sip] [Sipping] Update: Outage on SIP Mailing List X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The Web interface for managing subscriptions to SIP was found for me by Vijay Gurbani: https://www.ietf.org/mailman/listinfo/sip Thanks, Vijay -- Dean _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 28 22:02:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034CE28C176; Sat, 28 Jun 2008 22:02:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470593A6A26; Sat, 28 Jun 2008 22:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 wdAGfZ0Bj7oR; Sat, 28 Jun 2008 22:01:14 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14]) by core3.amsl.com (Postfix) with ESMTP id 928C13A688C; Sat, 28 Jun 2008 22:01:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thunder2.amsl.com (Postfix) with ESMTP id D8DEB48123; Sat, 28 Jun 2008 22:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([64.170.98.20]) by localhost (thunder2.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzihQtE96XTo; Sat, 28 Jun 2008 22:01:31 -0700 (PDT) Received: from [192.168.1.100] (c-76-103-55-1.hsd1.ca.comcast.net [76.103.55.1]) by thunder2.amsl.com (Postfix) with ESMTP id 36574480F5; Sat, 28 Jun 2008 22:01:31 -0700 (PDT) Message-ID: <48671722.1020502@amsl.com> Date: Sat, 28 Jun 2008 22:01:22 -0700 From: Glen User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ietf@ietf.org, sip@ietf.org, IAOC X-Enigmail-Version: 0.95.6 X-Mailman-Approved-At: Sat, 28 Jun 2008 22:02:57 -0700 Subject: [Sip] Subscriber List Damage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org All - I was asked by the IAOC to post a message to the IETF and SIP lists, to ensure that people were aware that the subscriber lists for the IETF and SIP lists were damaged as a result of an anomaly in TMDA and Mailman that occurred Thursday night. Basically, TMDA misbehaved, and, in the process, caused Mailman to encounter a transient failure in the reading of its databases for these two lists. As a result, rather than simply holding the mail and retrying it, Mailman decided to discard the current list databases and re-create them from 3-year-old data, for both the IETF and the SIP lists. *sigh* No email was lost to the system or the archives; however, some people may have missed some messages, or may still not be resubscribed to the list. Of course we restored the files from backups; however, we want to make sure that everyone gets the mail they missed, and that everyone is subscribed to these lists who wishes to be subscribed. So... If you're reading this message in your email box, you're subscribed to the list identified in the subject line, and all should be okay. If you're reading this message in the archives, wondering why you're not getting list mail, please take a moment to resubscribe yourself to the list, which should resolve your problem. And regardless, if you feel you missed any mail, we do have the archives available for your reference. IETF List Subscription Link: https://www.ietf.org/mailman/listinfo/ietf IETF List Archive Link: http://www.ietf.org/mail-archive/web/ietf/ SIP List Subscription Link: https://www.ietf.org/mailman/listinfo/sip SIP List Archive Link: http://www.ietf.org/mail-archive/web/sip/ We are in the home stretch of getting TMDA removed and replaced on the servers, and I apologize for any inconvenience caused by this issue. Because server problems apparently happen only in the dead of night, you can be sure that we feel any and all pain anyone may be experiencing. If you need any assistance, please contact the IETF Secretariat, using the links at: http://www.ietf.org/secretariat/ Thank you, Glen Barney IT Director AMS (IETF Secretariat) _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 02:59:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0518B3A6AA3; Mon, 30 Jun 2008 02:59:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A9E3A6AA6 for ; Mon, 30 Jun 2008 02:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1-Cv2IOK9GZ for ; Mon, 30 Jun 2008 02:59:37 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B1DDD3A687F for ; Mon, 30 Jun 2008 02:59:36 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m5U9xVJW009665; Mon, 30 Jun 2008 04:59:36 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 04:59:26 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 11:59:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 11:59:20 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800209C2B3@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups Thread-Index: AcjXZipKtZPN4grjQgmb+fT3O/KHuQAS5tAgADXtuQ0AAC9mAAABVrfLAIHpmDA= References: From: "DRAGE, Keith \(Keith\)" To: "Henry Sinnreich" , "Hadriel Kaplan" , "Hannes Tschofenig" , "Elwell, John" X-OriginalArrivalTime: 30 Jun 2008 09:59:22.0146 (UTC) FILETIME=[F8578020:01C8DA97] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: sip@ietf.org, Paul Kyzivat , Dan Wing Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In the context of the argument Hadriel is putting forward, he is correct. IMS deployments exist, but you can still regard what is out there as essentially IMS islands connected by the PSTN. For example, I suspect any Skype call you make to an IMS user is via the PSTN. And standards for direct interconnection of the enterprise SIP networks to IMS are relatively new, and we are still working on the bells and whistles. I would also note that some of the biggest users of mobiles for both voice and messaging are under 18, and they don't have Blackberrys, and the messaging they use is SMS over the CS network (i.e. PSTN), not over IP, at least in the 3GPP side of the house. Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Henry Sinnreich > Sent: Friday, June 27, 2008 8:54 PM > To: Hadriel Kaplan; Hannes Tschofenig; Elwell, John > Cc: sip@ietf.org; Paul Kyzivat; Dan Wing > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > See above - cell phones *are* the PSTN, at least so far they are. > > Any IMS folks here to agree with this? :-) > > Henry > > > On 6/27/08 12:31 PM, "Hadriel Kaplan" wrote: > > > > > > >> -----Original Message----- > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Friday, June 27, 2008 3:11 PM > >> To: Hadriel Kaplan; Hannes Tschofenig; Elwell, John > >> Cc: sip@ietf.org; Paul Kyzivat; Dan Wing > >> Subject: Re: [Sip] Toward the Evolution of SIP and Related Working > >> Groups > >> > >>> 1) Because most of their calls still go to/from the PSTN. > >> > >> I wonder if this may still be true: > >> - All employees have cell phones > > > > All cell phones *are* on the PSTN, for all intents and purposes to > > which the email was about. > > > >>> 3) Because voice means business/money for many Enterprises > >> > >> I wonder about this too. Except for the marketing and > support folks, > >> talking > > > > And sales, and brick-and-mortar retailers, and food delivery, and > > repair shops, and hotels, and restaurants, and financial trading > > floors, and most things found in thick yellow books or on business > > cards. I'm not saying commerce doesn't happen in other ways (duh), > > just that it also happens over voice. I have no idea if it's > > more/less than email or http or whatever (and I bet the > answer to that is regionally-specific), just that it's darn big. > > > > > >> Using voice at work (at some cost to the enterprise) seems > to me just > >> a bad habit or bad legacy, and is rather the exception, > not the rule. > >> > >> BTW: Don't you have a plain cell phone, iPhone or Blackberry? > > > > See above - cell phones *are* the PSTN, at least so far they are. > > > > -hadriel > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 09:35:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992813A6AFA; Mon, 30 Jun 2008 09:35:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68B33A6AFA for ; Mon, 30 Jun 2008 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 8nAlh1b9vo3Y for ; Mon, 30 Jun 2008 09:35:12 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ECEAC3A67B6 for ; Mon, 30 Jun 2008 09:35:11 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5UGZJon001267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 30 Jun 2008 11:35:23 -0500 Message-Id: <27427B41-3E2A-40D1-9F97-C5F29A5BD38A@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 11:35:14 -0500 X-Mailer: Apple Mail (2.924) Subject: [Sip] test, please ignore if you aren't Steve Pellegrino X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm still trying to clean up odds and ends from the recent meltdown of the mailing list. Sorry 'bout that. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 11:05:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D7028C0DB; Mon, 30 Jun 2008 11:05:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DC73A68FE for ; Mon, 30 Jun 2008 11:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 fxUUC8wXYElI for ; Mon, 30 Jun 2008 11:04:59 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1E5993A68FD for ; Mon, 30 Jun 2008 11:04:59 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m5UI4R3E004901 for ; Mon, 30 Jun 2008 13:05:05 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 13:04:36 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 20:04:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 20:04:33 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800209C48E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proto writeup for draft-ietf-sip-rph-new-namespaces-03 Thread-Index: Acja28AnYMfAmy/PSo2a8VgcFsLHWw== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 30 Jun 2008 18:04:34.0752 (UTC) FILETIME=[C0CEA400:01C8DADB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Sip] Proto writeup for draft-ietf-sip-rph-new-namespaces-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) I have just requested publication of draft-ietf-sip-rph-new-namespaces-03 The Proto writeup for this document is as follows: PROTO writeup for http://www.ietf.org/internet-drafts/ draft-ietf-sip-rph-new- namespaces-03.txt: " IANA Registration of New Session Initiation Protocol (SIP) Resource- Priority Header Namespaces" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: - draft-polk-sip-rph-new-namespaces-00 was submitted 26th February 2007 and expired 26th August 2007. - draft-polk-sip-rph-new-namespaces-01 was submitted 9th July 2007 and expired 9th January 2008. - draft-ietf-sip-rph-new-namespaces-00 was submitted 16th October 2007 and expired 16th April 2008. - draft-ietf-sip-rph-new-namespaces-01.txt was submitted 19th November 2007 and expired 17th May 2008. - draft-ietf-sip-rph-new-namespaces-02.txt was submitted 21st February 2008 and expires 21st August 2008. - draft-ietf-sip-rph-new-namespaces-03.txt was submitted 10th March 2008 and expires 10th September 2008. WGLC was initiated in the SIP WG on draft-ietf-sip-rph-new-namespaces-00 on 31st October 2007 with comments requested by 14th November 2007. Review was made and comments were received from: Janet Gunn, Joel Halpern, John Rosenberg, Henning Schulzrinne, Hannes Tschofenig, Dean Willis. During the course of the work comments have also been made by: Janet Gunn, Dale Worley. The main reason for the document is to create the IANA namespaces, but in the process of doing this it also requires one very small update to RFC 4412 in order to create the OPTIONAL delimiter, which would be opaque to implementers otherwise, and potentially causing implementations to not process the header (therefore message) correctly. One of the issues in the WGLC was the number of namespaces generated, which apparently contravenes RFC 4412 which essentially says that one should reuse existing namespaces if they are applicable, rather than going away and generating lots of new ones. There is text in section 1 of the document justifying this large allocation. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document has received review from a number of people whose interests lie in this particular field, in addition to the normal WG responses. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd has no concerns with this document. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document addresses a limited part of the SIP community, but is of significant interest in that part of the community. Within that limited community, there is strong consensus behind the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is believed that the document is conformant with those guidelines. For ID-NITS the checks against idnits 2.08.10 report no NITS found except: == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages which is a common fault which can be resolved readily during publication. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document contains only normative references. These references are both standards track documents, are published and have been verified to be normative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The main purpose of this document is to create additional entries in an existing IANA registry. The registry additions are clearly identified. The registry requirements for this existing registry is standards track required, which this document is. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no material written in a formal language, and as such there are no validation requirements. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Technical summary. This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. Working group summary. There is consensus in the working group to publish this document. Document Quality The document has received review by experts in the field as well as members of the SIP working group. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings. The IANA Expert(s) for the registries in this document are . _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 11:15:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB303A682E; Mon, 30 Jun 2008 11:15:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E723A68FE for ; Mon, 30 Jun 2008 11:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYpkn-RAukDl for ; Mon, 30 Jun 2008 11:15:16 -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 459423A68F5 for ; Mon, 30 Jun 2008 11:15:15 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5UIFLNR039235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Jun 2008 13:15:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <4E79ABB2-D399-4507-991D-6AB9660A3AC8@nostrum.com> From: Robert Sparks To: "SIP@ietf.org List" Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 13:15:21 -0500 X-Mailer: Apple Mail (2.924) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.1/7589/Mon Jun 30 12:07:41 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: Adam Roach Subject: [Sip] Possible semantic confusion w/ bodies in subscribes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org All (but particularly Jari and Adam) : What does the body of a request mean if you get a SUBSCRIBE to the "xcap-diff" event, and that subscribe contains a Require: recipient-list-subscribe ? I think we may have created some ambiguity here. If I'm wrong and it's clear, where is it captured in the documents? RjS _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 14:38:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52C53A6AE2; Mon, 30 Jun 2008 14:38:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24433A6AE2 for ; Mon, 30 Jun 2008 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf3qNr4LMx28 for ; Mon, 30 Jun 2008 14:38:04 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 0C9CA3A6A4C for ; Mon, 30 Jun 2008 14:38:04 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m5ULc81H022466; Mon, 30 Jun 2008 15:38:08 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 30 Jun 2008 15:38:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 15:38:08 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60128FC5D@srvxchg3.cablelabs.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progress draft-holmberg-sip-keep Thread-Index: AcjRkpnVfshskm2FTkKiI23wFbuvYAI039ag References: <5D1A7985295922448D5550C94DE2918002061E8B@DEEXC1U01.de.lucent.com> From: "Kevin Johns" To: "DRAGE, Keith (Keith)" , X-Approved: ondar Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Q1: I agree that the emergency services use case is important. However, I would like to see the statement that some devices do not support outbound but want to use the keep alive mechanism be further clarified (what devices this applies to and why they would not implement outbound - I think this has already been discussed on the list). Q2: Based on my comments to Q1, I would like to see the requirements narrowed in scope to only be in the context of a dialog initiating request outside of a registration. The reason being that outbound is the approach defined by the WG for client to Edge Proxy NAT traversal and I don't think there is a strong need for more tools which allow the creation of another NAT traversal solution. This narrowing of scope would still allow support by devices which would not implement outbound and are not providing edge proxy functionality. Regards, Kevin -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, June 19, 2008 3:31 AM To: sip@ietf.org Cc: Christer Holmberg Subject: [Sip] Progress draft-holmberg-sip-keep (As SIP WG cochair) We have been asked by the author of http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt Whether the SIP WG can progress this document. Because this draft arose as a result of the discussion of outbound, and indeed seems to reuse the requirements from outbound, and these requirements never really got handled in the SIPPING WG, it has been agreed with the SIPPING chairs that we will handle this entirely within SIP. Now in order to ask for charter milestones, and indeed when we finally present this to IESG, we will be asked for the level of support in the WG, which is also predicated on does this fix a real problem, or is it just a corner case with limited application. So: QUESTION 1 TO SIP WG: Are the use cases sufficiently important to proceed with this draft? The document states: Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] defines two keep-alive techniques. Even though the keep-alive techniques are separated from the Outbound mechanism [I-D.ietf-sip-outbound], it is currently not possible to indicate support of the keep-alive techniques without also indicating support for the Outbound mechanism. The Outbound mechanism is enabled during the UA registration phase. However, there are use-cases where the UA does not register itself, but still needs to be able to make calls and maintain NAT bindings open during the duration of that call. A typical example is emergency calls. There are also cases where entities do not support the Outbound mechanism, but still want to be able to indicate support and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. At first sight this is not the most inspiring declaration of the need for the document. Please respond indicating whether you consider this a useful draft, and propose text that you think would be useful in this section. Conversely, if you think this draft is not useful and the WG has other more important things to work on first, please also respond. QUESTION 2 TO SIP WG: Do we have a robust set of requirements for proceeding with this work? The document currently lists: REQ 1: It MUST be possible for a UA to indicate support of the keep- alive techniques defined [I-D.ietf-sip-outbound] if the UA supports only the keep-alive part of [I-D.ietf-sip-outbound]. REQ 2: It MUST be possible for an edge proxy to indicate support of the keep-alive techniques defined [I-D.ietf-sip-outbound] if the edge poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. It would be desirable to agree these at the outset, and not revisit them if we continue with the work. So if you require clarification, modification, or addition to these two requirements, then please also response with your questions and proposals. I suggest we would like responses by 30th June 2008 in order to allow the author to revise the document before the deadlines. Please note that we are looking to make this decision on the list within this deadline based on responses received, not leave it until the Dublin meeting. Regards Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 15:48:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90653A6B3A; Mon, 30 Jun 2008 15:48:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59D43A6AE2; Mon, 30 Jun 2008 15:48:00 -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 cHqXP96QLyfj; Mon, 30 Jun 2008 15:47:59 -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 68DC53A69C4; Mon, 30 Jun 2008 15:47:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,729,1204531200"; d="scan'208";a="46854717" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2008 15:48:11 -0700 Received: from mtcc13.mtcc.com ([10.21.64.4]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m5UMQxYM004273; Mon, 30 Jun 2008 15:26:59 -0700 Message-ID: <486962AA.3000800@cisco.com> Date: Mon, 30 Jun 2008 15:48:10 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Glen References: <48671722.1020502@amsl.com> In-Reply-To: <48671722.1020502@amsl.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2686; t=1214864819; x=1215728819; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20Subscriber=20List=20Damage |Sender:=20 |To:=20Glen=20; bh=7+YhQ4F+sLl14zte5OgtSyBe0SvjhdcSX1Y1SSeqkfE=; b=r8qA/ZqtI3koIcmlWeUA1aGyrEBUtJ9FepGtntbaBpUdufjBoTIJyUqib7 k01mNYAWv+7BOTCt/iHQkGxFEKwBmf5J+LY+U5XKc2g+pUntmN7UsILNwGwt BKYDMUaBkX; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, IAOC , ietf@ietf.org Subject: Re: [Sip] Subscriber List Damage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 1) Have you brought this up with the mailman folks? I've interacted with them and they seem like a responsive set of folks. I'm sure that this sort of thing would horrify them. 2) 3 years since the last backup? Oi. Mike Glen wrote: > All - > > I was asked by the IAOC to post a message to the IETF and SIP lists, > to ensure that people were aware that the subscriber lists for the > IETF and SIP lists were damaged as a result of an anomaly in TMDA and > Mailman that occurred Thursday night. > > Basically, TMDA misbehaved, and, in the process, caused Mailman to > encounter a transient failure in the reading of its databases for > these two lists. As a result, rather than simply holding the mail and > retrying it, Mailman decided to discard the current list databases and > re-create them from 3-year-old data, for both the IETF and the SIP lists. > > *sigh* > > No email was lost to the system or the archives; however, some people > may have missed some messages, or may still not be resubscribed to the > list. > > Of course we restored the files from backups; however, we want to make > sure that everyone gets the mail they missed, and that everyone is > subscribed to these lists who wishes to be subscribed. > > So... > > If you're reading this message in your email box, you're subscribed to > the list identified in the subject line, and all should be okay. > > If you're reading this message in the archives, wondering why you're > not getting list mail, please take a moment to resubscribe yourself to > the list, which should resolve your problem. > > And regardless, if you feel you missed any mail, we do have the > archives available for your reference. > > IETF List Subscription Link: https://www.ietf.org/mailman/listinfo/ietf > IETF List Archive Link: http://www.ietf.org/mail-archive/web/ietf/ > > SIP List Subscription Link: https://www.ietf.org/mailman/listinfo/sip > SIP List Archive Link: http://www.ietf.org/mail-archive/web/sip/ > > We are in the home stretch of getting TMDA removed and replaced on the > servers, and I apologize for any inconvenience caused by this issue. > Because server problems apparently happen only in the dead of night, > you can be sure that we feel any and all pain anyone may be experiencing. > > If you need any assistance, please contact the IETF Secretariat, using > the links at: http://www.ietf.org/secretariat/ > > Thank you, > Glen Barney > IT Director > AMS (IETF Secretariat) > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 17:36:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A033A6B3B; Mon, 30 Jun 2008 17:36:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4740E3A681F; Mon, 30 Jun 2008 17:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.492 X-Spam-Level: X-Spam-Status: No, score=-100.492 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 FeViMzITTqTz; Mon, 30 Jun 2008 17:36:52 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14]) by core3.amsl.com (Postfix) with ESMTP id 7AD713A67F7; Mon, 30 Jun 2008 17:36:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thunder2.amsl.com (Postfix) with ESMTP id AD4A7480B4; Mon, 30 Jun 2008 17:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([64.170.98.20]) by localhost (thunder2.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHaAOisN6XCx; Mon, 30 Jun 2008 17:37:12 -0700 (PDT) Received: from [192.168.1.100] (c-76-103-55-1.hsd1.ca.comcast.net [76.103.55.1]) by thunder2.amsl.com (Postfix) with ESMTP id 690B047ED5; Mon, 30 Jun 2008 17:37:12 -0700 (PDT) Message-ID: <48697C2F.7050207@amsl.com> Date: Mon, 30 Jun 2008 17:37:03 -0700 From: Glen User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Michael Thomas References: <48671722.1020502@amsl.com> <486962AA.3000800@cisco.com> In-Reply-To: <486962AA.3000800@cisco.com> X-Enigmail-Version: 0.95.6 Cc: sip@ietf.org, IAOC , ietf@ietf.org Subject: Re: [Sip] Subscriber List Damage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Michael Thomas wrote: > 1) Have you brought this up with the mailman folks? I've interacted with > them and they seem like a responsive set of folks. I'm sure that this > sort > of thing would horrify them. I haven't yet, but will try. They'll probably want more information than I can give them. > 2) 3 years since the last backup? Oi. No - not three years since the last backup. I have MUCH more recent backups than that, of course! Three years is the age of the file that I suspect mailman used to pull its old configuration from. An old copy of the database for those two lists that was just sitting around, not being used. Glen _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 18:35:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E1D3A6B41; Mon, 30 Jun 2008 18:35:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3933A6B3E; Mon, 30 Jun 2008 18:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 rbaz-ORX8L1I; Mon, 30 Jun 2008 18:35:02 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 842093A6B1E; Mon, 30 Jun 2008 18:35:02 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 93BD5509A9; Mon, 30 Jun 2008 18:42:18 -0700 (PDT) Date: Mon, 30 Jun 2008 18:42:18 -0700 From: Eric Rescorla To: Michael Thomas In-Reply-To: <486962AA.3000800@cisco.com> References: <48671722.1020502@amsl.com> <486962AA.3000800@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080701014218.93BD5509A9@romeo.rtfm.com> Cc: sip@ietf.org, IAOC , ietf@ietf.org, Glen Subject: Re: [Sip] Subscriber List Damage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Mon, 30 Jun 2008 15:48:10 -0700, Michael Thomas wrote: > > 1) Have you brought this up with the mailman folks? I've interacted with > them and they seem like a responsive set of folks. I'm sure that > this sort > of thing would horrify them. I agree that this is horrifying. More importantly, doesn't this mean that this is a problem we actually need a solution for pronto? As I understand Glen's message, he's saying that this is a bug in mailman triggered by some problem in TMDA. I realize that TMDA is being replaced, but presumably Henrik's code isn't perfect, so don't we have to worry about it triggering the same behavior? Glen, I'm sure there are some people on this list who understand mailman well. I realize you may not have complete info, but if you can provide us some more information--e.g., what file(s) got stomped and which code you think stomped it--about what you think happened, maybe they can help track it down? -Ekr > 2) 3 years since the last backup? Oi. > > Mike > > Glen wrote: > > All - > > > > I was asked by the IAOC to post a message to the IETF and SIP lists, > > to ensure that people were aware that the subscriber lists for the > > IETF and SIP lists were damaged as a result of an anomaly in TMDA and > > Mailman that occurred Thursday night. > > > > Basically, TMDA misbehaved, and, in the process, caused Mailman to > > encounter a transient failure in the reading of its databases for > > these two lists. As a result, rather than simply holding the mail and > > retrying it, Mailman decided to discard the current list databases and > > re-create them from 3-year-old data, for both the IETF and the SIP lists. > > > > *sigh* > > > > No email was lost to the system or the archives; however, some people > > may have missed some messages, or may still not be resubscribed to the > > list. > > > > Of course we restored the files from backups; however, we want to make > > sure that everyone gets the mail they missed, and that everyone is > > subscribed to these lists who wishes to be subscribed. > > > > So... > > > > If you're reading this message in your email box, you're subscribed to > > the list identified in the subject line, and all should be okay. > > > > If you're reading this message in the archives, wondering why you're > > not getting list mail, please take a moment to resubscribe yourself to > > the list, which should resolve your problem. > > > > And regardless, if you feel you missed any mail, we do have the > > archives available for your reference. > > > > IETF List Subscription Link: https://www.ietf.org/mailman/listinfo/ietf > > IETF List Archive Link: http://www.ietf.org/mail-archive/web/ietf/ > > > > SIP List Subscription Link: https://www.ietf.org/mailman/listinfo/sip > > SIP List Archive Link: http://www.ietf.org/mail-archive/web/sip/ > > > > We are in the home stretch of getting TMDA removed and replaced on the > > servers, and I apologize for any inconvenience caused by this issue. > > Because server problems apparently happen only in the dead of night, > > you can be sure that we feel any and all pain anyone may be experiencing. > > > > If you need any assistance, please contact the IETF Secretariat, using > > the links at: http://www.ietf.org/secretariat/ > > > > Thank you, > > Glen Barney > > IT Director > > AMS (IETF Secretariat) > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 30 19:29:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100523A6B6A; Mon, 30 Jun 2008 19:29:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DC03A6B2F; Mon, 30 Jun 2008 19:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.892 X-Spam-Level: X-Spam-Status: No, score=-99.892 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_63=0.6, RDNS_NONE=0.1, 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 ycEFK-gEJjSH; Mon, 30 Jun 2008 19:29:56 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14]) by core3.amsl.com (Postfix) with ESMTP id 76E2E3A6AF6; Mon, 30 Jun 2008 19:29:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thunder2.amsl.com (Postfix) with ESMTP id AE6F6480B4; Mon, 30 Jun 2008 19:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([64.170.98.20]) by localhost (thunder2.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF2gLXBaL0j3; Mon, 30 Jun 2008 19:30:16 -0700 (PDT) Received: from [192.168.1.100] (c-76-103-55-1.hsd1.ca.comcast.net [76.103.55.1]) by thunder2.amsl.com (Postfix) with ESMTP id 23636480B3; Mon, 30 Jun 2008 19:30:16 -0700 (PDT) Message-ID: <486996AC.2050405@amsl.com> Date: Mon, 30 Jun 2008 19:30:04 -0700 From: Glen User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eric Rescorla References: <48671722.1020502@amsl.com> <486962AA.3000800@cisco.com> <20080701014218.93BD5509A9@romeo.rtfm.com> In-Reply-To: <20080701014218.93BD5509A9@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 Cc: sip@ietf.org, IAOC , Michael Thomas , ietf@ietf.org Subject: Re: [Sip] Subscriber List Damage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Unfortunately I really don't have anything but assumptions about what happened at this point. An increase in TMDA activity caused the system to run out of resources. We saw an extremely high load average and a sudden decrease in kernel buffer memory. Processes started to fail to fork. Our engineers connected in, and rebooted the server. Upon reboot, we quickly discovered that the IETF list, which we moderate, was no longer letting us in with the normal list password. A quick check showed that the database file config.pck was now only about 50% of its original size, and that many subscribers had been removed - and others added. Passwords and other settings had been "reverted" to pre-cutover values. A comparison with our recent backup of the file showed massive differences - not just removals, but additions. We hypothesize that mailman fell back to some type of cached copy of the database from 2005, which was also in the directory, and recreated the data from that. Unfortunately, we have no way to verify what happened, and certainly don't want to try to cause it again. I believe our solution is going to be to remove TMDA completely, which, I believe will eliminate the side-effects we've been seeing such as this. I'm happy to discuss this further; however, I do not want to pollute the various lists with this. I'm cc'ing the lists in this case so everyone understands we are responding to emails, but I'm going to take any further threads off-list to keep the lists focused on their primary purposes. Glen Eric Rescorla wrote: > At Mon, 30 Jun 2008 15:48:10 -0700, > Michael Thomas wrote: >> 1) Have you brought this up with the mailman folks? I've interacted with >> them and they seem like a responsive set of folks. I'm sure that >> this sort >> of thing would horrify them. > > I agree that this is horrifying. > > More importantly, doesn't this mean that this is a problem we actually > need a solution for pronto? As I understand Glen's message, he's > saying that this is a bug in mailman triggered by some problem in > TMDA. I realize that TMDA is being replaced, but presumably Henrik's > code isn't perfect, so don't we have to worry about it triggering the > same behavior? > > Glen, I'm sure there are some people on this list who understand > mailman well. I realize you may not have complete info, but if you can > provide us some more information--e.g., what file(s) got stomped and > which code you think stomped it--about what you think happened, maybe > they can help track it down? > > -Ekr > > >> 2) 3 years since the last backup? Oi. >> >> Mike >> >> Glen wrote: >>> All - >>> >>> I was asked by the IAOC to post a message to the IETF and SIP lists, >>> to ensure that people were aware that the subscriber lists for the >>> IETF and SIP lists were damaged as a result of an anomaly in TMDA and >>> Mailman that occurred Thursday night. >>> >>> Basically, TMDA misbehaved, and, in the process, caused Mailman to >>> encounter a transient failure in the reading of its databases for >>> these two lists. As a result, rather than simply holding the mail and >>> retrying it, Mailman decided to discard the current list databases and >>> re-create them from 3-year-old data, for both the IETF and the SIP lists. >>> >>> *sigh* >>> >>> No email was lost to the system or the archives; however, some people >>> may have missed some messages, or may still not be resubscribed to the >>> list. >>> >>> Of course we restored the files from backups; however, we want to make >>> sure that everyone gets the mail they missed, and that everyone is >>> subscribed to these lists who wishes to be subscribed. >>> >>> So... >>> >>> If you're reading this message in your email box, you're subscribed to >>> the list identified in the subject line, and all should be okay. >>> >>> If you're reading this message in the archives, wondering why you're >>> not getting list mail, please take a moment to resubscribe yourself to >>> the list, which should resolve your problem. >>> >>> And regardless, if you feel you missed any mail, we do have the >>> archives available for your reference. >>> >>> IETF List Subscription Link: https://www.ietf.org/mailman/listinfo/ietf >>> IETF List Archive Link: http://www.ietf.org/mail-archive/web/ietf/ >>> >>> SIP List Subscription Link: https://www.ietf.org/mailman/listinfo/sip >>> SIP List Archive Link: http://www.ietf.org/mail-archive/web/sip/ >>> >>> We are in the home stretch of getting TMDA removed and replaced on the >>> servers, and I apologize for any inconvenience caused by this issue. >>> Because server problems apparently happen only in the dead of night, >>> you can be sure that we feel any and all pain anyone may be experiencing. >>> >>> If you need any assistance, please contact the IETF Secretariat, using >>> the links at: http://www.ietf.org/secretariat/ >>> >>> Thank you, >>> Glen Barney >>> IT Director >>> AMS (IETF Secretariat) >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 1 01:45:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CB43A6B5C; Tue, 1 Jul 2008 01:45:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933D53A6B5C for ; Tue, 1 Jul 2008 01:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_27=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 kyNgur3DoC2D for ; Tue, 1 Jul 2008 01:45:44 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.119.2.190]) by core3.amsl.com (Postfix) with ESMTP id E821A3A6A94 for ; Tue, 1 Jul 2008 01:45:43 -0700 (PDT) Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly18f.srv.mailcontrol.com (MailControl) with ESMTP id m618iF7j022903 for ; Tue, 1 Jul 2008 09:45:47 +0100 Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 09:47:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Jul 2008 09:45:53 +0100 Message-ID: <680808427CF931459462C3D78CB5EC60027C44EC@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity WG name Thread-Index: AcjYgglzP3w4l2+GT9y1YzR/SlnSygC0/HJw From: "Attila Sipos" To: Cc: X-OriginalArrivalTime: 01 Jul 2008 08:47:11.0373 (UTC) FILETIME=[0D69BBD0:01C8DB57] X-Scanned-By: MailControl A-08-50-03 (www.mailcontrol.com) on 10.70.0.128 Subject: Re: [Sip] SIP Identity WG name X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org RETIRE sounds like a WG to discuss features that are going to be deprecated. and INSIPID sounds... insipid. SIGNED for me unless... Can we use SIPID? is SIPID taken? OK, it's not a real word but it means "what it says on the tin". -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dan York Sent: 27 June 2008 19:14 To: Paul Kyzivat; sip-bounces@ietf.org; Hadriel Kaplan Cc: sip@ietf.org Subject: Re: [Sip] SIP Identity WG name I like SIGNED. I agree that RETIRE wasn't the right name. My 2 cents, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com -----Original Message----- From: Paul Kyzivat Date: Fri, 27 Jun 2008 14:07:49 To:Hadriel Kaplan Cc:"sip@ietf.org" Subject: Re: [Sip] SIP Identity WG name Another vote for INSIPID :) Hadriel Kaplan wrote: > I don't know if people care, but since email is free: it would be nice to decide on a name for this potential group, and RETIRE is kinda a downer. > > Potential names: > RETIRE - "REal Time Identity and Role Expression" > SIGNED - "Sip Identity for Generic Name and E.164 Deployments" > SIGN - "Sip Identity for Global Names" > RISE - "Roles and Identities in SIP Environments" > > Or if you prefer a tounge-in-cheek approach: > RESIGN - "Roles and Establishment for SIP Identities of Generic Nature" (which would be pronounced either as the act of signing again as in "re-sign", or of retiring as in "resign") > INSIPID - "INternet SIP IDentities" (which could be pronounced either as "in SIP-ID", or the word insipid) > > So far we have 3 votes for INSIPID and 1 vote for SIGNED. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
For e.g. in the scenario = below, when proxy=20 receives 403 on leg 2, and it is yet to receive responses on leg 3 and=20 4. In this case, the proxy = cannot=20 send a 199 to the UAC (is my understanding, please correct if=20 wrong).