From sip-bounces@ietf.org Tue Sep 21 20:51:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16943 for ; Tue, 21 Sep 2004 20:51:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9vSd-0002GF-Iq for sip-web-archive@ietf.org; Tue, 21 Sep 2004 20:58:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9vJ1-0008MC-PI; Tue, 21 Sep 2004 20:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9vIL-0008AG-E8 for sip@megatron.ietf.org; Tue, 21 Sep 2004 20:47:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16711 for ; Tue, 21 Sep 2004 20:47:39 -0400 (EDT) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9vOo-0002Cj-QR for sip@ietf.org; Tue, 21 Sep 2004 20:54:23 -0400 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Sep 2004 17:39:22 -0700 From: "Thomas Gal" To: "'vikram'" , "'sip-ietf'" Subject: RE: [Sip] call stateful ? Date: Tue, 21 Sep 2004 17:47:06 -0700 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSb789DbsoedRTMQXKfAMerVgu/iwETbOxw In-reply-to: <2D0CA64CDC33E14DA7AB043B8CC4D2BB0258BA2E@svr-exc.domain.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 22 Sep 2004 00:39:22.0984 (UTC) FILETIME=[9ADC7E80:01C4A03C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit That means a proxy tracks the transaction ID not the session ID. For example once the invite has completed a proxy may know nothing about the call that it connected while for a brief period of time it was "aware" (read maintaining state) that it was in the middle of an invite command. -Tom > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of vikram > Sent: Thursday, September 16, 2004 6:26 AM > To: sip-ietf > Subject: [Sip] call stateful ? > > hello all, > Could anybody pls explain following from rfc 3261 > > " *A call stateful proxy is always transaction stateful, > but the converse is not necessarily true"* > > > regards > > Vikram > > _______________________________________________ > 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://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 From sip-bounces@ietf.org Wed Sep 22 00:55:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00730 for ; Wed, 22 Sep 2004 00:55:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9zH2-00065p-Sf for sip-web-archive@ietf.org; Wed, 22 Sep 2004 01:02:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9z8k-0007l8-6A; Wed, 22 Sep 2004 00:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9z1H-0006Lb-6k; Wed, 22 Sep 2004 00:46:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29909; Wed, 22 Sep 2004 00:46:16 -0400 (EDT) Received: from smtp.persistent.co.in ([202.54.11.65] helo=smtp.pspl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9z7l-0005qG-T4; Wed, 22 Sep 2004 00:53:03 -0400 Received: from grandin (verazgw.intranet.persistent.co.in [10.33.1.80]) (authenticated bits=0) by smtp.pspl.co.in (8.12.9/8.12.9) with ESMTP id i8M4NY5x007607; Wed, 22 Sep 2004 09:53:35 +0530 From: "Umesh Sharma" To: , "sip" Subject: RE: [Sip] Need guidance in call transfer - SIP Based Date: Wed, 22 Sep 2004 09:53:46 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit pls see inline. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Anurag Kabra (by way of Anurag Kabra) (by way of Anurag Kabra ) Sent: Monday, September 20, 2004 1:24 PM To: sip@ietf.org Subject: [Sip] Need guidance in call transfer - SIP Based I am currently working on VoIP, and I am located in India. I have few queries which are bothering me, could you suggest me something on them. Below are my queries. 1. Do we do retransmission for Refer Request(& Notify) if it doesnot reach transferee. >> timeout/retransmission mechanism for refer is same as for bye, non-invite transactions; when notify times out it is not retransmitted & correp. subscription should be removed. 2. In a unattended call transfer, when does the dialog end i.e. normally with a BYE or Notify(subscriptio-state="terminated"). 3. Does the dialog exists even after BYE or subscription-state header in Notify will terminate the dialog. 2, 3>> my understanding from rfc 3265 bye would not terminate the dialog if there is subscription on it, subscriber-state="terminated" destroys the subscription and the dialog if no other application state is associated with the dialog (more in 3.3.4 rfc 3265). For Call transfer refer goes with in existing dialog. 4. Is 202 Accepted sent after getting a REFER request, ignored by the transferor. What is the effect of the response 202 Accepted? >> it indicates that the subscription has been accepted and that authorization to proceed with transfer may or may not have been granted. Also, that a notify will be sent immediately (3.1.4.1). It also creates a new dialog & subscription if the initial refer was not sent on a pre-existing dialog otherwise it just creates the new subscription with the dialog. This is all for now. Hope to hear from you soon. Thanks in advance. Best Regards Anurag. _______________________________________________ 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://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 From sip-bounces@ietf.org Wed Sep 22 04:35:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13521 for ; Wed, 22 Sep 2004 04:35:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA2i2-0001XW-N8 for sip-web-archive@ietf.org; Wed, 22 Sep 2004 04:42:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA2ZQ-0002A0-4H; Wed, 22 Sep 2004 04:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA2XD-0001ob-2y for sip@megatron.ietf.org; Wed, 22 Sep 2004 04:31:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13350 for ; Wed, 22 Sep 2004 04:31:28 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA2dk-0001UF-3F for sip@ietf.org; Wed, 22 Sep 2004 04:38:16 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8M8V2hO005136 for ; Wed, 22 Sep 2004 10:31:02 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8M8V09a012590 for ; Wed, 22 Sep 2004 10:31:00 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Sep 2004 10:30:10 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692195@hrtades7.atea.be> From: Goeman Stefan To: "'sip@ietf.org'" Subject: [Sip]: SIP and SAML Date: Wed, 22 Sep 2004 10:30:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1042764901==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1042764901== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A07E.1CB0EEDC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4A07E.1CB0EEDC Content-Type: text/plain Hello, I was wondering if somebody already reviewed the ID draft-tschofenig-sip-saml-00.txt. This draft explicitly mentions that its main goal is not to realize single sign-on (SSO) functionality as in HTTP. However, I wonder if it would not be a good idea to realize SSO functionality with SAML in SIP. Right now, 3GPP has defined IMS-AKA. This procedure authenticates the end-user when sending an initial SIP Register request to the P-CSCF. It must be noted that this is an MNO-centric approach; the MNO owning both a wireless access network and an IMS domain. However, it is not unthinkable that in the future there will exist entities that will only operate an IMS domain. In this case, end-users will be authenticated by the (wireless) access network provider. Then, I believe it makes sense that the access network provider would provide SAML assertions to the IMS operator providing information on the authentication status of the end-user. How this should be done is unclear to me; I do have some initial ideas though. Anybody willing to comment? Thanks in advance! Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN Stefan.Goeman@siemens.com ------_=_NextPart_001_01C4A07E.1CB0EEDC Content-Type: text/html Content-Transfer-Encoding: quoted-printable [Sip]: SIP and SAML

Hello,

I was wondering if somebody already = reviewed the ID draft-tschofenig-sip-saml-00.txt.

This draft explicitly mentions that = its main goal is not to realize single sign-on (SSO) functionality as = in HTTP.
However, I wonder if it would not be = a good idea to realize SSO functionality with SAML in SIP. Right now, = 3GPP has defined IMS-AKA. This procedure authenticates the end-user = when sending an initial SIP Register request to the P-CSCF. It must be = noted that this is an MNO-centric approach; the MNO owning both a = wireless access network and an IMS domain.

However, it is not unthinkable that in = the future there will exist entities that will only operate an IMS = domain. In this case, end-users will be authenticated by the (wireless) = access network provider. Then, I believe it makes sense that the access = network provider would provide SAML assertions to the IMS operator = providing information on the authentication status of the end-user. =

How this should be done is unclear to = me; I do have some initial ideas though.

Anybody willing to comment?

Thanks in advance!

Greetings,
Stefan.


Stefan = Goeman
SIEMENS ICM/ICN
Stefan.Goeman@siemens.com=20
        =

------_=_NextPart_001_01C4A07E.1CB0EEDC-- --===============1042764901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --===============1042764901==-- From sip-bounces@ietf.org Wed Sep 22 05:25:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16355 for ; Wed, 22 Sep 2004 05:25:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3U3-0002JL-O7 for sip-web-archive@ietf.org; Wed, 22 Sep 2004 05:32:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3Kg-0003xb-08; Wed, 22 Sep 2004 05:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3Jo-0003lz-En for sip@megatron.ietf.org; Wed, 22 Sep 2004 05:21:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16045 for ; Wed, 22 Sep 2004 05:21:41 -0400 (EDT) Received: from web14224.mail.yahoo.com ([66.163.171.108]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CA3QB-0002FO-Gs for sip@ietf.org; Wed, 22 Sep 2004 05:28:30 -0400 Message-ID: <20040922092131.31780.qmail@web14224.mail.yahoo.com> Received: from [192.76.54.22] by web14224.mail.yahoo.com via HTTP; Wed, 22 Sep 2004 02:21:31 PDT Date: Wed, 22 Sep 2004 02:21:31 -0700 (PDT) From: brijesh nair To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] Performance testing tools for SIP entities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi, I am looking for good performace testing tools (free or otherwise) which can be used to test various SIP entities (e.g B2BUA, Proxy Servers etc.). Can anyone help on this?? Thanks, Brijesh _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 22 05:39:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17690 for ; Wed, 22 Sep 2004 05:39:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3hp-0002bA-Df for sip-web-archive@ietf.org; Wed, 22 Sep 2004 05:46:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3WT-00069t-6f; Wed, 22 Sep 2004 05:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3TL-0005jG-NR for sip@megatron.ietf.org; Wed, 22 Sep 2004 05:31:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16903 for ; Wed, 22 Sep 2004 05:31:32 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3Zs-0002RO-IQ for sip@ietf.org; Wed, 22 Sep 2004 05:38:22 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8M9VTfM017003 for ; Wed, 22 Sep 2004 11:31:32 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Sep 2004 11:31:28 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Sep 2004 11:31:28 +0200 Message-ID: <633A2BAC69E8D411819A00508BCF883C0DA5F66D@esealnt452.al.sw.ericsson.se> From: "Thomas Johansson G (HF/EAB)" To: "'brijesh nair'" , sip@ietf.org Subject: RE: [Sip] Performance testing tools for SIP entities Date: Wed, 22 Sep 2004 11:30:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Sep 2004 09:31:28.0956 (UTC) FILETIME=[F03937C0:01C4A086] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Sipp from HP might fulfil your needs (freeware): http://sourceforge.net/projects/sipp Sipp is a performance testing tool for the SIP protocol. Its main features are basic SIPStone scenarios, TCP/UDP transport, customizable (xml based) scenarios, dynamic adjustement of call-rate and a comprehensive set of real-time statistics. BRs /Thomas -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of brijesh nair Sent: den 22 september 2004 11:22 To: sip@ietf.org Subject: [Sip] Performance testing tools for SIP entities Hi, I am looking for good performace testing tools (free or otherwise) which can be used to test various SIP entities (e.g B2BUA, Proxy Servers etc.). Can anyone help on this?? Thanks, Brijesh _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ 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://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 From sip-bounces@ietf.org Wed Sep 22 05:41:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17985 for ; Wed, 22 Sep 2004 05:41:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3jt-0002eb-LA for sip-web-archive@ietf.org; Wed, 22 Sep 2004 05:48:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3YD-0006So-O4; Wed, 22 Sep 2004 05:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3U6-0005nw-8Q for sip@megatron.ietf.org; Wed, 22 Sep 2004 05:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16977 for ; Wed, 22 Sep 2004 05:32:19 -0400 (EDT) Received: from usagi.ingate.se ([193.180.23.12] ident=[ZbfzZbFCn+5YnVw30qJ7iUGUjPXDKvPE]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3aU-0002S2-5E for sip@ietf.org; Wed, 22 Sep 2004 05:39:08 -0400 Received: from conar.ingate.se (IDENT:8ZVqQYahP95z1oyxFOxOCIjI7JJGxZmz@conar.ingate.se [193.180.23.103]) (authenticated bits=0) by usagi.ingate.se (8.12.8/8.12.8) with ESMTP id i8M9W7Bx008364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2004 11:32:09 +0200 Date: Wed, 22 Sep 2004 11:32:07 +0200 (CEST) From: =?ISO-8859-1?Q?Bj=F6rn_Gr=F6nesj=F6?= X-X-Sender: bg@conar.ingate.se To: brijesh nair Subject: Re: [Sip] Performance testing tools for SIP entities In-Reply-To: <20040922092131.31780.qmail@web14224.mail.yahoo.com> Message-ID: References: <20040922092131.31780.qmail@web14224.mail.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1262393577-1882252819-1095845527=:16071" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1262393577-1882252819-1095845527=:16071 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Try: SIPp - sipp.sourceforge.net //Bj=F6rn On Wed, 22 Sep 2004, brijesh nair wrote: > Hi, > I am looking for good performace testing tools (free > or otherwise) which can be used to test various SIP > entities (e.g B2BUA, Proxy Servers etc.). Can anyone > help on this?? > > Thanks, > Brijesh > > > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com > > _______________________________________________ > 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 > ---1262393577-1882252819-1095845527=:16071 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 ---1262393577-1882252819-1095845527=:16071-- From sip-bounces@ietf.org Wed Sep 22 08:58:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02959 for ; Wed, 22 Sep 2004 08:58:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA6oK-0006JC-Lq for sip-web-archive@ietf.org; Wed, 22 Sep 2004 09:05:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA6W6-0002JH-Dx; Wed, 22 Sep 2004 08:46:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA6Mz-0008O0-4M for sip@megatron.ietf.org; Wed, 22 Sep 2004 08:37:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01232 for ; Wed, 22 Sep 2004 08:37:11 -0400 (EDT) Received: from [203.129.224.106] (helo=kr.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA6TO-0005t0-56 for sip@ietf.org; Wed, 22 Sep 2004 08:44:01 -0400 Received: from Amit ([10.0.0.169]) by kr.aftek.com (8.11.6/8.11.6) with ESMTP id i8MCav901981 for ; Wed, 22 Sep 2004 18:06:58 +0530 Content-Type: text/plain; charset="us-ascii" From: Anurag Kabra Organization: Aftek Infosys Ltd. To: sip@ietf.org Date: Wed, 22 Sep 2004 18:10:31 +0530 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200409221810.31676.anuragk@aftek.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Voice Mail X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Hello Everyone I need some links detailing Voice Mail Client implementation based on SIP= =2E =20 Thank You in advance. Best Regards Anurag. _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 22 10:19:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10908 for ; Wed, 22 Sep 2004 10:19:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA84x-00081h-DX for sip-web-archive@ietf.org; Wed, 22 Sep 2004 10:26:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA7t4-0006I8-6z; Wed, 22 Sep 2004 10:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA7sU-00060b-DJ for sip@megatron.ietf.org; Wed, 22 Sep 2004 10:13:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09829 for ; Wed, 22 Sep 2004 10:13:48 -0400 (EDT) Received: from zaz.kom.auc.dk ([130.225.51.10] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA7z3-0007uc-Uz for sip@ietf.org; Wed, 22 Sep 2004 10:20:39 -0400 Received: from bs-w2k.kom.auc.dk ([192.168.110.161] helo=BSW2K) by zaz.kom.auc.dk with smtp (Exim 2.05 #3) id 1CA7sQ-0006qo-00 for sip@ietf.org; Wed, 22 Sep 2004 16:13:46 +0200 From: "Thibault Renier" To: Date: Wed, 22 Sep 2004 16:13:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01C4A0BF.248721D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Sip] SIP and MIP addressing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C4A0BF.248721D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, I am currently working on integrating SIP in architecture using Mobile IP for mobility support. My question concerns the addressing scheme: At the SIP layer a SIP URI specifies the destination point ("To" field), going from SIP hop to SIP hop. At the IP layer, the destination address is usually the same as the current IP address (Care of Address in the MIP jargon -CoA) that corresponds to the URI used in the "To" (I guess that the association URI/current IP address of a user is made possible during the registration procedure). When MIP is used at the IP layer, for communications from the Correspondent Node (CN) to the Mobile Node (MN), the destination address is the MN's home address and the packets should be intercepted by the Home Agent (HA). 1. What is the route in a system combining MIP for mobility support and SIP for signalling flow? Do the packets go through all the SIP servers/hops before applying the MIP routing solutions? 2. What does happen because of the 'conflict' of addresses? (SIP resolves the URI with the CoA, while IP uses the MN's home address at first) Thanks for your help /Tibo ------=_NextPart_000_0028_01C4A0BF.248721D0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjAOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHCQAWABAADQAAAAMAGgEB A5AGAFgHAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAFwAAAFNJUCBhbmQgTUlQIGFkZHJlc3NpbmcAAAIBcQABAAAAFgAAAAHEoK5cU4d69zuU0UES s1Q1b8lXdhwAAAIBHQwBAAAAFwAAAFNNVFA6VE9VQklYQEtPTS5BVUMuREsAAAsAAQ4AAAAAQAAG DgD+EUSuoMQBAgEKDgEAAAAYAAAAAAAAAEZyA5xPQ1JGjIe7cgmJzRPCgAAACwAfDgEAAAACAQkQ AQAAAGsDAABnAwAACgUAAExaRnVPsI1UAwAKAHJjcGcxMjWWMgD4C2BuDhAwMwHoJwKkA+MCAGNo CsBzZVh0MCAHEwKAfQqBdkkIkHdrC4BkNAxgY4cAUAsDC7UgSGkgB0BcbCwKogqECoBJE/BtHCBj CHAJcAIwbHkgpncFsBJhZyACICALgCR0ZQnAYXQWMlNJVlAWkRPwchDgaRbAY2J0CHBlIHUAkBZB TfxvYgMQGIAXcQIQBcAEYIcZIRgQFdBzdXBwCRGqLhRETRXQcQpQcxcQMxZxBaBuYwSRBCB0aPEY gGFkZAlwBBAWMgTw6xywB4A6FERBBUAcohdinQtgeQSQE/AXU1VSFQD8c3AFkAaQCJAchAEAG7Ee bhcBFnEaoBahICgiGFRvIhmQCJBsZCl4LCBnIcEWUANSF1No1G9wHJBvI5YuEWAedH8e5iLQIL4c 5RaQBCAYoHX3FAEV0ByicxUgHMEchBVVMxliJvYoQwrAGIBvZq8RYCcGA6Acok0XcWoKwMsi8AOg LQhQQSkckRcA7xwBFXEgEAIgZByBJDAcol8f0higCYArViIjKBUAZ98bkRyCLQEcowQQbyBAIVT9 H9EvKS8EICqxH3AuoQXA/ydxAMABACGhHTECYCDRCHHXFkEcoglwZwQAdBbyIYKnA2AcQDSxZSkk wFccsP8DoCvSJ3MuwTBlJVgZogWg6G1tdQMAYyFTBCAjU28coghQLVYpYk4EcSpBTu8swS4EGQU7 tE08ICXfJur5K5NOJwQgI+AogicFAHBnLtAcogqwY2sRMAQgc+Uj4HUioCBiGIAWohfgVmUFMC7B YigESEAyQbJnKWIoSCywGuUxNtJ3LQE/ZQNgdRbAF5MaYHn/G7AdwDlCGSADABjSGX8ahO9A4xdi SBIAkGchQBQQIxPhCQB3PyBELgRBdiLwcxyRRhFnaBPyHoczYXb5BJBzLyPhBCBCYEgRHMH/GpAV wDTmK9JGEh1TBvBQAZc6AUsQFEQyRTVkbweR/xDwGpA3EUJgOcAuoSqiHKLOJxwRDvAN4HQnMvMc 9PsHkEsQKBdiHREG8E3AHISvH9ID8BygOoVBItB3GAB/GUQuoT9/QIYFQCBgERB0yikUSlQQ8G5r OiEFsa55CGEj0CKQcBRELwdgFwbgFEQR4QBdkAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAA AAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYA AAAAUoUAAH1uAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwANgAgg BgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA AAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAADAHOACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAg4AIIAYAAAAAAMAAAAAA AABGAAAAAAaFAAAAAAAAAgH4DwEAAAAQAAAARnIDnE9DUkaMh7tyCYnNEwIB+g8BAAAAEAAAAEZy A5xPQ1JGjIe7cgmJzRMCAfsPAQAAAJYAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRM TAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXHRpYm9c TG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29r LnBzdAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAA8RkNFR0lNSUhQTkFBQUtCRklDRkFP RU9GQ0VBQS50b3ViaXhAa29tLmF1Yy5kaz4AAAAAAwAGEEJm9swDAAcQlAMAAAMAEBAAAAAAAwAR EAAAAAAeAAgQAQAAAGUAAABISUFMTCxJQU1DVVJSRU5UTFlXT1JLSU5HT05JTlRFR1JBVElOR1NJ UElOQVJDSElURUNUVVJFVVNJTkdNT0JJTEVJUEZPUk1PQklMSVRZU1VQUE9SVE1ZUVVFU1RJT05D T05DAAAAADHN ------=_NextPart_000_0028_01C4A0BF.248721D0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 ------=_NextPart_000_0028_01C4A0BF.248721D0-- From sip-bounces@ietf.org Wed Sep 22 10:55:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14528 for ; Wed, 22 Sep 2004 10:55:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA8cy-0000Nq-3H for sip-web-archive@ietf.org; Wed, 22 Sep 2004 11:01:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA8Kd-0007WY-2L; Wed, 22 Sep 2004 10:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA8F0-0005L7-1x for sip@megatron.ietf.org; Wed, 22 Sep 2004 10:37:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12683 for ; Wed, 22 Sep 2004 10:37:03 -0400 (EDT) Received: from clint.songbird.com ([208.184.79.11] helo=joy.songbird.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA8La-0008Q4-H5 for sip@ietf.org; Wed, 22 Sep 2004 10:43:55 -0400 Received: from RSHOCKEY-LTXP.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i8MEaMq17063; Wed, 22 Sep 2004 07:36:23 -0700 Message-Id: <6.1.0.6.2.20040922102253.04e18210@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Wed, 22 Sep 2004 10:24:46 -0400 To: Goeman Stefan , "'sip@ietf.org'" From: Richard Shockey Subject: Re: [Sip]: SIP and SAML In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F195692195@hrtades7.atea.be> References: <57FD2C3A246F76438CA6FDAD8FE9F195692195@hrtades7.atea.be> Mime-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0385867311==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c --===============0385867311== Content-Type: multipart/alternative; boundary="=====================_1513416==.ALT" --=====================_1513416==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:30 AM 9/22/2004, Goeman Stefan wrote: >Hello, > >I was wondering if somebody already reviewed the ID >draft-tschofenig-sip-saml-00.txt. > >This draft explicitly mentions that its main goal is not to realize single >sign-on (SSO) functionality as in HTTP. >However, I wonder if it would not be a good idea to realize SSO >functionality with SAML in SIP. Right now, 3GPP has defined IMS-AKA. This >procedure authenticates the end-user when sending an initial SIP Register >request to the P-CSCF. It must be noted that this is an MNO-centric >approach; the MNO owning both a wireless access network and an IMS domain. > >However, it is not unthinkable that in the future there will exist >entities that will only operate an IMS domain. In this case, end-users >will be authenticated by the (wireless) access network provider. Then, I >believe it makes sense that the access network provider would provide SAML >assertions to the IMS operator providing information on the authentication >status of the end-user. IMHO this is only one useful application of SAML to the SIP environment. I was personally disappointed this document did not recieve more attention in SanDiego I hope it will be given a broader hearing in DC. There are a variety of issues related to SIP security and Identity that SAML could solve. >How this should be done is unclear to me; I do have some initial ideas >though. > >Anybody willing to comment? > >Thanks in advance! > >Greetings, >Stefan. > >Stefan Goeman >SIEMENS ICM/ICN >Stefan.Goeman@siemens.com > >_______________________________________________ >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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --=====================_1513416==.ALT Content-Type: text/html; charset="us-ascii" At 04:30 AM 9/22/2004, Goeman Stefan wrote:

Hello,

I was wondering if somebody already reviewed the ID draft-tschofenig-sip-saml-00.txt.

This draft explicitly mentions that its main goal is not to realize single sign-on (SSO) functionality as in HTTP.
However, I wonder if it would not be a good idea to realize SSO functionality with SAML in SIP. Right now, 3GPP has defined IMS-AKA. This procedure authenticates the end-user when sending an initial SIP Register request to the P-CSCF. It must be noted that this is an MNO-centric approach; the MNO owning both a wireless access network and an IMS domain.

However, it is not unthinkable that in the future there will exist entities that will only operate an IMS domain. In this case, end-users will be authenticated by the (wireless) access network provider. Then, I believe it makes sense that the access network provider would provide SAML assertions to the IMS operator providing information on the authentication status of the end-user.

IMHO this is only one useful application of SAML to the SIP environment.

I was personally disappointed this document did not recieve more attention in SanDiego I hope it will be given a broader hearing in DC.

There are a variety of issues related to SIP security and Identity that SAML could solve.


How this should be done is unclear to me; I do have some initial ideas though.

Anybody willing to comment?

Thanks in advance!

Greetings,
Stefan.

Stefan Goeman
SIEMENS ICM/ICN
Stefan.Goeman@siemens.com
       
_______________________________________________
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


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141@fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--=====================_1513416==.ALT-- --===============0385867311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --===============0385867311==-- From sip-bounces@ietf.org Wed Sep 22 20:06:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28420 for ; Wed, 22 Sep 2004 20:06:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAHEo-0003O9-3a for sip-web-archive@ietf.org; Wed, 22 Sep 2004 20:13:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAH63-0000oe-GS; Wed, 22 Sep 2004 20:04:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAH3I-0000M8-WF for sip@megatron.ietf.org; Wed, 22 Sep 2004 20:01:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28147 for ; Wed, 22 Sep 2004 20:01:35 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAH9u-0003Ja-RI for sip@ietf.org; Wed, 22 Sep 2004 20:08:31 -0400 Received: from dfnjgl21 (c-24-1-99-5.client.comcast.net[24.1.99.5]) by comcast.net (rwcrmhc11) with SMTP id <2004092300010001300aekbfe> (Authid: sdawkins@comcast.net); Thu, 23 Sep 2004 00:01:00 +0000 Message-ID: <080c01c4a100$70bc3130$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: "Paul Kyzivat" , "Jonathan Rosenberg" References: <277CD60C-0369-11D9-8BB1-000D93326732@xten.com><41491F74.8090205@dynamicsoft.com> <414A2265.3070708@cisco.com> Subject: Re: [Sip] Re: GRUU and things that rewrite contacts Date: Wed, 22 Sep 2004 19:01:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Robert Sparks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Spencer Dawkins List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit From: "Paul Kyzivat" Sent: Thursday, September 16, 2004 6:31 PM Subject: Re: [Sip] Re: GRUU and things that rewrite contacts > > I don't think we can meaningfully comment on the impact on SBCs when > we have no definition of such a beast. And trying to generalize to > all forms of B2BUA makes things worse - we repeatedly state that > about all you can say in general about a B2BUA is that it is two > connected UAs - you can't say anything about how the two calls are > related. > > If this is an important problem for us to mention at all, (and I'm > not yet convinced it is), then I think the first step is to define > an SBC, along with the kinds of transformations it performs. Since > that has never been written down, when it is written it can deal > properly with GRUUs. > > Paul Yes, I agree completely. We can learn from the experience of waiting several years to figure out BCP for NATs, as we are now apparently doing in BEHAVE. Spencer _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 23 04:54:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23509 for ; Thu, 23 Sep 2004 04:54:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAPTw-00037L-F5 for sip-web-archive@ietf.org; Thu, 23 Sep 2004 05:01:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPJ1-000701-TI; Thu, 23 Sep 2004 04:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPEp-0006dp-Db for sip@megatron.ietf.org; Thu, 23 Sep 2004 04:46:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22886 for ; Thu, 23 Sep 2004 04:45:58 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAPLW-0002xd-2D for sip@ietf.org; Thu, 23 Sep 2004 04:52:59 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i8N8jv6e016455; Thu, 23 Sep 2004 10:45:57 +0200 Received: from hannes (mhpakcsc.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i8N8jsuF023792; Thu, 23 Sep 2004 10:45:56 +0200 Message-Id: <200409230845.i8N8jsuF023792@mail2.siemens.de> From: "Hannes Tschofenig" To: "'Richard Shockey'" , "'Goeman Stefan'" , Subject: RE: [Sip]: SIP and SAML Date: Thu, 23 Sep 2004 10:45:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.1.0.6.2.20040922102253.04e18210@joy.songbird.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSgtF0dkfkT0aSmRgO1xfl4M/PIwgABkzwQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit # hi richard, # ~snip~ IMHO this is only one useful application of SAML to the SIP environment. # i fully agree with your observation. # there is a difference between the usage of saml in http and sip due to the difference between these two protocols. # please take a look at my other mail as well. I was personally disappointed this document did not recieve more attention in SanDiego I hope it will be given a broader hearing in DC. # the sip working group is very busy with other working group items. i thankful that the chairs gave us a few minutes to introduce the document to the working group. There are a variety of issues related to SIP security and Identity that SAML could solve. # true. ~ snip ~ ciao hannes _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 23 05:01:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24024 for ; Thu, 23 Sep 2004 05:01:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAPaV-0003Dc-5R for sip-web-archive@ietf.org; Thu, 23 Sep 2004 05:08:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPJ4-00070m-0M; Thu, 23 Sep 2004 04:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPEp-0006dq-Dc for sip@megatron.ietf.org; Thu, 23 Sep 2004 04:46:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22887 for ; Thu, 23 Sep 2004 04:45:58 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAPLV-0002xc-W6 for sip@ietf.org; Thu, 23 Sep 2004 04:52:59 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i8N8jv6e016452 for ; Thu, 23 Sep 2004 10:45:57 +0200 Received: from hannes (mhpakcsc.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i8N8jsuE023792; Thu, 23 Sep 2004 10:45:56 +0200 Message-Id: <200409230845.i8N8jsuE023792@mail2.siemens.de> From: "Hannes Tschofenig" To: "'Goeman Stefan'" , Subject: RE: [Sip]: SIP and SAML Date: Thu, 23 Sep 2004 10:45:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F195692195@hrtades7.atea.be> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSgf+I6WETf8AtSTx6GUEZ59Pw+WwAUEMKg X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit hi stefan, thanks for pointing to this important issue. we are currently working on a draft update. we try to incorporate the issues presented in san diego (see http://www.softarmor.com/sipwg/meets/ietf60/slides/pres-ietf60-sip-saml-tsch ofenig.ppt). one of the open issues is related to reference integrity. we also had a discussion on this issue. since you raised this issue i will give some more insights in our off-line discussions. it is true that we mentioned in http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-00.txt that we do not aim to create a solution for single sign-on (sso). unfortunately, the term 'single sign-on' is somewhat loosely defined. there i have two answers for you: first answer: in section 4.5 of draft-ietf-sipping-trait-authz-00.txt (trait-based authz requirements draft) we describe a scenario where different protocols are linked together using saml assertions. we use an example where we associate a sip signaling protocol run and a qos signaling protocol. however, the scenario is more generic in the sense that an arbitrary protocol can be linked together with sip. if you call this "single sign-on" then this is certainly in scope of our work. the current sip-saml draft supports such a scenario. there are, however, some issues with reference integrity. this issue will be treated in more detail in second answer. second answer: there is a difference between the usage of saml in http and sip. section 5 talks about a problem where a sip proxy can reuse an obtained saml assertion to impersonate a user in future protocol runs. this problem has a direct relationship to your question. a few solutions exist to address this problem: 1) you can delete this problem by assuming that all sip proxies are trustworthy and do not act maliciously. 2) the current draft talks about binding the saml assertion to a particular sip session (see paragraphs mentioning the concept of reference integrity). binding a saml assertion to a sip session means that a) you compute a hash over a number of sip fields (see also draft-ietf-sip-identity and draft-ietf-sip-authid-body) b) include this hash into the saml assertion c) compute a digital signature this procedure has to be done by the authentication service. now, the main question is which fields to include in the hash. if you include information such as the call-id then the assertion is only valid for a particular sip session. if you only include the from,to field then the assertion is valid for sip sessions between the two indicated entities (typically for given timeframe - as specified in the validity of the saml assertion). depending what you call single sign-on there might indeed be a problem. there is no reason to be disappointed. during a discussion with bob morgan (one of the saml authors) at the last ietf he pointed me to the holder-of-the-key assertion to deal with reference integrity in a better way. the idea is the following: instead of using reference integrity with an enhancement to the conditions extension point the holder-of-the-key assertion allows to bind a key to the assertion. as a result, the end host which was quite passive with the previous approach can be turned into an active participant. obviously this considerably improves security (with the drawback of adding some complexity to it). although we discussed this issue among the authors we haven't reached a conclusion on it. the usage of saml in sip might heavily be scenario dependend. this means that one solution might not fit in all cases. hence, i personally see only the following options: - we do not strictly mandate which fields the authentication service has to include into the hash function in order to gurantee reference integrity. - we additionally allow the usage of the holder-of-the-key assertion ciao hannes > -----Original Message----- > From: Goeman Stefan [mailto:Stefan.Goeman@siemens.com] > Sent: Mittwoch, 22. September 2004 10:31 > To: 'sip@ietf.org' > Subject: [Sip]: SIP and SAML > > Hello, > > I was wondering if somebody already reviewed the ID > draft-tschofenig-sip-saml-00.txt. > > This draft explicitly mentions that its main goal is not to > realize single sign-on (SSO) functionality as in HTTP. > However, I wonder if it would not be a good idea to realize > SSO functionality with SAML in SIP. Right now, 3GPP has > defined IMS-AKA. > This procedure authenticates the end-user when sending an > initial SIP Register request to the P-CSCF. It must be noted > that this is an MNO-centric approach; the MNO owning both a > wireless access network and an IMS domain. > > However, it is not unthinkable that in the future there will > exist entities that will only operate an IMS domain. In this > case, end-users will be authenticated by the (wireless) > access network provider. Then, I believe it makes sense that > the access network provider would provide SAML assertions to > the IMS operator providing information on the authentication > status of the end-user. > > How this should be done is unclear to me; I do have some > initial ideas though. > > Anybody willing to comment? > > Thanks in advance! > > Greetings, > Stefan. > > > Stefan Goeman > SIEMENS ICM/ICN > Stefan.Goeman@siemens.com > > > _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 23 11:00:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20397 for ; Thu, 23 Sep 2004 11:00:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVCG-0001Mg-O8 for sip-web-archive@ietf.org; Thu, 23 Sep 2004 11:07:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUsN-0000yy-2y; Thu, 23 Sep 2004 10:47:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUnq-0007gR-Eo for sip@megatron.ietf.org; Thu, 23 Sep 2004 10:42:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18356 for ; Thu, 23 Sep 2004 10:42:32 -0400 (EDT) Received: from m5tmail.m5t.com ([66.129.134.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAUue-0000kC-Bc for sip@ietf.org; Thu, 23 Sep 2004 10:49:36 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Sep 2004 10:42:03 -0400 Message-ID: Thread-Topic: RFC3515 Refer-To ABNF Thread-Index: AcShe32AqQt8gsDsSZ2rxCiHaoanyw== From: "Joel Payeur" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: rsparks@dynamicsoft.com Subject: [Sip] RFC3515 Refer-To ABNF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Hi, Refer-To's ABNF: Refer-To =3D ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) as well as being incompatible with previous Refer-To draft ABNF (it adds = optional parameters at the header level), does not seem to be consistent = on its own. If I have the header: Refer-To: sip:user@host;param=3Dvalue This is RFC3515 ABNF compliant. However, is "param" part of the header, = or part of the URI? If i use the addr-spec form, i guess the param = should be part of the URI then. Or is it? The problem comes from allowing name-addr/addr-spec. This was also = present for other headers in RFC3261, these are From,To, Contact and = Reply-To, however for each of these a comment was inserted to clarify = that the name-addr form (angle quotes) MUST be used if parameters or = headers are present in the URI: RFC3261 Sect 20: The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. Sect 20.31 Reply-To Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. My question is: If RFC3261 mandates that the name-addr form be used if = the URI has parameters/headers, why would it not be the same for = Refer-To? It is safe to assume that extension headers should also = conform to this? Should we add the section 20.31 comment Refer-To's = definition? The examples section in 3515 goes this way...=20 I'm also wondering why the ABNF allows name-addr/addr-spec, when it = could be simpler by allowing only name-addr, as is the case for Route = and Record-route? Is this legacy for Pre-Rfc3515 compatibility? Thanks, Joel@m5t _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 23 11:18:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21974 for ; Thu, 23 Sep 2004 11:18:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVTR-0001mg-9D for sip-web-archive@ietf.org; Thu, 23 Sep 2004 11:25:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAV9k-0004M2-9F; Thu, 23 Sep 2004 11:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAV5s-0003Rz-OG for sip@megatron.ietf.org; Thu, 23 Sep 2004 11:01:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20450 for ; Thu, 23 Sep 2004 11:01:10 -0400 (EDT) Received: from [64.69.76.5] (helo=mail.xten.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVCF-0001Lg-4v for sip@ietf.org; Thu, 23 Sep 2004 11:08:14 -0400 Received: from [24.1.66.77] by mail.xten.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Thu, 23 Sep 2004 08:01:40 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <29104F89-0D71-11D9-90F7-000D93326732@xten.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 23 Sep 2004 09:59:25 -0500 To: "Joel Payeur" X-Mailer: Apple Mail (2.619) X-ArGoMail-Authenticated: robert@xten.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: RFC3515 Refer-To ABNF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit The use is the same in Refer-To as it was for From/To/Contact. Any instance of name-addr | addr-spec in SIP headers will follow this same rule. (and we are being more careful as we go forward to be explicit in each document) If you have a URI parameter you must place it inside angle brackets. Any semicolon delimited parameters appearing outside brackets are header parameters, not URI parameters. RjS On Sep 23, 2004, at 9:42 AM, Joel Payeur wrote: > Hi, > > Refer-To's ABNF: > > Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * > (SEMI generic-param) > > as well as being incompatible with previous Refer-To draft ABNF (it > adds optional parameters at the header level), does not seem to be > consistent on its own. > > If I have the header: > > Refer-To: sip:user@host;param=value > > This is RFC3515 ABNF compliant. However, is "param" part of the > header, or part of the URI? If i use the addr-spec form, i guess the > param should be part of the URI then. Or is it? > > The problem comes from allowing name-addr/addr-spec. This was also > present for other headers in RFC3261, these are From,To, Contact and > Reply-To, however for each of these a comment was inserted to clarify > that the name-addr form (angle quotes) MUST be used if parameters or > headers are present in the URI: > > RFC3261 Sect 20: > > The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in > angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters. > > Sect 20.31 Reply-To > Even if the "display-name" is empty, the "name-addr" form MUST be > used if the "addr-spec" contains a comma, question mark, or > semicolon. Syntax issues are discussed in Section 7.3.1. > > > My question is: If RFC3261 mandates that the name-addr form be used if > the URI has parameters/headers, why would it not be the same for > Refer-To? It is safe to assume that extension headers should also > conform to this? Should we add the section 20.31 comment Refer-To's > definition? The examples section in 3515 goes this way... > > I'm also wondering why the ABNF allows name-addr/addr-spec, when it > could be simpler by allowing only name-addr, as is the case for Route > and Record-route? Is this legacy for Pre-Rfc3515 compatibility? > > Thanks, > > Joel@m5t _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 23 11:21:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22295 for ; Thu, 23 Sep 2004 11:21:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVVv-0001rf-M6 for sip-web-archive@ietf.org; Thu, 23 Sep 2004 11:28:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAV9x-0004Vi-9v; Thu, 23 Sep 2004 11:05:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAV9B-00049N-1K for sip@megatron.ietf.org; Thu, 23 Sep 2004 11:04:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20775 for ; Thu, 23 Sep 2004 11:04:34 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVFo-0001Sz-SL for sip@ietf.org; Thu, 23 Sep 2004 11:11:39 -0400 Received: from [127.0.0.1] (kevlar.softarmor.com [127.0.0.1]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i8NF3Y8u021630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Sep 2004 10:03:40 -0500 Message-ID: <4152E5C6.4020905@softarmor.com> Date: Thu, 23 Sep 2004 10:03:34 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-2022-JP?B?GyRCQFBAbiEhMCYbKEI=?= Subject: Re: [sip]Join header syntax related to RFC2543 References: <20040902001944.8D2B93D0FB@ms2.alpha.co.jp> In-Reply-To: <20040902001944.8D2B93D0FB@ms2.alpha.co.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, rohan@ekabal.com, dpetrie@pingtel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit $B@P@n!!0&(B wrote: > Hi, > > I have a question associated with draft-ietf-sip-join-03.txt > and draft-ietf-sip-replaces-05.txt. > > > Join document at the tail of Section 7.1 saids: > > For compatibility with dialogs initiated by RFC2543 [11] > compliant UAs, a tag of zero matches both tags of zero and null tags > > Examples: > Join: 87134@192.0.2.23;to-tag=24796;from-tag=0$B!!(B > > and also said at section 6.1 in Replaces document. > > > > In inverse case, i.e., there is a dialog initiated by RFC3261 > compliant UAs to RFC2543 compliant UAs, is the same? > In other words, there is a possibility that there is > no to-tag in this case. So we can as below? > > For example, > Join: 12345@192.1.2.3;to-tag=0;from-tag=56789 > > > In this example, does tag of zero matches both tags of zero > and null tags? And also for Replaces? That's my reading of the doc, although in retrospect the wording at the end of joing-7.1 is particularly clumsy, and I wish somebody had noticed sooner. I'd like to ask the authors to clarify here, and perhaps we can get an errata entry with that clarification. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Fri Sep 24 06:54:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29066 for ; Fri, 24 Sep 2004 06:54:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAnpz-0007Mr-7A for sip-web-archive@ietf.org; Fri, 24 Sep 2004 07:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAnh2-0007yq-Nu; Fri, 24 Sep 2004 06:52:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAndj-0007E1-LM for sip@megatron.ietf.org; Fri, 24 Sep 2004 06:49:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28799 for ; Fri, 24 Sep 2004 06:49:20 -0400 (EDT) Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAnkc-0007G8-AK for sip@ietf.org; Fri, 24 Sep 2004 06:56:35 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i8OAiqhi000381 for ; Fri, 24 Sep 2004 18:44:53 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Sep 24 18:47:42 2004 +0800 Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Sep 2004 18:47:42 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Fri, 24 Sep 2004 18:47:42 +0800 Message-ID: Thread-Topic: Sip Digest, Vol 5, Issue 17 Thread-Index: AcSgw0+kN9XTo64/QfmowwULPpctHwBXTmXA From: "FCG Huang Qiang \(B300\)" To: X-OriginalArrivalTime: 24 Sep 2004 10:47:42.0218 (UTC) FILETIME=[EAED1EA0:01C4A223] X-Spam-Score: 1.9 (+) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Content-Transfer-Encoding: quoted-printable Subject: [Sip] SIP GW Register X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: d67762704726a1bed57e7f4595960d34 Content-Transfer-Encoding: quoted-printable Question 1: Accordint to RFC 3261 10.2.2: Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values. So if we use contact * and expire time zero can remove all contact = bindings for the user, is it or not? Question 2: For the registrar discovery mechanism in the RFC 3261 charpter 10.2.6: we cand send register message with Request-URI "sip.mcast.net" to find = registrar, and how the registrar reply with it? how we can get the = registrar information, sucha as domain,ip address and port from the = registrar response ? Question 3: Not like In H323 GK register mechanism the field termination type can be = used to distinguish the GW or termiantion. In SIP GW can the telephone = number prefix be used in the from and to field to send to registrar for = telephone number routing? if ok, maybe are there several user to = register with registrar for one GW. if not How SIP GW can register with = registrar? -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org]=B4=FA=B1=ED sip-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA9=D4=C223=C8=D5 0:45 =CA=D5=BC=FE=C8=CB: sip@ietf.org =D6=F7=CC=E2: Sip Digest, Vol 5, Issue 17 Send Sip mailing list submissions to sip@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/sip or, via email, send a message with subject or body 'help' to sip-request@ietf.org You can reach the person managing the list at sip-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip digest..." Today's Topics: 1. RE: call stateful ? (Thomas Gal) 2. RE: Need guidance in call transfer - SIP Based (Umesh Sharma) 3. [Sip]: SIP and SAML (Goeman Stefan) 4. Performance testing tools for SIP entities (brijesh nair) 5. RE: Performance testing tools for SIP entities (Thomas Johansson G (HF/EAB)) 6. Re: Performance testing tools for SIP entities (Bj?rn Gr?nesj?) 7. Voice Mail (Anurag Kabra) 8. SIP and MIP addressing (Thibault Renier) 9. Re: [Sip]: SIP and SAML (Richard Shockey) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Sep 2004 17:47:06 -0700 From: "Thomas Gal" Subject: RE: [Sip] call stateful ? To: "'vikram'" , "'sip-ietf'" Message-ID: Content-Type: text/plain; charset=3D"us-ascii" That means a proxy tracks the transaction ID not the session ID. For = example once the invite has completed a proxy may know nothing about the call = that it connected while for a brief period of time it was "aware" (read maintaining state) that it was in the middle of an invite command. -Tom=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of vikram > Sent: Thursday, September 16, 2004 6:26 AM > To: sip-ietf > Subject: [Sip] call stateful ? >=20 > hello all, > Could anybody pls explain following from rfc 3261 >=20 > " *A call stateful proxy is always transaction stateful,=20 > but the converse is not necessarily true"* >=20 >=20 > regards >=20 > Vikram >=20 > _______________________________________________ > 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 >=20 ------------------------------ Message: 2 Date: Wed, 22 Sep 2004 09:53:46 +0530 From: "Umesh Sharma" Subject: RE: [Sip] Need guidance in call transfer - SIP Based To: , "sip" Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" pls see inline. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Anurag Kabra (by way of Anurag Kabra) (by way of Anurag Kabra ) Sent: Monday, September 20, 2004 1:24 PM To: sip@ietf.org Subject: [Sip] Need guidance in call transfer - SIP Based I am currently working on VoIP, and I am located in India. I have few queries which are bothering me, could you suggest me = something on them. Below are my queries. 1. Do we do retransmission for Refer Request(& Notify) if it doesnot = reach transferee. >> timeout/retransmission mechanism for refer is same as for bye, = non-invite transactions; when notify times out it is not retransmitted & correp. subscription should be removed. 2. In a unattended call transfer, when does the dialog end i.e. normally with a BYE or Notify(subscriptio-state=3D"terminated"). 3. Does the dialog exists even after BYE or subscription-state header in Notify will terminate the dialog. 2, 3>> my understanding from rfc 3265 bye would not terminate the dialog = if there is subscription on it, subscriber-state=3D"terminated" destroys = the subscription and the dialog if no other application state is associated = with the dialog (more in 3.3.4 rfc 3265). For Call transfer refer goes with = in existing dialog. 4. Is 202 Accepted sent after getting a REFER request, ignored by the transferor. What is the effect of the response 202 Accepted? >> it indicates that the subscription has been accepted and that authorization to proceed with transfer may or may not have been granted. Also, that a notify will be sent immediately (3.1.4.1). It also creates = a new dialog & subscription if the initial refer was not sent on a pre-existing dialog otherwise it just creates the new subscription with = the dialog. This is all for now. Hope to hear from you soon. Thanks in advance. Best Regards Anurag. _______________________________________________ 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 ------------------------------ Message: 3 Date: Wed, 22 Sep 2004 10:30:55 +0200 From: Goeman Stefan Subject: [Sip]: SIP and SAML=20 To: "'sip@ietf.org'" Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692195@hrtades7.atea.be> Content-Type: text/plain; charset=3D"us-ascii" Hello, I was wondering if somebody already reviewed the ID draft-tschofenig-sip-saml-00.txt. This draft explicitly mentions that its main goal is not to realize = single sign-on (SSO) functionality as in HTTP.=20 However, I wonder if it would not be a good idea to realize SSO functionality with SAML in SIP. Right now, 3GPP has defined IMS-AKA. = This procedure authenticates the end-user when sending an initial SIP = Register request to the P-CSCF. It must be noted that this is an MNO-centric approach; the MNO owning both a wireless access network and an IMS = domain.=20 However, it is not unthinkable that in the future there will exist = entities that will only operate an IMS domain. In this case, end-users will be authenticated by the (wireless) access network provider. Then, I believe = it makes sense that the access network provider would provide SAML = assertions to the IMS operator providing information on the authentication status = of the end-user.=20 How this should be done is unclear to me; I do have some initial ideas though. Anybody willing to comment? Thanks in advance! Greetings, Stefan. Stefan Goeman=20 SIEMENS ICM/ICN=20 Stefan.Goeman@siemens.com =20 =09 -------------- next part -------------- An HTML attachment was scrubbed... URL: = http://www1.ietf.org/pipermail/sip/attachments/20040922/c26a946e/attachme= nt.htm ------------------------------ Message: 4 Date: Wed, 22 Sep 2004 02:21:31 -0700 (PDT) From: brijesh nair Subject: [Sip] Performance testing tools for SIP entities To: sip@ietf.org Message-ID: <20040922092131.31780.qmail@web14224.mail.yahoo.com> Content-Type: text/plain; charset=3Dus-ascii Hi, I am looking for good performace testing tools (free or otherwise) which can be used to test various SIP entities (e.g B2BUA, Proxy Servers etc.). Can anyone help on this?? Thanks, Brijesh =09 _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ------------------------------ Message: 5 Date: Wed, 22 Sep 2004 11:30:47 +0200 From: "Thomas Johansson G (HF/EAB)" Subject: RE: [Sip] Performance testing tools for SIP entities To: "'brijesh nair'" , sip@ietf.org Message-ID: <633A2BAC69E8D411819A00508BCF883C0DA5F66D@esealnt452.al.sw.ericsson.se> =09 Content-Type: text/plain; charset=3D"iso-8859-1" Sipp from HP might fulfil your needs (freeware): http://sourceforge.net/projects/sipp Sipp is a performance testing tool for the SIP protocol. Its main = features are basic SIPStone scenarios, TCP/UDP transport, customizable = (xml based) scenarios, dynamic adjustement of call-rate and a = comprehensive set of real-time statistics. BRs /Thomas -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of brijesh nair Sent: den 22 september 2004 11:22 To: sip@ietf.org Subject: [Sip] Performance testing tools for SIP entities Hi, I am looking for good performace testing tools (free or otherwise) which can be used to test various SIP entities (e.g B2BUA, Proxy Servers etc.). Can anyone help on this?? Thanks, Brijesh =09 _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ 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 ------------------------------ Message: 6 Date: Wed, 22 Sep 2004 11:32:07 +0200 (CEST) From: Bj?rn Gr?nesj? Subject: Re: [Sip] Performance testing tools for SIP entities To: brijesh nair Cc: sip@ietf.org Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Try: SIPp - sipp.sourceforge.net //Bj=F6rn On Wed, 22 Sep 2004, brijesh nair wrote: > Hi, > I am looking for good performace testing tools (free > or otherwise) which can be used to test various SIP > entities (e.g B2BUA, Proxy Servers etc.). Can anyone > help on this?? > > Thanks, > Brijesh > > > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com > > _______________________________________________ > 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 > ------------------------------ Message: 7 Date: Wed, 22 Sep 2004 18:10:31 +0530 From: Anurag Kabra Subject: [Sip] Voice Mail To: sip@ietf.org Message-ID: <200409221810.31676.anuragk@aftek.com> Content-Type: text/plain; charset=3D"us-ascii" Hello Everyone I need some links detailing Voice Mail Client implementation based on = SIP. =20 Thank You in advance. Best Regards Anurag. ------------------------------ Message: 8 Date: Wed, 22 Sep 2004 16:13:48 +0200 From: "Thibault Renier" Subject: [Sip] SIP and MIP addressing To: Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Hi all, I am currently working on integrating SIP in architecture using Mobile = IP for mobility support. My question concerns the addressing scheme: At the SIP layer a SIP URI specifies the destination point ("To" field), going from SIP hop to SIP hop. At the IP layer, the destination address = is usually the same as the current IP address (Care of Address in the MIP jargon -CoA) that corresponds to the URI used in the "To" (I guess that = the association URI/current IP address of a user is made possible during the registration procedure). When MIP is used at the IP layer, for communications from the Correspondent Node (CN) to the Mobile Node (MN), = the destination address is the MN's home address and the packets should be intercepted by the Home Agent (HA). 1. What is the route in a system combining MIP for mobility support and = SIP for signalling flow? Do the packets go through all the SIP servers/hops before applying the MIP routing solutions?=20 2. What does happen because of the 'conflict' of addresses? (SIP = resolves the URI with the CoA, while IP uses the MN's home address at first) Thanks for your help /Tibo -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2004 bytes Desc: not available Url : = http://www1.ietf.org/pipermail/sip/attachments/20040922/87c2eb8d/winmail.= bin ------------------------------ Message: 9 Date: Wed, 22 Sep 2004 10:24:46 -0400 From: Richard Shockey Subject: Re: [Sip]: SIP and SAML=20 To: Goeman Stefan , "'sip@ietf.org'" Message-ID: <6.1.0.6.2.20040922102253.04e18210@joy.songbird.com> Content-Type: text/plain; charset=3D"us-ascii" At 04:30 AM 9/22/2004, Goeman Stefan wrote: >Hello, > >I was wondering if somebody already reviewed the ID=20 >draft-tschofenig-sip-saml-00.txt. > >This draft explicitly mentions that its main goal is not to realize = single=20 >sign-on (SSO) functionality as in HTTP. >However, I wonder if it would not be a good idea to realize SSO=20 >functionality with SAML in SIP. Right now, 3GPP has defined IMS-AKA. = This=20 >procedure authenticates the end-user when sending an initial SIP = Register=20 >request to the P-CSCF. It must be noted that this is an MNO-centric=20 >approach; the MNO owning both a wireless access network and an IMS = domain. > >However, it is not unthinkable that in the future there will exist=20 >entities that will only operate an IMS domain. In this case, end-users=20 >will be authenticated by the (wireless) access network provider. Then, = I=20 >believe it makes sense that the access network provider would provide = SAML=20 >assertions to the IMS operator providing information on the = authentication=20 >status of the end-user. IMHO this is only one useful application of SAML to the SIP environment. I was personally disappointed this document did not recieve more = attention=20 in SanDiego I hope it will be given a broader hearing in DC. There are a variety of issues related to SIP security and Identity that=20 SAML could solve. >How this should be done is unclear to me; I do have some initial ideas=20 >though. > >Anybody willing to comment? > >Thanks in advance! > >Greetings, >Stefan. > >Stefan Goeman >SIEMENS ICM/ICN >Stefan.Goeman@siemens.com > >_______________________________________________ >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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 = 815.333.1237 or = ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -------------- next part -------------- An HTML attachment was scrubbed... URL: = http://www1.ietf.org/pipermail/sip/attachments/20040922/cb454d7a/attachme= nt.htm ------------------------------ _______________________________________________ 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 End of Sip Digest, Vol 5, Issue 17 ********************************** _______________________________________________ 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 From sip-bounces@ietf.org Fri Sep 24 07:54:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03334 for ; Fri, 24 Sep 2004 07:54:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAom8-00007L-KE for sip-web-archive@ietf.org; Fri, 24 Sep 2004 08:02:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAoWq-0007fe-U1; Fri, 24 Sep 2004 07:46:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAoTr-00079o-7W for sip@megatron.ietf.org; Fri, 24 Sep 2004 07:43:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02574 for ; Fri, 24 Sep 2004 07:43:14 -0400 (EDT) Received: from [203.129.224.106] (helo=kr.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAoao-0008Fu-Kg for sip@ietf.org; Fri, 24 Sep 2004 07:50:28 -0400 Received: from [10.0.0.145] ([10.0.0.145]) by kr.aftek.com (8.11.6/8.11.6) with ESMTP id i8OBh4L22912 for ; Fri, 24 Sep 2004 17:13:05 +0530 Message-ID: <41540A09.4030509@aftek.com> Date: Fri, 24 Sep 2004 17:20:33 +0530 From: Vikram Bhuskute User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip-ietf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Sip] STUN server Misleads ! X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Helo all, I am using an open stun client. It helped me a lot . But there is problem. one out of five times my stun gives me wrong type of NAT !! When i traced the packets .. .i found it is not my client's faul server itself is responisble for that. e.g. I was behind port restricted NAT and still i got different binding for Test 1.2 (request to other IP of STUN server) and my client concluded from protocol that it is Symmetric NAT. I tried 5-6 STUN server i could found. but same problem Is it a known issue ? Is any STUN server is bug free ? regards vikram _______________________________________________ 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 From sip-bounces@ietf.org Fri Sep 24 08:20:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05509 for ; Fri, 24 Sep 2004 08:20:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CApBC-0000c1-Ss for sip-web-archive@ietf.org; Fri, 24 Sep 2004 08:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAp0d-0004Ts-1T; Fri, 24 Sep 2004 08:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAox7-0003tv-Sp for sip@megatron.ietf.org; Fri, 24 Sep 2004 08:13:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05015 for ; Fri, 24 Sep 2004 08:13:28 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAp45-0000Ub-7E for sip@ietf.org; Fri, 24 Sep 2004 08:20:43 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Sep 2004 13:12:58 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E52FE9@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Roman Shpount'" Subject: RE: RE: RE: [Sip] Problem with an intial SIP INVITE server transa ction. Date: Fri, 24 Sep 2004 13:12:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Roman, I believe you have strayed into a poorly specified area of SIP here. I have also found nothing in the specs. that directly answers your question however I can tell you what is observed: the duplication INVITEs are simply ignored. One option is to keep track of the INVITE transaction until the ACK arrives. Although logically there is no transaction layer interaction (as per section 17, RFC 3261), you can then identify the INVITE as a duplicate and discard it. Paul D Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Roman Shpount [mailto:roman@atelo.com] Sent: 19 September 2004 08:15 To: SIP Public Folder (E-mail) Subject: Re: RE: RE: [Sip] Problem with an intial SIP INVITE server transaction. Thomas, The problem is that retransmitted INVITE message does not have the To-tag. Thus it does not match the dialog and UAC is not even informed about this message. The only way I could think to deal with this, as I described in my original email, was to add a timer which keeps the server INVITE transaction open for T4 after 2XX response is sent. If retransmitted INVITE message arrives within this time, it matches the transaction and is ignored. By the way, this discussion is not academic, this is the real problem that we encountered while dealing with large volumes of SIP transactions over Wi-Fi. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. -- www.atelo.com ------ Original message ------ >From: Thomas Gal >Subject: RE: RE: [Sip] Problem with an intial SIP INVITE server transaction. >Date: 31 Aug 04, 04:44 PM >To: 'Roman Shpount' , , Maybe some people were just trying to help without scouring the spec for all the details. I have read the spec quite a few times, thanks, but here, maybe this will help(17): In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction. The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction. You gotta wait til you get the ACK. -Tom -----Original Message----- From: Roman Shpount [mailto:roman@atelo.com] Sent: Tuesday, August 31, 2004 8:38 AM To: gledgard@iperia.com; ThomasGal@LumenVox.com; sip@ietf.org Subject: Re: RE: [Sip] Problem with an intial SIP INVITE server transaction. Hi All, I got quite a few answers like: "there is a magic key which prevents this" or "there is a timer that prevents this", or "you cannot get an INVITE once you sent the 1XX or 2XX response". I would suggest that you would read the RFC (Section 17.2.1) before rushing to answer my question. RFC clearly spells out that INVITE server transaction is terminated when 2XX response is sent. There is even a picture (Figure 7) that shows just that. There are no timers. There are no special transaction IDs. Transaction is ended, clear and simple. Once transaction is ended, re-transmitted INVITE message should start the new transaction. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. -- www.atelo.com ------ Original message ------ >From: Gordon Ledgard >Subject: RE: [Sip] Problem with an intial SIP INVITE server transaction. >Date: 31 Aug 04, 12:40 PM >To: , Roman Shpount , > Read the stuff about timers in the transaction layer. It spells out how you need to hold on to transactions for messages over unreliable transports for just this sort of reason. Gordon -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Thomas Gal Sent: Monday, August 30, 2004 7:54 PM To: 'Roman Shpount'; sip@ietf.org Subject: RE: [Sip] Problem with an intial SIP INVITE server transaction. I'm not an expert on this protocol (only read through the spec a few times so it blurs together with some of the other ones) but even without looking I'm SURE there's supposed to be a unique request-ID generated by the client to avoid just such a confusion. Of course in this case any stateful UA would ignore the already processed invite request. Also (sure about this one) if the client received the provisional(100) response it wouldn't re-transmit the INVITE either as that's the whole point. -Tom -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Roman Shpount Sent: Tuesday, August 17, 2004 7:05 PM To: sip@ietf.org Subject: [Sip] Problem with an intial SIP INVITE server transaction. I run into the problem with handling of retransmitted SIP INVITE message based on the RFC 3621. Imagine the following situation INVITE 1 -----------------------> 100 <----------------------- 2XX <----------------------- re-transmitted INVITE 1 -----------------------> Based on RFC 3261, server INVITE transaction terminates as soon as 2XX response is sent. This means that re-transmitted INVITE will be treated as a new transaction. This INVITE message will not match the existing dialog, since its To tag is empty. This means it will be treated as new dialog creating message and phone will treat this message as a new call, which is clearly not intended. This situation can occur if both 100 and 2XX responses were lost by the unreliable transport, and INVITE continues to be re-transmitted. The fact that, 100 and 2XX responses were lost is unknown to the server transaction and INVITE re-transmit can arrive before the 2XX re-transmit is sent. Majority of the transaction state machines in SIP are designed to handle messages, that are received after the response is sent. It seems that something simular is required in this case as well. In our implementation of SIP stack, server transaction is not terminated when the 2XX response is sent. Instead, transaction is moved into the "ConfirmedBis" state and timer, which is set to fire in T4, is started. If the stack receives an INVITE message which matches the server transaction in this state, it ignores it. If stack receives a 2XX response, which matches the server transaction, it passes it to TU. Once the T4 timer is fired, the transaction is terminated. There is also an additional issue related to this problem. It looks like, for the sake of consistency, some type of response should be sent immediately to the transport layer when INVITE re-transmit is received. If multiple 2XX responses has been sent, it is unclear what the behavior should be: should all the 2XX messages be sent, should the last 2XX message be resent or should the INVITE be plainly ignored. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. -- www.atelo.com _______________________________________________ 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://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://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://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 From sip-bounces@ietf.org Sat Sep 25 16:01:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14527 for ; Sat, 25 Sep 2004 16:01:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBIqg-0000RH-Mj for sip-web-archive@ietf.org; Sat, 25 Sep 2004 16:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBIac-0005rp-R0; Sat, 25 Sep 2004 15:52:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9f7r-0001hn-Tj for sip@megatron.ietf.org; Tue, 21 Sep 2004 03:31:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18886 for ; Tue, 21 Sep 2004 03:31:46 -0400 (EDT) Received: from web51103.mail.yahoo.com ([206.190.38.145]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9fE7-0004nu-Dy for sip@ietf.org; Tue, 21 Sep 2004 03:38:20 -0400 Message-ID: <20040921073112.55612.qmail@web51103.mail.yahoo.com> Received: from [217.45.197.113] by web51103.mail.yahoo.com via HTTP; Tue, 21 Sep 2004 00:31:12 PDT Date: Tue, 21 Sep 2004 00:31:12 -0700 (PDT) From: Rayees Khan Subject: Re: [Sip] Contact: headers in SIP REGISTER 200 OK responses To: "Gerke, Tom" , sip@ietf.org In-Reply-To: <3DEC199BD7489643817ECA151F7C59290B992B@pysmsx401.amr.corp.intel.com> MIME-Version: 1.0 X-Spam-Score: 1.5 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-Mailman-Approved-At: Sat, 25 Sep 2004 15:52:12 -0400 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rakhan@hssworld.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1074374439==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 --===============1074374439== Content-Type: multipart/alternative; boundary="0-1001205529-1095751872=:54845" --0-1001205529-1095751872=:54845 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA18886 Content-Transfer-Encoding: quoted-printable =20 I think that the REGISTER messages from both the UAs would be taken by re= gistrar to be from same UA. As a result the second REGISTER would be take= n as re-REGISTER. Now the validity of the contacts in the two would depen= d on the expires parameter in the contact header.=20 These contacts can be overlapping too.=20 In any case the response to the REGISTER message would be sent to the Via= address mentioned in the REGISTER rathar than the address specified in c= ontact. =20 =20 regards Rayees =20 "Gerke, Tom" wrote: Hello, =20 If two different UAs (in the same domain) happen to register a user using= the same AOR (but different Contact addresses), to the same Registrar, w= hat would be in their respective REGISTER 200 OK responses from that Regi= strar? i.e. Would they be notified of each others=92 bindings? =20 Section 10.3, step 8, of the SIP spec states that the 200 OK response wil= l contain =93all current bindings=94. It doesn=92t mention anything abou= t the Call-IDs for those bindings having to match up or anything. =20 So, let=92s say: First, UA 1 decides to register AOR sip:userA@example.com with the Contac= t address sip:usr1212@102.103.104.105 to a Registrar. Then sometime later UA 2 decides to register AOR sip:userA@example.com wi= th the Contact address sip:m1300@102.103.104.105:5070 to that same Regist= rar. =20 Assuming both of these UAs used unique Call-IDs, and there were no author= ization issues, what Contact: headers would be in the REGISTER 200 OK res= ponse message from this Registrar: 1) When UA 2 received its initial REGISTER response? 2) Sometime later when UA 1 then refreshes its binding for AOR sip:userA@= example.com? =20 Thanks in advance for any clarification on this matter, -Tom =20 _______________________________________________ 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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 --0-1001205529-1095751872=:54845 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA18886 Content-Transfer-Encoding: quoted-printable

 
I think that the REGISTER messages from both the UAs would be taken = by registrar to be from same UA. As a result the second REGISTER would be= taken as re-REGISTER. Now the validity of the contacts in the two would = depend on the expires parameter in the contact header.
These contacts can be overlapping too.
In any case the response to the REGISTER message would be sent to th= e Via address mentioned in the REGISTER rathar than the address specified= in contact.
 
 
regards
Rayees
 


"Gerke, Tom" <tom.gerke@intel.com> wrote= :

Hello,

 

If two different UAs (in the same domain) hap= pen to register a user using the same AOR (but different Contact addresse= s), to the same Registrar, what would be in their respective REGISTER 200= OK responses from that Registrar?   i.e. Would they be notifie= d of each others=92 bindings? 

Section 10.3, step 8, of the SIP spec states = that the 200 OK response will contain =93all current bindings=94.  I= t doesn=92t mention anything about the Call-IDs for those bindings having= to match up or anything.

 

So, let=92s say:

First, UA 1 decides to register AOR sip:userA@example.com with the Contact ad= dress sip:usr1212@102.103.104.105 to a Registrar.

Then sometime later UA 2 decides to register = AOR sip:userA@example.com with t= he Contact address sip:m1300@102.103.104.105:5070 to that same Registrar.=

 

Assuming both of these UAs used unique Call-I= Ds, and there were no authorization issues, what Contact: headers would b= e in the REGISTER 200 OK response message from this Registrar:=

1) When UA 2 received its initial REGISTER re= sponse?

2) Sometime later when UA 1 then refreshes it= s binding for AOR sip:userA@example.= com?

 

Thanks in advance for any clarification on th= is matter,

-Tom

 

____= ___________________________________________
Sip mailing list https://w= ww1.ietf.org/mailman/listinfo/sip
This list is for NEW development of = the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questio= ns on current sip
Use sipping@ietf.org for new developments on the app= lication of sip

____________________________________= ______________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the b= est spam protection around
http://mail.yahoo.com=20 --0-1001205529-1095751872=:54845-- --===============1074374439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --===============1074374439==-- From sip-bounces@ietf.org Sat Sep 25 16:01:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14561 for ; Sat, 25 Sep 2004 16:01:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBIrI-0000SJ-Dw for sip-web-archive@ietf.org; Sat, 25 Sep 2004 16:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBIae-0005sQ-8G; Sat, 25 Sep 2004 15:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9jrD-0000SH-5b for sip@megatron.ietf.org; Tue, 21 Sep 2004 08:34:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09252 for ; Tue, 21 Sep 2004 08:34:53 -0400 (EDT) Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9jxZ-0001sY-KR for sip@ietf.org; Tue, 21 Sep 2004 08:41:30 -0400 Received: from snom.de (pD9E0D008.dip.t-dialin.net [217.224.208.8]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i8LCYeoF027001; Tue, 21 Sep 2004 14:34:40 +0200 (MEST) Content-class: urn:content-classes:message Subject: RE: [Sip] Symmetric NAT issue MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Sep 2004 14:34:39 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Sip] Symmetric NAT issue thread-index: AcSfqtkdn81HOIEnTkafdblJw+fKdQAK/o5g From: "Christian Stredicke" To: "Jonathan Rosenberg" , "vikram" X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 25 Sep 2004 15:52:12 -0400 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable IMVHO SBC that use ICE are a smart alternative to using TURN. UA that are not aware of ICE, STUN, TURN or NAT will run media through the B2BUA while ICE-aware devices can bypass them. IMEHO ist much easier to implement STUN/ICE than TURN (well, we did/tried it) and it solves the problem with the "dumb" devices. Paired with DNS SRV and STUN its possible to automatically detect the nearest SBC, in case the SBC is necessary to relay media for symmetrical NAT. CS -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, September 21, 2004 9:16 AM To: vikram Cc: sip@ietf.org Subject: Re: [Sip] Symmetric NAT issue There are some TURN implementations. There are security and interop benefits of TURN over the b2bua-wm approach used by current SBC products. TURN will work with e2e sip security mechanisms, and does not require a b2bua function in the network, which can cause problems with new sip features (see, for example, the recent thread on how sbc's interfere with gruu operation). Thanks, Jonathan R. vikram wrote: > Hello All, > We are facing lots of problem with NAT traversal=20 > for SIP . > It is not working behind symmetric NAT. I could see various=20 > solutions but none is 100% promising. ?? > e.g 1) ALGs(intelligent firewall) 2)Session=20 > Border Controller > 3)TURN > 4) Tunneling (e.g X-tunnel) > 5) RTP proxy ?? > Which one is best ??? >=20 > we are looking for a solution which could work by just *changing > our client* and/or *by using a global server*... > ALGs require upgradation of Firewalls, which everybody cant afford.=20 > Tunneling too require some server entity within Intranet and > a global server, which again is not possible to deploy at every=20 > place . >=20 > Now question remains about TURN and SBCs. TURN is still in=20 > process ..has anybody implemented. ? > Session border controller seems promising ...? > but could i have a SBC for a trial period with whom i can connect > my client ?? > *Dose anybody provide free SBC service as of SIP proxies ??* > =20 > Please Help !!!! >=20 >=20 > regards >=20 > Vikram > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > 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 sip >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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://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 From sip-bounces@ietf.org Sat Sep 25 16:03:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14736 for ; Sat, 25 Sep 2004 16:03:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBItF-0000Wc-V2 for sip-web-archive@ietf.org; Sat, 25 Sep 2004 16:11:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBIaf-0005tx-Sa; Sat, 25 Sep 2004 15:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWNU-0003kZ-TO for sip@megatron.ietf.org; Thu, 23 Sep 2004 12:23:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27343 for ; Thu, 23 Sep 2004 12:23:25 -0400 (EDT) Received: from figas.ekabal.com ([157.22.13.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWUJ-0003KB-Bg for sip@ietf.org; Thu, 23 Sep 2004 12:30:31 -0400 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id i8NGNKc03538; Thu, 23 Sep 2004 09:23:20 -0700 In-Reply-To: <4152E5C6.4020905@softarmor.com> References: <20040902001944.8D2B93D0FB@ms2.alpha.co.jp> <4152E5C6.4020905@softarmor.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Rohan Mahy Subject: Re: [sip]Join header syntax related to RFC2543 Date: Thu, 23 Sep 2004 09:23:39 -0700 To: Dean Willis X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 X-Mailman-Approved-At: Sat, 25 Sep 2004 15:52:12 -0400 Cc: dpetrie@pingtel.com, Rohan Mahy , sip@ietf.org, =?ISO-2022-JP?B?GyRCQFBAbiEhMCYbKEI=?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0235458443==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 --===============0235458443== Content-Type: multipart/alternative; boundary=Apple-Mail-3--462180903 --Apple-Mail-3--462180903 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Hi, The intent of the text is that either the to-tag or the from-tag parameter could match a null tag. Examples are non-normative, so they should not limit what you can do. The normative text intentionally says "a tag" and does not specify what kind of tag. I'm assuming the following text would clarify things appropriately. For compatibility with ... RFC 2543 compliant UAs, a to-tag of zero matches both a to-tag value of zero and a null to-tag. Likewise, a from-tag of zero matches both a to-tag value of zero and a null from-tag. I might even be able to get this text into Replaces as well. thanks, -rohan On Sep 23, 2004, at 8:03 AM, Dean Willis wrote: > $B@P@n!!0&(B wrote: >> Hi, >> >> I have a question associated with draft-ietf-sip-join-03.txt >> and draft-ietf-sip-replaces-05.txt. >> >> >> Join document at the tail of Section 7.1 saids: >> >> For compatibility with dialogs initiated by RFC2543 [11] >> compliant UAs, a tag of zero matches both tags of zero and null tags >> >> Examples: >> Join: 87134@192.0.2.23;to-tag=24796;from-tag=0$B!!(B >> >> and also said at section 6.1 in Replaces document. >> >> >> >> In inverse case, i.e., there is a dialog initiated by RFC3261 >> compliant UAs to RFC2543 compliant UAs, is the same? >> In other words, there is a possibility that there is >> no to-tag in this case. So we can as below? >> >> For example, >> Join: 12345@192.1.2.3;to-tag=0;from-tag=56789 >> >> >> In this example, does tag of zero matches both tags of zero >> and null tags? And also for Replaces? > > That's my reading of the doc, although in retrospect the wording at the > end of joing-7.1 is particularly clumsy, and I wish somebody had > noticed > sooner. > > I'd like to ask the authors to clarify here, and perhaps we can get an > errata entry with that clarification. > > -- > Dean > > _______________________________________________ > 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 --Apple-Mail-3--462180903 Content-Type: text/enriched; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, The intent of the text is that either the to-tag or the from-tag parameter could match a null tag. Examples are non-normative, so they should not limit what you can do. The normative text intentionally says "a tag" and does not specify what kind of tag. I'm assuming the following text would clarify things appropriately. For compatibility with ... RFC 2543 compliant UAs, a to-tag of zero matches both a to-tag value of zero and a null to-tag. Likewise, a from-tag of zero matches both a to-tag value of zero and a null from-tag. I might even be able to get this text into Replaces as well. thanks, -rohan On Sep 23, 2004, at 8:03 AM, Dean Willis wrote: Hiragino Kaku Gothic Pro$B@P@n!!0&(B wrote: Hi, I have a question associated with draft-ietf-sip-join-03.txt and draft-ietf-sip-replaces-05.txt. Join document at the tail of Section 7.1 saids: For compatibility with dialogs initiated by RFC2543 [11] compliant UAs, a tag of zero matches both tags of zero and null tags Examples: Join: 87134@192.0.2.23;to-tag=24796;from-tag=0Hiragino Kaku Gothic Pro$B!!(B and also said at section 6.1 in Replaces document. In inverse case, i.e., there is a dialog initiated by RFC3261 compliant UAs to RFC2543 compliant UAs, is the same? In other words, there is a possibility that there is no to-tag in this case. So we can as below? For example, Join: 12345@192.1.2.3;to-tag=0;from-tag=56789 In this example, does tag of zero matches both tags of zero and null tags? And also for Replaces? That's my reading of the doc, although in retrospect the wording at the end of joing-7.1 is particularly clumsy, and I wish somebody had noticed sooner. I'd like to ask the authors to clarify here, and perhaps we can get an errata entry with that clarification. -- Dean _______________________________________________ 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 --Apple-Mail-3--462180903-- --===============0235458443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --===============0235458443==-- From sip-bounces@ietf.org Sun Sep 26 22:03:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13024 for ; Sun, 26 Sep 2004 22:03:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBkzH-0003fb-Gp for sip-web-archive@ietf.org; Sun, 26 Sep 2004 22:11:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBkpW-0001gu-Dr; Sun, 26 Sep 2004 22:01:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBkoX-0001XB-J9 for sip@megatron.ietf.org; Sun, 26 Sep 2004 22:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12894 for ; Sun, 26 Sep 2004 22:00:27 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBkvu-0003aW-A1 for sip@ietf.org; Sun, 26 Sep 2004 22:08:16 -0400 Received: from dynamicsoft.com ([63.113.46.24]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8R208pl003519; Sun, 26 Sep 2004 22:00:08 -0400 (EDT) Message-ID: <41577412.6040006@dynamicsoft.com> Date: Sun, 26 Sep 2004 21:59:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vikram Bhuskute Subject: Re: [Sip] STUN server Misleads ! References: <41540A09.4030509@aftek.com> In-Reply-To: <41540A09.4030509@aftek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: sip-ietf X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Vikram, The problem may lie in the fact that RFC 3489's definition of NAT types is known to be outdated. In particular, some NATs are known to exhibit different behaviors based on whether the source port is in use or not. See: http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-01.txt http://www.ietf.org/internet-drafts/draft-audet-nat-behave-00.txt -Jonathan R. Vikram Bhuskute wrote: > Helo all, > I am using an open stun client. It helped me a lot . But there > is problem. > one out of five times my stun gives me wrong type of NAT !! When > i traced the packets .. > .i found it is not my client's faul server itself is > responisble for that. > > e.g. I was behind port restricted NAT and still i got different > binding for Test 1.2 > (request to other IP of STUN server) > and my client concluded from protocol that it is Symmetric NAT. > > I tried 5-6 STUN server i could found. but same problem > > Is it a known issue ? Is any STUN server is bug free ? > > > regards > > vikram > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Sep 27 08:39:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25830 for ; Mon, 27 Sep 2004 08:39:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBuum-00054P-Ot for sip-web-archive@ietf.org; Mon, 27 Sep 2004 08:47:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBufZ-0000pk-Ny; Mon, 27 Sep 2004 08:31:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBucm-0000SG-3X for sip@megatron.ietf.org; Mon, 27 Sep 2004 08:29:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25279 for ; Mon, 27 Sep 2004 08:28:58 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBukO-0004sx-9k for sip@ietf.org; Mon, 27 Sep 2004 08:36:52 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 13:28:21 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E52FFA@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Jonathan Rosenberg'" Subject: FW: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying next transport upon failure Date: Mon, 27 Sep 2004 13:28:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: SIP WG , "Paul D.Smith" , "'Brett Tate'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Jonathan, Can I please ask you to comment on the discussion Brett and I have been having via the WG regarding the use of NAPTR records? The question is whether the use of multiple transports, indicated by multiple NAPTR records, SRV records or client support for multiple transports should be attempted or not. I can see an advantage to defining, say "TLS preferred over TCP over UDP" but this would only be useful under the "just try one transport" idea if the client only supported one of the less preferred options. However the "try all in order" idea allows for, for example, a separate TLS connection server to be preferred but for TCP to be acceptable (possibly with some restrictions imposed through other means) if the TLS server is unavailable. So what is the intended processing? Also in either case, would you like to raise a bugzilla report to ensure this is clarified in a future release of the specification? Thanks, Paul D Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: 17 September 2004 18:31 To: SIP Public Folder (E-mail) Subject: RE: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying next transport upon failure Hi Jonathan, Do you agree with Paul's interpretation concerning advancement to the next transport (next NAPTR record or set of SRV records)? My interpretation was that advancing between transports has been removed. There are likely good reasons for and against advancing between transports. I am just trying to understand what rfc3263, rfc2915, and rfc3261 indicate or should have indicated. Thanks in advance, Brett Tate > RFC3263, section 4.1, contains the following text > > If no NAPTR records are found, the client > constructs SRV queries for those transport > protocols it supports, and does a query for > each. Queries are done using the service > identifier "_sip" for SIP URIs and "_sips" > for SIPS URIs. A particular transport is > supported if the query is successful. The > client MAY use any transport protocol it > desires which is supported by the server. > > This means that potentially the set of > SRV records covers multiple protocols in > the case that no NAPTR records are returned. I interpret the text as indicating that one transport should be selected instead of potentially combining the multiple sets of srv records. > It therefore seems only sensible to me > that if multiple transports are indicated > by NAPTR records, that they too should be > tried, in the order indicated by the NAPTR > records. Hopefully there would have been a statement indicating when to advance to the next NAPTR record. Or there could have been a statement indicating the combining of all the SRV records for each NAPTR record. _______________________________________________ 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 From sip-bounces@ietf.org Mon Sep 27 10:48:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04776 for ; Mon, 27 Sep 2004 10:48:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwvQ-0007P5-Sz for sip-web-archive@ietf.org; Mon, 27 Sep 2004 10:56:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBweA-0008Id-Ve; Mon, 27 Sep 2004 10:38:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwba-0007hb-FI; Mon, 27 Sep 2004 10:35:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03936; Mon, 27 Sep 2004 10:35:51 -0400 (EDT) Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwjC-0007AR-V6; Mon, 27 Sep 2004 10:43:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Sep 2004 16:35:21 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A330406FA4B@email10.etsihq.org> Thread-Topic: Simple question about ENUM service in SIP solutions ? Thread-Index: AcSknzdgEk266Jf+Ru6z0GOqD4UFzg== From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: plugtests-enum@list.etsi.org Subject: [Sip] Simple question about ENUM service in SIP solutions ? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Dear All, Basic question : Do you know a SIP product available implementating enum ? We are preparing enum interop tests and need to identify which SIP products that already adopted enum ? We will contact them to set up the test bed for next coming enum = Plugtests. Thank you very much I advance for any help. Patrick GUILLEMIN=20 ETSI - Plugtests Technical Coordinator=20 http://www.etsi.org/plugtests tel +33(0)4 92 94 43 31=20 fax +33(0)4 92 38 52 31=20 _______________________________________=20 _______________________________________________ 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 From sip-bounces@ietf.org Tue Sep 28 09:29:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21584 for ; Tue, 28 Sep 2004 09:29:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIAh-0001Ly-JV for sip-web-archive@ietf.org; Tue, 28 Sep 2004 09:37:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHxI-0003nc-13; Tue, 28 Sep 2004 09:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHqX-0001o1-IY for sip@megatron.ietf.org; Tue, 28 Sep 2004 09:16:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20810 for ; Tue, 28 Sep 2004 09:16:43 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHyN-00016e-7l for sip@ietf.org; Tue, 28 Sep 2004 09:24:51 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0I4R0080160D56@siemenscomms.co.uk> for sip@ietf.org; Tue, 28 Sep 2004 14:12:16 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0I4R0062T5R4HR@siemenscomms.co.uk> for sip@ietf.org; Tue, 28 Sep 2004 14:06:40 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Sep 2004 14:08:26 +0100 Content-return: allowed Date: Tue, 28 Sep 2004 14:08:24 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670252D3F5@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7BIT Subject: [Sip] Question on offer-answer during establishment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT RFC3261 states (13.2.1, second bullet): "The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE." Suppose SDP answer is received in a reliable provisional response. This would complete the offer-answer sequence. The behaviour mandated here would seem to preclude the UAS sending a further offer in a subsequent reliable provisional response or 2xx. Is this intended, and if so for what reason? Obviously the UAS can send an UPDATE request (or re-INVITE request after answer) if it wishes to re-negotiate the session, but this would involve additional messages. John Elwell (john.elwell@siemens.com) _______________________________________________ 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 From sip-bounces@ietf.org Tue Sep 28 10:00:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23384 for ; Tue, 28 Sep 2004 10:00:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIeR-0001th-Cb for sip-web-archive@ietf.org; Tue, 28 Sep 2004 10:08:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIVO-00084p-4p; Tue, 28 Sep 2004 09:58:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCISh-0007lT-93 for sip@megatron.ietf.org; Tue, 28 Sep 2004 09:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23145 for ; Tue, 28 Sep 2004 09:56:09 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIaW-0001pU-7m for sip@ietf.org; Tue, 28 Sep 2004 10:04:17 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8SDu7WR000262 for ; Tue, 28 Sep 2004 15:56:07 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Sep 2004 15:56:07 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Sep 2004 15:56:07 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Elwell, John'" , sip@ietf.org Subject: RE: [Sip] Question on offer-answer during establishment Date: Tue, 28 Sep 2004 15:55:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Sep 2004 13:56:07.0198 (UTC) FILETIME=[E6DF2BE0:01C4A562] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi, >RFC3261 states (13.2.1, second bullet): > >"The UAC MUST treat the first session description it receives >as the answer, and MUST ignore any session descriptions in subsequent >responses to the initial INVITE." > >Suppose SDP answer is received in a reliable provisional >response. This would complete the offer-answer sequence. Correct. >The behaviour mandated here would seem to preclude the UAS sending a further offer in a >subsequent reliable provisional response or 2xx. Exactly. >Is this intended, and if so for what reason? There has been discussions about this before, but I guess to put it short the answer is that you can only have at-most (sometimes you only send a single offer, or answer, within one transaction, but never more than one complete offer/answer exchange) one offer/answer exchange per SIP transaction. >Obviously the UAS can send an UPDATE request (or re-INVITE >request after answer) if it wishes to re-negotiate the session, Correct, but that is within a separate SIP transaction. >but this would involve additional messages. C'est la vie. Please also note, that you are only allowed to send SDP (offer or answer) in the FIRST PRACK, so even if you would send new offers in provisional responses you would still have to use a non-PRACK mechanism to send the answers. Sending SDPs in PRACK then causes other problems, ie how you would reject those, but that's another issue... Regards, Christer Holmberg Ericsson Finland > > John Elwell (john.elwell@siemens.com) > > > > _______________________________________________ > 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://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 From sip-bounces@ietf.org Tue Sep 28 10:14:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24489 for ; Tue, 28 Sep 2004 10:14:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIsW-0002Al-JR for sip-web-archive@ietf.org; Tue, 28 Sep 2004 10:22:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIjN-0004Nu-Dl; Tue, 28 Sep 2004 10:13:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIht-00041f-Gm for sip@megatron.ietf.org; Tue, 28 Sep 2004 10:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24205 for ; Tue, 28 Sep 2004 10:11:51 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIpi-000271-Fv for sip@ietf.org; Tue, 28 Sep 2004 10:19:59 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2004 10:11:20 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8SEBIbx013750; Tue, 28 Sep 2004 10:11:18 -0400 (EDT) Received: from [64.102.92.205] (dhcp-64-102-92-205.cisco.com [64.102.92.205]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCH69660; Tue, 28 Sep 2004 07:11:17 -0700 (PDT) Message-ID: <41597105.70105@cisco.com> Date: Tue, 28 Sep 2004 10:11:17 -0400 From: Michael Zhou User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Question on offer-answer during establishment References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Christer, Can you point me to the RFC(s) (probably in 3262?) that says a UA is only allowed to send SDP in the first PRACK? Thanks Michael Christer Holmberg (JO/LMF) wrote: >Please also note, that you are only allowed to send SDP (offer or answer) in the FIRST PRACK, so even if you would send new offers in provisional responses you would still have to use a non-PRACK mechanism to send the answers. > >Sending SDPs in PRACK then causes other problems, ie how you would reject those, but that's another issue... > _______________________________________________ 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 From sip-bounces@ietf.org Tue Sep 28 11:14:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28895 for ; Tue, 28 Sep 2004 11:14:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJnv-0003Ed-Vg for sip-web-archive@ietf.org; Tue, 28 Sep 2004 11:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJdz-0006t9-F5; Tue, 28 Sep 2004 11:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJaV-0006Al-R4 for sip@megatron.ietf.org; Tue, 28 Sep 2004 11:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28540 for ; Tue, 28 Sep 2004 11:08:17 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJiL-00037u-J2 for sip@ietf.org; Tue, 28 Sep 2004 11:16:27 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Sep 2004 08:11:12 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8SF7fwp025932; Tue, 28 Sep 2004 08:07:42 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALW68410; Tue, 28 Sep 2004 11:07:43 -0400 (EDT) Message-ID: <41597E3F.40501@cisco.com> Date: Tue, 28 Sep 2004 11:07:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Question on offer-answer during establishment References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Christer Holmberg (JO/LMF) wrote: > > Please also note, that you are only allowed to send SDP (offer or answer) in the FIRST PRACK, so even if you would send new offers in provisional responses you would still have to use a non-PRACK mechanism to send the answers. > > Sending SDPs in PRACK then causes other problems, ie how you would reject those, but that's another issue... Christer, I have to quibble with the above. If the INVITE is offerless, then an offer must be present in the first reliable response. If that is a reliable 1xx, then the 1xx must be answered with a PRACK, and that prack must contain the answer. So in that case the answer would be in the first PRACK. I believe that is the *only* case in which an answer can be in a PRACK, and that there are *no* cases where an offer can be in a prack. Paul _______________________________________________ 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 From sip-bounces@ietf.org Tue Sep 28 11:34:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00073 for ; Tue, 28 Sep 2004 11:34:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCK7S-0003dQ-NZ for sip-web-archive@ietf.org; Tue, 28 Sep 2004 11:42:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJru-0000xU-NS; Tue, 28 Sep 2004 11:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJp7-0000cY-Ne for sip@megatron.ietf.org; Tue, 28 Sep 2004 11:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29469 for ; Tue, 28 Sep 2004 11:23:23 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJwy-0003Qh-KE for sip@ietf.org; Tue, 28 Sep 2004 11:31:33 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2004 08:36:16 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8SFMnlr020958; Tue, 28 Sep 2004 08:22:50 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALW69916; Tue, 28 Sep 2004 11:22:50 -0400 (EDT) Message-ID: <415981CA.7040208@cisco.com> Date: Tue, 28 Sep 2004 11:22:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rakhan@hssworld.com Subject: Re: [Sip] Contact: headers in SIP REGISTER 200 OK responses References: <20040921073112.55612.qmail@web51103.mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA29469 Cc: sip@ietf.org, "Gerke, Tom" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Rayees Khan wrote: > =20 > I think that the REGISTER messages from both the UAs would be taken by=20 > registrar to be from same UA. I disagree. It seems pretty clearcut that these are independent and that=20 the registrar should accept them both. This is exactly how you get=20 multiple contacts associated with an AOR. More below. > As a result the second REGISTER would be > taken as re-REGISTER. Now the validity of the contacts in the two would= =20 > depend on the expires parameter in the contact header. > These contacts can be overlapping too. > In any case the response to the REGISTER message would be sent to the=20 > Via address mentioned in the REGISTER rathar than the address specified= =20 > in contact. > =20 > =20 > regards > Rayees > =20 >=20 >=20 > */"Gerke, Tom" /* wrote: >=20 > Hello, >=20 > =20 >=20 > If two different UAs (in the same domain) happen to register a user > using the same AOR (but different Contact addresses), to the same > Registrar, what would be in their respective REGISTER 200 OK > responses from that Registrar? i.e. Would they be notified of eac= h > others=92 bindings?=20 >=20 > Section 10.3, step 8, of the SIP spec states that the 200 OK > response will contain =93all current bindings=94. It doesn=92t men= tion > anything about the Call-IDs for those bindings having to match up o= r > anything. >=20 > =20 >=20 > So, let=92s say: >=20 > First, UA 1 decides to register AOR sip:userA@example.com > I don't understand the in the above. You have two URLs, and=20 the mailto seems entirely inappropriate. I'm assuming it isn't there. The presence of this suggests that you have some kind of=20 misunderstanding, but I can't tell what it is. > with the Contact address > sip:usr1212@102.103.104.105 to a Registrar. >=20 > Then sometime later UA 2 decides to register AOR > sip:userA@example.com with the Contact again ignoring > address sip:m1300@102.103.104.105:5070 to that same Registrar. >=20 > =20 >=20 > Assuming both of these UAs used unique Call-IDs, and there were no > authorization issues, what Contact: headers would be in the REGISTE= R > 200 OK response message from this Registrar: >=20 > 1) When UA 2 received its initial REGISTER response? It would see both registered contacts. Each should show the remaining=20 time till expiration in the expires parameter. > 2) Sometime later when UA 1 then refreshes its binding for AOR > sip:userA@example.com ? Assuming the contact from UA2 hasn't expired, there should again be two=20 contacts, as above. If the contact from UA2 had expired without refresh,=20 then only the refreshed contact would be seen. > Thanks in advance for any clarification on this matter, >=20 > -Tom >=20 > =20 >=20 > _______________________________________________ > 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 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > 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://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 From sip-bounces@ietf.org Tue Sep 28 19:27:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03340 for ; Tue, 28 Sep 2004 19:27:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRVa-0005pL-JU for sip-web-archive@ietf.org; Tue, 28 Sep 2004 19:35:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQzy-0006iv-Fe; Tue, 28 Sep 2004 19:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQv0-0005lW-6X; Tue, 28 Sep 2004 18:57:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01229; Tue, 28 Sep 2004 18:57:55 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCR2v-00057U-4g; Tue, 28 Sep 2004 19:06:09 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i8SMvHJ01896; Tue, 28 Sep 2004 15:57:17 -0700 (PDT) Message-Id: <200409282257.i8SMvHJ01896@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Sep 2004 15:57:17 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 3891 on The Session Initiation Protocol (SIP) "Replaces" Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3891 Title: The Session Initiation Protocol (SIP) "Replaces" Header Author(s): R. Mahy, B. Biggs, R. Dean Status: Standards Track Date: September 2004 Mailbox: rohan@cisco.com, bbiggs@dumbterm.net, rfc@fdd.com Pages: 16 Characters: 34180 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-replaces-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3891.txt This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040928155545.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3891 --OtherAccess Content-Type: Message/External-body; name="rfc3891.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040928155545.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --NextPart-- From sip-bounces@ietf.org Tue Sep 28 19:38:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04396 for ; Tue, 28 Sep 2004 19:38:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRgY-0006Bf-It for sip-web-archive@ietf.org; Tue, 28 Sep 2004 19:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRCH-00005d-GV; Tue, 28 Sep 2004 19:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQwu-00064A-JX; Tue, 28 Sep 2004 18:59:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01325; Tue, 28 Sep 2004 18:59:53 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCR4p-00059Q-Hx; Tue, 28 Sep 2004 19:08:07 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i8SMxHJ02453; Tue, 28 Sep 2004 15:59:17 -0700 (PDT) Message-Id: <200409282259.i8SMxHJ02453@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Sep 2004 15:59:17 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 3892 on The Session Initiation Protocol (SIP) Referred-By Mechanism X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3892 Title: The Session Initiation Protocol (SIP) Referred-By Mechanism Author(s): R. Sparks Status: Standards Track Date: September 2004 Mailbox: RjS@xten.com Pages: 25 Characters: 52441 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-referredby-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3892.txt The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040928155733.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3892 --OtherAccess Content-Type: Message/External-body; name="rfc3892.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040928155733.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --NextPart-- From sip-bounces@ietf.org Tue Sep 28 19:44:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05035 for ; Tue, 28 Sep 2004 19:44:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRm1-0006QX-2s for sip-web-archive@ietf.org; Tue, 28 Sep 2004 19:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRE0-0000V2-V2; Tue, 28 Sep 2004 19:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQys-0006Fy-8R; Tue, 28 Sep 2004 19:01:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01440; Tue, 28 Sep 2004 19:01:55 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCR6n-0005Bi-7f; Tue, 28 Sep 2004 19:10:09 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i8SN12J02874; Tue, 28 Sep 2004 16:01:02 -0700 (PDT) Message-Id: <200409282301.i8SN12J02874@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Sep 2004 16:01:02 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -13.8 (-------------) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 3893 on Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: -13.8 (-------------) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3893 Title: Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format Author(s): J. Peterson Status: Standards Track Date: September 2004 Mailbox: jon.peterson@neustar.biz Pages: 13 Characters: 28500 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-authid-body-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3893.txt RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040928155935.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3893 --OtherAccess Content-Type: Message/External-body; name="rfc3893.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040928155935.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --NextPart-- From sip-bounces@ietf.org Wed Sep 29 01:06:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26297 for ; Wed, 29 Sep 2004 01:06:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCWnl-0004UX-QB for sip-web-archive@ietf.org; Wed, 29 Sep 2004 01:15:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCWdG-0001DN-Bk; Wed, 29 Sep 2004 01:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCWcj-0000vr-5C for sip@megatron.ietf.org; Wed, 29 Sep 2004 01:03:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26147 for ; Wed, 29 Sep 2004 01:03:27 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCWkg-0004RZ-Tu for sip@ietf.org; Wed, 29 Sep 2004 01:11:43 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8T53QfM009754 for ; Wed, 29 Sep 2004 07:03:26 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Sep 2004 07:03:26 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Sep 2004 07:03:26 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" Subject: RE: [Sip] Question on offer-answer during establishment Date: Wed, 29 Sep 2004 07:03:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 29 Sep 2004 05:03:26.0299 (UTC) FILETIME=[A71AC2B0:01C4A5E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org, "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, >>Please also note, that you are only allowed to send SDP >>(offer or answer) in the FIRST PRACK, so even if you would >>send new offers in provisional responses you would still have >>to use a non-PRACK mechanism to send the answers. >> >>Sending SDPs in PRACK then causes other problems, ie how >>you would reject those, but that's another issue... > >Christer, > >I have to quibble with the above. > >If the INVITE is offerless, then an offer must be present in >the first reliable response. If that is a reliable 1xx, then the 1xx must be >answered with a PRACK, and that prack must contain the answer. So in >that case the answer would be in the first PRACK. Correct. >I believe that is the *only* case in which an answer can be >in a PRACK, and that there are *no* cases where an offer can be in a prack. I would be very happy if that was true :) However, chapter 5 in RFC 3262 says: "If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK." Now, I have to admit I did not find the text saying that we're only allowed to use the first PRACK to send a new offer, but my understanding is that that is the case, and one of the reasons for that was to "save" a SIP transaction in pre-condition scenarios (instead of sending the first updated offer in an UPDATE you can use the PRACK). But, correct me if I'm wrong. At the previous SIPit we had some discussions about the usage of PRACK for offer/answer. The problem, as said before, is that there is currently no standard way to reject an offer received in a PRACK, because a UAS MUST answer with 200 OK, if the PRACK otherwise is ok, matches a reliabel provisional response etc. It has even been suggested that it should be forbidden to send SDPs (at least new offers) in PRACKs, but that would of course have impacts on existing nodes - depending on how many nodes currently support it in the first place, of course. Regards, Christer Holmberg Ericsson Finland > > Paul > _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 29 03:09:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00472 for ; Wed, 29 Sep 2004 03:09:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCYiv-0006bh-6a for sip-web-archive@ietf.org; Wed, 29 Sep 2004 03:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCYAg-0001dq-A2; Wed, 29 Sep 2004 02:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCY6s-0000nE-RI for sip@megatron.ietf.org; Wed, 29 Sep 2004 02:38:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28985 for ; Wed, 29 Sep 2004 02:38:41 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCYEr-00064l-Kx for sip@ietf.org; Wed, 29 Sep 2004 02:46:58 -0400 Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8T6cCpl014679; Wed, 29 Sep 2004 02:38:12 -0400 (EDT) Message-ID: <415A583D.1070304@dynamicsoft.com> Date: Wed, 29 Sep 2004 02:37:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul D.Smith" Subject: Re: FW: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying next transport upon failure References: <53F74F5A7B94D511841C00B0D0AB16F803E52FFA@baker.datcon.co.uk> In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E52FFA@baker.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.0 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: SIP WG , "'Brett Tate'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Thanks for prodding me to answer this. I agree this is confusing. RFC 3261 seems to refer to the notion that you can change transports on different attempts (end of 8.1.2). However, RFC 3263 would seem to indicate that the NAPTR result would be a single service, and therefore, a single transport. The correct behavior is the latter. That is, the NAPTR processing will select a single transport, and that's what gets used. Previously, we were allowing attempts across transports because we were combining addresses from different SRV records and merging them. This was deemed a no-no by the DNS folks, due to the operational issues with comparing preference values across records. Once we eliminated this merging, the updated procedures in RFC 3263 effectively resulted in selection of a single transport, but this wasn't made fully consistent with RFC 3261. I've logged a bug against 3261 to clarify (http://bugs.sipit.net/sipwg/show_bug.cgi?id=760). Thanks, Jonathan R. Paul D.Smith wrote: > Jonathan, > > Can I please ask you to comment on the discussion Brett and I have been > having > via the WG regarding the use of NAPTR records? > > The question is whether the use of multiple transports, indicated by > multiple > NAPTR records, SRV records or client support for multiple transports should > be attempted or not. > > I can see an advantage to defining, say "TLS preferred over TCP over UDP" > but > this would only be useful under the "just try one transport" idea if the > client only supported one of the less preferred options. > > However the "try all in order" idea allows for, for example, a separate TLS > connection server to be preferred but for TCP to be acceptable (possibly > with > some restrictions imposed through other means) if the TLS server is > unavailable. > > So what is the intended processing? Also in either case, would you like to > raise a bugzilla report to ensure this is clarified in a future release of > the > specification? > > Thanks, > Paul D Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 17 September 2004 18:31 > To: SIP Public Folder (E-mail) > Subject: RE: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying > next transport upon failure > > > Hi Jonathan, > > Do you agree with Paul's interpretation > concerning advancement to the next transport > (next NAPTR record or set of SRV records)? > > My interpretation was that advancing > between transports has been removed. > > There are likely good reasons for and > against advancing between transports. > I am just trying to understand what > rfc3263, rfc2915, and rfc3261 indicate > or should have indicated. > > Thanks in advance, > Brett Tate > > > >>RFC3263, section 4.1, contains the following text >> >> If no NAPTR records are found, the client >> constructs SRV queries for those transport >> protocols it supports, and does a query for >> each. Queries are done using the service >> identifier "_sip" for SIP URIs and "_sips" >> for SIPS URIs. A particular transport is >> supported if the query is successful. The >> client MAY use any transport protocol it >> desires which is supported by the server. >> >>This means that potentially the set of >>SRV records covers multiple protocols in >>the case that no NAPTR records are returned. > > > I interpret the text as indicating that one > transport should be selected instead of > potentially combining the multiple sets of > srv records. > > >>It therefore seems only sensible to me >>that if multiple transports are indicated >>by NAPTR records, that they too should be >>tried, in the order indicated by the NAPTR >>records. > > > Hopefully there would have been a statement > indicating when to advance to the next NAPTR > record. Or there could have been a statement > indicating the combining of all the SRV records > for each NAPTR record. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 29 07:22:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21895 for ; Wed, 29 Sep 2004 07:22:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCcfB-0003im-HZ for sip-web-archive@ietf.org; Wed, 29 Sep 2004 07:30:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCcOF-00073o-5q; Wed, 29 Sep 2004 07:12:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCcFn-0005bF-I5 for sip@megatron.ietf.org; Wed, 29 Sep 2004 07:04:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20631 for ; Wed, 29 Sep 2004 07:04:08 -0400 (EDT) Received: from [203.129.224.106] (helo=kr.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCcNo-0003P5-5O for sip@ietf.org; Wed, 29 Sep 2004 07:12:29 -0400 Received: from [10.0.0.145] ([10.0.0.145]) by kr.aftek.com (8.11.6/8.11.6) with ESMTP id i8TB45M17152 for ; Wed, 29 Sep 2004 16:34:06 +0530 Message-ID: <415A986B.9070008@aftek.com> Date: Wed, 29 Sep 2004 16:41:39 +0530 From: Vikram Bhuskute User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-takeda-symmetric-nat-traversal ?? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hello all, While searching for NAT traversal solution i came across a draft "draft-takeda-symmetric-nat-traversal-00.txt" from url ( http://cnscenter.future.co.kr/resource/ietf/ind-draft/draft-takeda-symmetric-nat-traversal-00.txt) It proposes some solution for Symmetric NAT based on some Prediction .....? It dosent seem reliable ... !!! (however it gives glimps on type of Symmetric NATs ) Is it still a matter of further research ? or the concept is not well accepted ? thanks in advance vikram _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 29 08:41:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28271 for ; Wed, 29 Sep 2004 08:41:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCduD-0005TH-Cy for sip-web-archive@ietf.org; Wed, 29 Sep 2004 08:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdct-0005GB-ON; Wed, 29 Sep 2004 08:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdRF-0003NG-MT for sip@megatron.ietf.org; Wed, 29 Sep 2004 08:20:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26573 for ; Wed, 29 Sep 2004 08:20:04 -0400 (EDT) From: leo_minor@mail.goo.ne.jp Received: from cm136.mail.goo.ne.jp ([210.150.10.136] helo=mail.goo.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCdZH-00053X-9i for sip@ietf.org; Wed, 29 Sep 2004 08:28:24 -0400 Received: (qmail 1425 invoked by uid 65534); 29 Sep 2004 21:20:01 +0900 Date: 29 Sep 2004 21:20:01 +0900 Message-ID: <20040929122001.1424.qmail@mail.goo.ne.jp> To: sip@ietf.org Subject: =?ISO-2022-JP?B?UmU6IFtTaXBdIFJlOiBSRkMzNTE1IFJlZmVyLVRvIEFCTkY=?= Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-type: text/plain; charset=iso-2022-jp X-Original-IP: [210.136.112.93] X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Hi Robert. If this rule adjusts to all headers, I think that it is necessary to allow the use of addr-spec for the Route/Record-Route header. ex. Route: sip:proxy.example.com Jone. Robert Sparks wrote in <29104F89-0D71-11D9-90F7-000D93326732@xten.com> >The use is the same in Refer-To as it was for From/To/Contact. > >Any instance of name-addr | addr-spec in SIP headers will follow this >same rule. >(and we are being more careful as we go forward to be explicit in each >document) > >If you have a URI parameter you must place it inside angle brackets. >Any semicolon >delimited parameters appearing outside brackets are header parameters, >not URI >parameters. > >RjS > >On Sep 23, 2004, at 9:42 AM, Joel Payeur wrote: > >> Hi, >> >> Refer-To's ABNF: >> >> Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * >> (SEMI generic-param) >> >> as well as being incompatible with previous Refer-To draft ABNF (it >> adds optional parameters at the header level), does not seem to be >> consistent on its own. >> >> If I have the header: >> >> Refer-To: sip:user@host;param=value >> >> This is RFC3515 ABNF compliant. However, is "param" part of the >> header, or part of the URI? If i use the addr-spec form, i guess the >> param should be part of the URI then. Or is it? >> >> The problem comes from allowing name-addr/addr-spec. This was also >> present for other headers in RFC3261, these are From,To, Contact and >> Reply-To, however for each of these a comment was inserted to clarify >> that the name-addr form (angle quotes) MUST be used if parameters or >> headers are present in the URI: >> >> RFC3261 Sect 20: >> >> The Contact, From, and To header fields contain a URI. If the URI >> contains a comma, question mark or semicolon, the URI MUST be >> enclosed in angle brackets (< and >). Any URI parameters are >> contained within these brackets. If the URI is not enclosed in >> angle >> brackets, any semicolon-delimited parameters are header-parameters, >> not URI parameters. >> >> Sect 20.31 Reply-To >> Even if the "display-name" is empty, the "name-addr" form MUST be >> used if the "addr-spec" contains a comma, question mark, or >> semicolon. Syntax issues are discussed in Section 7.3.1. >> >> >> My question is: If RFC3261 mandates that the name-addr form be used if >> the URI has parameters/headers, why would it not be the same for >> Refer-To? It is safe to assume that extension headers should also >> conform to this? Should we add the section 20.31 comment Refer-To's >> definition? The examples section in 3515 goes this way... >> >> I'm also wondering why the ABNF allows name-addr/addr-spec, when it >> could be simpler by allowing only name-addr, as is the case for Route >> and Record-route? Is this legacy for Pre-Rfc3515 compatibility? >> >> Thanks, _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 29 10:24:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08002 for ; Wed, 29 Sep 2004 10:24:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCfVF-0007kC-7M for sip-web-archive@ietf.org; Wed, 29 Sep 2004 10:32:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCfA3-0003V5-3o; Wed, 29 Sep 2004 10:10:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCf0G-0006Tv-Kr for sip@megatron.ietf.org; Wed, 29 Sep 2004 10:00:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05199 for ; Wed, 29 Sep 2004 10:00:18 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCf8I-0007GU-NZ for sip@ietf.org; Wed, 29 Sep 2004 10:08:40 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2004 10:17:14 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8TDxjbx024907; Wed, 29 Sep 2004 09:59:46 -0400 (EDT) Received: from [64.102.92.205] (dhcp-64-102-92-205.cisco.com [64.102.92.205]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCI50888; Wed, 29 Sep 2004 06:59:44 -0700 (PDT) Message-ID: <415ABFD0.70404@cisco.com> Date: Wed, 29 Sep 2004 09:59:44 -0400 From: Michael Zhou User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Question on offer-answer during establishment References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Paul Kyzivat'" , "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Christer Holmberg (JO/LMF) wrote: >At the previous SIPit we had some discussions about the usage of PRACK for offer/answer. The problem, as said before, is that there is currently no standard way to reject an offer received in a PRACK, because a UAS MUST answer with 200 OK, if the PRACK otherwise is ok, matches a reliabel provisional response etc. It has even been suggested that it should be forbidden to send SDPs (at least new offers) in PRACKs, but that would of course have impacts on existing nodes - depending on how many nodes currently support it in the first place, of course. > > It's not mentioned in RFC 3262 how to reject an offer, but 488 (Not Acceptable Here) might be a natural choice according to Section 13.3.1.3 of RFC 3261, quoted below. In practice, 4xx-6xx respons to PRACK (which contains offer) may also be considered rejection of offer. " A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected. " _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 29 15:01:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29034 for ; Wed, 29 Sep 2004 15:01:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjpr-0005F1-Ok for sip-web-archive@ietf.org; Wed, 29 Sep 2004 15:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCjVq-00067e-Ux; Wed, 29 Sep 2004 14:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCjCx-0002iu-SM for sip@megatron.ietf.org; Wed, 29 Sep 2004 14:29:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26404 for ; Wed, 29 Sep 2004 14:29:42 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjL2-0004RX-Cr for sip@ietf.org; Wed, 29 Sep 2004 14:38:05 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2004 14:46:38 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8TIT8bx018380; Wed, 29 Sep 2004 14:29:08 -0400 (EDT) Received: from cisco.com (dhcp-64-102-208-215.cisco.com [64.102.208.215]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCI76559; Wed, 29 Sep 2004 11:29:07 -0700 (PDT) Message-ID: <415AFEF3.1070808@cisco.com> Date: Wed, 29 Sep 2004 14:29:07 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] removing configuration from the SIP MIB References: <2CF7498A-E728-11D8-863B-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org WG" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit here are the proposed access level changes for mib objects in SIP-COMMON-MIB and SIP-SERVER-MIB modules... based on... http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-08.txt SIP-COMMON-MIB (currently 21 read-write objects) OBJECT PROPOSED CHANGE ---------------------- --------------- sipServiceAdminStatus remove sipOrganization make read-only sipServiceNotifEnable no change (note 1) sipCfgTimerA make read-only sipCfgTimerB make read-only sipCfgTimerC make read-only sipCfgTimerD make read-only sipCfgTimerE make read-only sipCfgTimerF make read-only sipCfgTimerG make read-only sipCfgTimerH make read-only sipCfgTimerI make read-only sipCfgTimerJ make read-only sipCfgTimerK make read-only sipCfgTimerT1 make read-only sipCfgTimerT2 make read-only sipCfgTimerT4 make read-only sipStatusCodeNotifSend no change (note 1) sipStatusCodeNotifEmitMode no change (note 1) sipStatusCodeNotifThresh no change (note 1) sipStatusCodeNotifInterval no change (note 1) SIP-SERVER-MIB (9 read-write objects) OBJECT PROPOSED CHANGE ---------------------- --------------- sipServerHostAddrType make read-only sipServerHostAddr make read-only sipProxyRecursion make read-only sipProxyRecordRoute make read-only sipProxyAuthMethod make read-only sipProxyAuthRealm make read-only sipRegAllowThirdParty make read-only sipRegMaxContactExpiryDuration make read-only sipRegDfltRegActiveInterval make read-only note 1: read-write required to configure snmp notifications. if there are no objections to this, we'll make it so in rev -09 of the draft. kevin Rohan Mahy wrote: > Hi Everyone, > > The current SIP MIB (-08) contains a handful of elements which are > related to configuration. These elements are insufficient to usefully > configure a UA or a Proxy. The SIP community already has a framework > for UA Profile configuration, and we have not identified anyone who is > planning to implement the SIP MIB for configuration. In addition, the > configuration issues directly affects 3 of the 4 open issues (#1, #46, > and #79) with the MIB. Finally, the IETF has de-emphasized using MIBs > for configuration since last year. > > Unless someone objects (and volunteers to help), the chairs propose that > we do not provide elements for configuration use, and don't make > elements write or create enabled which would only use this attribute for > configuration. We would keep many of these same elements for monitoring > the actual configuration of elements relevant for monitoring, debugging, > or troubleshooting purposes. If the group does not object, the authors > will propose specific changes to the list, edit the document > appropriately, and we can send the document to the Area Director. > > Please send mail right away if you disagree with this approach. > > If the group agrees with this proposal, this still leaves issue #87 as > an open issue, plus the issue that Bob Penfield recently brought up on > the list. Most issues with the MIB are discussed here: > > http://www1.ietf.org/mail-archive/web/sip/current/msg10184.html > > many thanks, > -rohan > > > _______________________________________________ > 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://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 From sip-bounces@ietf.org Wed Sep 29 17:07:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14610 for ; Wed, 29 Sep 2004 17:07:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CClnc-0001Yc-2J for sip-web-archive@ietf.org; Wed, 29 Sep 2004 17:15:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCkTE-0004W0-Bm; Wed, 29 Sep 2004 15:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCk9W-0004Dt-HW; Wed, 29 Sep 2004 15:30:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02227; Wed, 29 Sep 2004 15:30:12 -0400 (EDT) Message-Id: <200409291930.PAA02227@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 29 Sep 2004 15:30:12 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-identity-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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 : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson, C. Jennings Filename : draft-ietf-sip-identity-03.txt Pages : 32 Date : 2004-9-29 The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests and responses, especially in an interdomain context. This document recommends practices and conventions for identifying end users in SIP messages, and proposes a way to distribute cryptographically secure authenticated identities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-identity-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-identity-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-29153542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-identity-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-identity-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-29153542.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --NextPart-- From sip-bounces@ietf.org Wed Sep 29 17:15:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15772 for ; Wed, 29 Sep 2004 17:15:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CClvt-0001tK-F1 for sip-web-archive@ietf.org; Wed, 29 Sep 2004 17:24:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCkTI-0004Ym-R7; Wed, 29 Sep 2004 15:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCk9b-0004FL-4J; Wed, 29 Sep 2004 15:30:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02234; Wed, 29 Sep 2004 15:30:17 -0400 (EDT) Message-Id: <200409291930.PAA02234@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 29 Sep 2004 15:30:16 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc3312-update-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : Update to the Session Initiation Protocol (SIP) Preconditions Framework Author(s) : G. Camarillo, P. Kyzivat Filename : draft-ietf-sip-rfc3312-update-03.txt Pages : 10 Date : 2004-9-29 This document updates the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc3312-update-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rfc3312-update-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc3312-update-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-29153550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc3312-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc3312-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-29153550.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 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 --NextPart-- From sip-bounces@ietf.org Wed Sep 29 19:12:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29499 for ; Wed, 29 Sep 2004 19:12:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCnkk-0005XX-7W for sip-web-archive@ietf.org; Wed, 29 Sep 2004 19:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnJJ-0000nD-LP; Wed, 29 Sep 2004 18:52:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCmoo-0007kP-9e for sip@megatron.ietf.org; Wed, 29 Sep 2004 18:21:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25116 for ; Wed, 29 Sep 2004 18:20:59 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCmwl-0004O3-JB for sip@ietf.org; Wed, 29 Sep 2004 18:29:26 -0400 Received: (qmail 36278 invoked by uid 1014); 29 Sep 2004 22:20:15 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.75. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.357503 secs); 29 Sep 2004 22:20:15 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 29 Sep 2004 22:20:14 -0000 From: "Shan Lu" To: "'IETF SIP Mailing List'" Date: Wed, 29 Sep 2004 18:21:31 -0400 Message-ID: <001601c4a672$ac45bab0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [Sip] Question on RFC3261 Merged Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi, RFC3261 has following text: 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. Assume that calls to support@example.com is forked to two phone numbers on PSTN, say, 555-1111 and 555-2222. Further assume that there is only one SIP-PSTN gateway. The two INVITEs arriving at the gw are identical except for R-URI userinfo and top VIA branch (assuming forking proxy is the only proxy). My question is: why should GW 482 second INVITE? Isn't that the purpose of forking? Should 8.2.2.2 be modified as: ... If request URI, the From tag, Call-ID, and CSeq exactly match ... ^^^^^^^^^^^^ Regards, Shan Lu sentitO Networks _______________________________________________ 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 From sip-bounces@ietf.org Wed Sep 29 19:43:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02818 for ; Wed, 29 Sep 2004 19:43:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCoF2-0006Np-QI for sip-web-archive@ietf.org; Wed, 29 Sep 2004 19:52:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnrI-0002zv-PA; Wed, 29 Sep 2004 19:27:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnL2-000150-Np for sip@megatron.ietf.org; Wed, 29 Sep 2004 18:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28131 for ; Wed, 29 Sep 2004 18:54:17 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCnTA-0005D0-5Z for sip@ietf.org; Wed, 29 Sep 2004 19:02:44 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i8TMrkPm019842 for ; Wed, 29 Sep 2004 22:53:46 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Sep 2004 18:53:46 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41F8@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Wed, 29 Sep 2004 18:53:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a As promised, I've released a new version of the SIP identity draft that removes all text relating to response identity - and as such, there's no more talk in the draft about restricting retargeting or what have you. Given the many dependencies on request identity, I think it's worth getting this part done first, and then revisiting response identity at a later time. I also made a few more changes to the draft. The most obvious will be the addition of examples and a corresponding bit-exact archive of the exact messages (following the practice of Robert Sparks' torture test draft). The hope is that they will significantly increase the likelihood that the draft will be implemented. I also added new sections giving considerations on privacy and the use of telephone numbers as identities. There are also some subtler changes to the mechanism itself to address a few lingering threats. I think that the draft is in a fairly mature state now, and I solicited a number of detailed reviews that were factored into this version. I'd appreciate it if interested parties could give it a read. Thanks, Jon Peterson NeuStar, Inc. _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 30 00:13:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21928 for ; Thu, 30 Sep 2004 00:13:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCsSU-0003l7-Ij for sip-web-archive@ietf.org; Thu, 30 Sep 2004 00:22:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCsJ0-0005Zm-4u; Thu, 30 Sep 2004 00:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCsGk-0004m2-01 for sip@megatron.ietf.org; Thu, 30 Sep 2004 00:10:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21738 for ; Thu, 30 Sep 2004 00:10:10 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCsOt-0003h2-Ob for sip@ietf.org; Thu, 30 Sep 2004 00:18:41 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Sep 2004 21:13:24 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8U49Vwp011004; Wed, 29 Sep 2004 21:09:32 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn1-537.cisco.com [10.21.98.25]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id VAA25105; Wed, 29 Sep 2004 21:09:31 -0700 (PDT) From: "Dan Wing" To: "Vikram Bhuskute" , Subject: RE: [Sip] draft-takeda-symmetric-nat-traversal ?? Date: Wed, 29 Sep 2004 21:09:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <415A986B.9070008@aftek.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: takeday@kmerl.com, IETF Behave Mailing List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Thanks for bringing that I-D to the group's attention. I, for one, hadn't seen it. Section 8.1 is where the meat is, and it says: ... If the port allocation rule of the other endpoint is a symmetric type, the endpoint needs either to record the source port number of an incoming packet or to predict a port number that the symmetric NAT will assign, with a MAPPED-ADDRESS obtained from the other endpoint. ... which I agree isn't a good mechanism, especially with a large NAT. It could work just fine on a small, residential NAT which isn't processing much new traffic (and thus it is, in theory, possible to guess the next port number it will assign for the next mapping). This technique is too fragile for my blood. There is a lot of other good information in this Internet Draft, though; I hope we can incorporate some of it into the BEHAVE work if the author is willing. -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Vikram Bhuskute > Sent: Wednesday, September 29, 2004 4:12 AM > To: sip@ietf.org > Subject: [Sip] draft-takeda-symmetric-nat-traversal ?? > > > Hello all, > While searching for NAT traversal solution i came across a > draft "draft-takeda-symmetric-nat-traversal-00.txt" > from url ( > http://cnscenter.future.co.kr/resource/ietf/ind-draft/draft-takeda > -symmetric-nat-traversal-00.txt) > > It proposes some solution for Symmetric NAT based on some > Prediction .....? It dosent seem reliable ... !!! > (however it gives glimps on type of Symmetric NATs ) > > Is it still a matter of further research ? or the concept is > not well accepted ? > > thanks in advance > > vikram > > _______________________________________________ > 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://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 From sip-bounces@ietf.org Thu Sep 30 01:34:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27564 for ; Thu, 30 Sep 2004 01:34:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCti3-0005CX-8A for sip-web-archive@ietf.org; Thu, 30 Sep 2004 01:42:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCtYZ-0004Lf-IN; Thu, 30 Sep 2004 01:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCtVz-0003zv-PC for sip@megatron.ietf.org; Thu, 30 Sep 2004 01:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27112 for ; Thu, 30 Sep 2004 01:30:02 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCteA-00056i-1Y for sip@ietf.org; Thu, 30 Sep 2004 01:38:31 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8U5U0RU006706 for ; Thu, 30 Sep 2004 07:30:00 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Sep 2004 07:30:00 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Sep 2004 07:30:00 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Michael Zhou'" Subject: RE: [Sip] Question on offer-answer during establishment Date: Thu, 30 Sep 2004 07:29:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Sep 2004 05:30:00.0403 (UTC) FILETIME=[87AD7A30:01C4A6AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org, "'Paul Kyzivat'" , "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi, >>At the previous SIPit we had some discussions about the >>usage of PRACK for offer/answer. The problem, as said before, >>is that there is currently no standard way to reject an offer >>received in a PRACK, because a UAS MUST answer with 200 OK, >>if the PRACK otherwise is ok, matches a reliabel provisional >>response etc. It has even been suggested that it should be >>forbidden to send SDPs (at least new offers) in PRACKs, but >>that would of course have impacts on existing nodes - >>depending on how many nodes currently support it in the first >>place, of course. >> >> >It's not mentioned in RFC 3262 how to reject an offer, but 488 (Not >Acceptable Here) might be a natural choice according to >Section 13.3.1.3 of RFC 3261, quoted below. In practice, 4xx-6xx respons to >PRACK (which contains offer) may also be considered rejection of offer. > >" > > A UAS rejecting an offer contained in an INVITE SHOULD return a 488 > (Not Acceptable Here) response. Such a response SHOULD include a > Warning header field value explaining why the offer was rejected. > >" You are right. But, at the same time the PRACK RFC says that 200 MUST be sent, and I think is also the conclusion from previous discussions on the list. I know about implementations that reject the offer by simply don't inserting an answer in the 200 OK. No, you don't have to tell me it's non-standard behaviour :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 30 01:51:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28671 for ; Thu, 30 Sep 2004 01:51:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCtyn-0005Ws-Bc for sip-web-archive@ietf.org; Thu, 30 Sep 2004 01:59:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCtkM-0007AZ-Oz; Thu, 30 Sep 2004 01:44:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCtgv-0006P5-Kw for sip@megatron.ietf.org; Thu, 30 Sep 2004 01:41:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28090 for ; Thu, 30 Sep 2004 01:41:20 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCtp6-0005MV-SR for sip@ietf.org; Thu, 30 Sep 2004 01:49:49 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8U5fJWR010316 for ; Thu, 30 Sep 2004 07:41:19 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Sep 2004 07:41:19 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Sep 2004 07:41:19 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Shan Lu'" , "'IETF SIP Mailing List'" Subject: RE: [Sip] Question on RFC3261 Merged Requests Date: Thu, 30 Sep 2004 07:41:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Sep 2004 05:41:19.0714 (UTC) FILETIME=[1C941C20:01C4A6B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hi, Interesting point. One could argue that the existing text is ok for a normal SIP phone, because there is really no idea in receiving multiple "calls" (multiple "instances" of the same forked INVITE) from the same caller (in most cases the SIP phone can handle only one call at a time anyway, no matter if the incoming INVITEs origin from the same user or different users). However, for a gateway that may not be a valid case. Even if the gateway from a SIP perspective is a single SIP endpoint there are multiple end-users behind it, so IF we want to allow "forking" into the PSTN network (or whatever is on the other side) you are correct, I think. The problem I have with merged requests is that it takes away the advantages of only using the RFC3261 Via branch cookie from transaction identification. A node compliant with RFC3261 will basically still have to use the "old" transaction mapping mechanism, in order the to the merge check... Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Shan Lu > Sent: 30. syyskuuta 2004 1:22 > To: 'IETF SIP Mailing List' > Subject: [Sip] Question on RFC3261 Merged Requests > > > Hi, > > RFC3261 has following text: > > 8.2.2.2 Merged Requests > > If the request has no tag in the To header field, the UAS core MUST > check the request against ongoing transactions. If the From tag, > Call-ID, and CSeq exactly match those associated with an ongoing > transaction, but the request does not match that transaction (based > on the matching rules in Section 17.2.3), the UAS core SHOULD > generate a 482 (Loop Detected) response and pass it to the server > transaction. > > Assume that calls to support@example.com is forked to two > phone numbers on > PSTN, say, 555-1111 and 555-2222. Further assume that there > is only one > SIP-PSTN gateway. The two INVITEs arriving at the gw are > identical except > for R-URI userinfo and top VIA branch (assuming forking proxy > is the only > proxy). > > My question is: why should GW 482 second INVITE? Isn't that > the purpose of > forking? Should 8.2.2.2 be modified as: > > ... If request URI, the From tag, Call-ID, and CSeq exactly match ... > ^^^^^^^^^^^^ > > Regards, > > Shan Lu > sentitO Networks > > > _______________________________________________ > 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://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 From sip-bounces@ietf.org Thu Sep 30 09:40:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20335 for ; Thu, 30 Sep 2004 09:40:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD1J7-0007z4-5o for sip-web-archive@ietf.org; Thu, 30 Sep 2004 09:49:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD10X-0001cN-EQ; Thu, 30 Sep 2004 09:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD0sK-0008Gh-CZ for sip@megatron.ietf.org; Thu, 30 Sep 2004 09:21:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19044 for ; Thu, 30 Sep 2004 09:21:34 -0400 (EDT) From: leo_minor@mail.goo.ne.jp Received: from cm136.mail.goo.ne.jp ([210.150.10.136] helo=mail.goo.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CD10Z-0007VQ-Ly for sip@ietf.org; Thu, 30 Sep 2004 09:30:08 -0400 Received: (qmail 27505 invoked by uid 65534); 30 Sep 2004 22:21:17 +0900 Date: 30 Sep 2004 22:21:17 +0900 Message-ID: <20040930132117.27504.qmail@mail.goo.ne.jp> To: sip@ietf.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-type: text/plain; charset=iso-2022-jp X-Original-IP: [210.136.112.93] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Sip] Re: RFC3515 Refer-To ABNF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Also in RFC and draft, there is a similar example. draft-ietf-sip-session-timer-15 Route: sips:p1.atlanta.example.com;lr RFC 3329 Route: sip:callee@domain.com _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 30 12:59:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09862 for ; Thu, 30 Sep 2004 12:59:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD4PM-00059z-Os for sip-web-archive@ietf.org; Thu, 30 Sep 2004 13:07:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD4AF-0003Su-4Y; Thu, 30 Sep 2004 12:52:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD3s2-0007By-OB for sip@megatron.ietf.org; Thu, 30 Sep 2004 12:33:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06669 for ; Thu, 30 Sep 2004 12:33:27 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD40F-0004Ea-9s for sip@ietf.org; Thu, 30 Sep 2004 12:42:04 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0I4V007014IBIF@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 Sep 2004 17:30:21 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0I4V0059Z4ES8B@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 Sep 2004 17:28:04 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Sep 2004 17:29:50 +0100 Content-return: allowed Date: Thu, 30 Sep 2004 17:29:48 +0100 From: "Elwell, John" To: "'sip@ietf.org'" Message-id: <50B1CBA96870A34799A506B2313F26670252D417@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7BIT Subject: [Sip] Proposed bug fix to RFC3261 arising from draft-elwell-sip-state-u pdate-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7BIT At the SIP meeting in San Diego, I was asked to raise on the mailing list the individual bug fixes proposed in the state-update draft, so that each can be given due scrutiny. I decided to start with RFC3261. Here only a few changes are proposed and it does not seem sensible to consider these separately, so I propose them here as a single bug fix. If we can gain consensus on those, I will follow it up with messages proposing bug fixes to the other documents (mainly RFC3311). As a result of comments by Paul Kyzivat raised on the list recently, I have modified the proposed changes slightly. In particular, I have dropped any headers that are not obviously dialog state changes, including those that might not be considered state at all (e.g., Alert-Info) and those that might be considered call state rather than dialog state (e.g., Call-Info, Subject). If anyone wants these re-instating, please say so. Proposed bug fix to RFC3261: Add the following paragraph to the end of 12 (prior to 12.1): "A dialog can also have certain other state information that can change during the lifetime of the dialog. This includes the session description (as negotiated by SDP offer/answer), information from certain other headers and information from certain other bodies. There are no examples from this RFC. However, extensions may define other headers or bodies containing information that contributes to the state of a dialog and can change during the lifetime of the dialog." Add two new paragraphs to the end of 12.2 (prior to 12.2.1): "A request, whether or not it is a target refresh request, MAY update certain other information transmitted at the time of dialog establishment. Although there are no examples in this RFC, other extensions may define headers or bodies that are appropriate for updating during a dialog. "In this RFC, the only request defined that is suitable for updating information during a dialog is re-INVITE (see section 14). Other extensions may define different requests suitable for updating information during a dialog." Add to the end of the first paragraph of 14.1: "A UAC MAY send a session description that is unchanged, if the purpose of the re-INVITE is solely for updating dialog-related information." John Elwell (john.elwell@siemens.com) _______________________________________________ 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 From sip-bounces@ietf.org Thu Sep 30 23:14:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27575 for ; Thu, 30 Sep 2004 23:14:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDE0e-0002eH-6G for sip-web-archive@ietf.org; Thu, 30 Sep 2004 23:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDDoh-00036Q-1R; Thu, 30 Sep 2004 23:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDDZC-0007uf-14 for sip@megatron.ietf.org; Thu, 30 Sep 2004 22:54:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26543 for ; Thu, 30 Sep 2004 22:54:39 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDDhX-0002J2-VJ for sip@ietf.org; Thu, 30 Sep 2004 23:03:21 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Sep 2004 19:54:45 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i912s63c010216; Thu, 30 Sep 2004 19:54:07 -0700 (PDT) Received: from cisco.com (rtp-vpn2-189.cisco.com [10.82.240.189]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALY88861; Thu, 30 Sep 2004 22:54:05 -0400 (EDT) Message-ID: <415CC6CD.6030806@cisco.com> Date: Thu, 30 Sep 2004 22:54:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Proposed bug fix to RFC3261 arising from draft-elwell-sip-state-u pdate-02 References: <50B1CBA96870A34799A506B2313F26670252D417@ntht201e> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit John, I agree with what you are trying to do. But one rather significant detail with what you propose is that I don't believe the session description (SDP) is dialog state. It is call state. (A dialog that exists for the purpose of a SUBSCRIBE would not have this.) That in some sense guts this proposal, since now there are no examples in this document of additional dialog state. However I still think the clarification is needed. In addition, 3261 sweeps the distinction between dialog state and call state under the rug. Once alternative uses of dialogs are in play it is important to make this distinction clear, and to identify those items that are part of call state. This includes the session description info (the negotiated offer and answer as well as potentially another proposed change to offer and answer). It also includes the data associated with session timer, and possibly Call-Info, Alert-Info, Subject. (Which if any of these is truly call state remains to be discussed.) Paul Elwell, John wrote: > At the SIP meeting in San Diego, I was asked to raise on the mailing list > the individual bug fixes proposed in the state-update draft, so that each > can be given due scrutiny. I decided to start with RFC3261. Here only a few > changes are proposed and it does not seem sensible to consider these > separately, so I propose them here as a single bug fix. If we can gain > consensus on those, I will follow it up with messages proposing bug fixes to > the other documents (mainly RFC3311). > > As a result of comments by Paul Kyzivat raised on the list recently, I have > modified the proposed changes slightly. In particular, I have dropped any > headers that are not obviously dialog state changes, including those that > might not be considered state at all (e.g., Alert-Info) and those that might > be considered call state rather than dialog state (e.g., Call-Info, > Subject). If anyone wants these re-instating, please say so. > > Proposed bug fix to RFC3261: > > Add the following paragraph to the end of 12 (prior to 12.1): > > "A dialog can also have certain other state information that can change > during the lifetime of the dialog. This includes the session description (as > negotiated by SDP offer/answer), information from certain other headers and > information from certain other bodies. There are no examples from this RFC. > However, extensions may define other headers or bodies containing > information that contributes to the state of a dialog and can change during > the lifetime of the dialog." > > Add two new paragraphs to the end of 12.2 (prior to 12.2.1): > > "A request, whether or not it is a target refresh request, MAY update > certain other information transmitted at the time of dialog establishment. > Although there are no examples in this RFC, other extensions may define > headers or bodies that are appropriate for updating during a dialog. > > "In this RFC, the only request defined that is suitable for updating > information during a dialog is re-INVITE (see section 14). Other extensions > may define different requests suitable for updating information during a > dialog." > > Add to the end of the first paragraph of 14.1: > > "A UAC MAY send a session description that is unchanged, if the purpose of > the re-INVITE is solely for updating dialog-related information." > > John Elwell (john.elwell@siemens.com) > > _______________________________________________ > 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://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