From mailman-bounces@ietf.org Sat Jan 1 07:34:26 2005 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 HAA15514 for ; Sat, 1 Jan 2005 07:34:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkieT-0008V6-4N for sip-web-archive@ietf.org; Sat, 01 Jan 2005 07:46:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgPV-0000B1-El for sip-web-archive@ietf.org; Sat, 01 Jan 2005 05:23:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: sip-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:08:55 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for sip-web-archive@ietf.org: List Password // URL ---- -------- sip@ietf.org toufat https://www1.ietf.org/mailman/options/sip/sip-web-archive%40ietf.org From sip-bounces@ietf.org Sun Jan 2 13:09:20 2005 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 NAA22123 for ; Sun, 2 Jan 2005 13:09:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClAMM-0007da-VX for sip-web-archive@ietf.org; Sun, 02 Jan 2005 13:21:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClA5m-0002Jm-GX; Sun, 02 Jan 2005 13:04:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClA1S-0000xT-Ol for sip@megatron.ietf.org; Sun, 02 Jan 2005 13:00:10 -0500 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 NAA21594 for ; Sun, 2 Jan 2005 13:00:07 -0500 (EST) 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 1ClADR-0007T1-4J for sip@ietf.org; Sun, 02 Jan 2005 13:12:34 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Jan 2005 11:09:55 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j02HxZjw013816; Sun, 2 Jan 2005 09:59:36 -0800 (PST) Received: from [10.0.1.5] (sjc-vpn1-218.cisco.com [10.21.96.218]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVD86776; Sun, 2 Jan 2005 09:59:34 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 02 Jan 2005 09:59:33 -0800 Subject: Re: [Sip] 3840 Device ID - SIP Capababilties From: Cullen Jennings To: , "sip@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On 12/28/04 1:40 PM, "Srini Krishnamoorthy" wrote: > > Dear All, > > Some time last year there was a discussion about Device IDs and > SIP capabilities - what was the consensus on that? > > Was a instance-id or a device-id included? Or is it addressed > in some other piece of work? I couldn't find any text in > RFC3840 (SIP Cababilities) on this subject > > Can any one help? > > Here is link to that the original discussion: > http://www1.ietf.org/mail-archive/web/sip/current/msg08369.html > > > Thanks very much The http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-02.txt draft defines +sip.instance in the contact headers. I think everyone agrees this is the way to deal with this 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 Wed Jan 5 00:20:33 2005 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 AAA26786 for ; Wed, 5 Jan 2005 00:20:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm3nY-00020s-Cp for sip-web-archive@ietf.org; Wed, 05 Jan 2005 00:33:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm3Yj-0004ot-RE; Wed, 05 Jan 2005 00:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm3WT-0003IL-8o for sip@megatron.ietf.org; Wed, 05 Jan 2005 00:15:53 -0500 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 AAA26425 for ; Wed, 5 Jan 2005 00:15:48 -0500 (EST) Received: from machine77.level3.com ([209.244.4.106] helo=scanner3.l3.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm3iY-0001tF-H3 for sip@ietf.org; Wed, 05 Jan 2005 00:28:47 -0500 Received: from scanner3.l3.com (localhost [127.0.0.1]) by localhost.l3.com (Postfix) with ESMTP id 3B67078B8E5 for ; Wed, 5 Jan 2005 05:14:51 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by scanner3.l3.com (Postfix) with SMTP id 08CCD78B800 for ; Wed, 5 Jan 2005 05:14:51 +0000 (GMT) Received: from idc1exc0002.corp.global.level3.com ([10.1.8.18]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 22:14:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Tue, 4 Jan 2005 22:14:50 -0700 Message-ID: <11FD90E74279C0489ECB6793F227C847044BFC70@idc1exc0002.corp.global.level3.com> Thread-Topic: a question on tags when INVITE is challenged Thread-Index: AcTy5XsAi9bzp435TOqNKDTkTCH4kg== From: "Wang, Jin-Gen" To: X-OriginalArrivalTime: 05 Jan 2005 05:14:50.0844 (UTC) FILETIME=[7B9B89C0:01C4F2E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Subject: [Sip] a question on tags when INVITE is challenged 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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable We are running into an inter-op problem in SIP. It involves the = interpretation of RFC 3261. Hopefully we can get some input from the = list. Here is the call flow: UAC UAS | ----- INVITE (F1) ------> | | <--- 401 (F2) ------------ | | ------ ACK (F3) ---------> | | ------ INVITE (F4) ------> | | ............................... | | <----- 200 (F5) ---------- | | ------- ACK (F6) --------> | where INVITE (F1) has no credential and INVITE (F4) has credential.=20 The vendor 1 believes INVITE (F1) and INVITE (F4) should have same From = tag and 401 (F2) and 200 (F5) should have same To tag. The following = quote from section 22.2 in RFC 3261 indicates F4 is an updated request. "When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request." It implicitly indicates that INVITE (F1) and INVITE (F4) are within the = same dialog for a same call even though the dialog is created after = INVITE (F4). The vendor 2 believes INVITE (F1) and INVITE (F4) should have different = >From tag and/or 401 (F2) and 200 (F5) should have different To tags = because of the quote from section 19.3 in RFC 3261: "When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for "hairpinning" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags." Which vendor interprets the tag requirements correctly? Thanks. Jin-Gen Wang Level3 Communications Inc. 1025 Eldorado Blvd. Broomfield, CO 80021 _______________________________________________ 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 Jan 5 01:10:32 2005 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 BAA29591 for ; Wed, 5 Jan 2005 01:10:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm4Zp-0002xq-WB for sip-web-archive@ietf.org; Wed, 05 Jan 2005 01:23:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm4K2-0001uL-49; Wed, 05 Jan 2005 01:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm4Bn-0008Ip-V6 for sip@megatron.ietf.org; Wed, 05 Jan 2005 00:58:35 -0500 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 AAA29077 for ; Wed, 5 Jan 2005 00:58:32 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm4OE-0002lL-0H for sip@ietf.org; Wed, 05 Jan 2005 01:11:32 -0500 Received: from Nataraju (bsc@[192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id j055roo14088; Wed, 5 Jan 2005 11:23:50 +0530 From: "Nataraju A B" To: "'Wang, Jin-Gen'" , Subject: RE: [Sip] a question on tags when INVITE is challenged Date: Wed, 5 Jan 2005 11:18:54 +0530 Message-ID: <000401c4f2ea$4104a8f0$7302a8c0@Nataraju> 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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <11FD90E74279C0489ECB6793F227C847044BFC70@idc1exc0002.corp.global.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Comments inline... Best Regards, Nataraju A.B. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Wang, Jin-Gen Sent: Wednesday, January 05, 2005 10:45 AM To: sip@ietf.org Subject: [Sip] a question on tags when INVITE is challenged We are running into an inter-op problem in SIP. It involves the interpretation of RFC 3261. Hopefully we can get some input from the list. Here is the call flow: UAC UAS | ----- INVITE (F1) ------> | | <--- 401 (F2) ------------ | | ------ ACK (F3) ---------> | | ------ INVITE (F4) ------> | | ............................... | | <----- 200 (F5) ---------- | | ------- ACK (F6) --------> | where INVITE (F1) has no credential and INVITE (F4) has credential. The vendor 1 believes INVITE (F1) and INVITE (F4) should have same From tag and 401 (F2) and 200 (F5) should have same To tag. The following quote from section 22.2 in RFC 3261 indicates F4 is an updated request. "When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request." It implicitly indicates that INVITE (F1) and INVITE (F4) are within the same dialog for a same call even though the dialog is created after INVITE (F4). [ABN] this might be confusing text... may needs to be modified... The vendor 2 believes INVITE (F1) and INVITE (F4) should have different >From tag and/or 401 (F2) and 200 (F5) should have different To tags because of the quote from section 19.3 in RFC 3261: "When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for "hairpinning" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags." Which vendor interprets the tag requirements correctly? [ABN] I feel the vendor 2 interprets correctly... Once the failure response received for an INVITE request and that transaction is closed the session will also be deleted since there are no other dialog exists as part of the same session. Hence the application (no the user) has to initiate a new session with new from tag to send the INVITE (F4) with challenge response... Thanks. Jin-Gen Wang Level3 Communications Inc. 1025 Eldorado Blvd. Broomfield, CO 80021 _______________________________________________ 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 Jan 5 03:30:26 2005 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 DAA12041 for ; Wed, 5 Jan 2005 03:30:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm6lI-0006J9-6K for sip-web-archive@ietf.org; Wed, 05 Jan 2005 03:43:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm6Rm-0003pt-8Z; Wed, 05 Jan 2005 03:23:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm6MZ-0002Tn-9t for sip@megatron.ietf.org; Wed, 05 Jan 2005 03:17:51 -0500 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 DAA11093 for ; Wed, 5 Jan 2005 03:17:49 -0500 (EST) Received: from web15305.mail.cnb.yahoo.com ([202.43.216.180] helo=web15305.mail.bjs.yahoo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cm6Z3-0005xm-HQ for sip@ietf.org; Wed, 05 Jan 2005 03:30:48 -0500 Message-ID: <20050105081715.14666.qmail@web15305.mail.bjs.yahoo.com> Received: from [219.150.142.155] by web15305.mail.cnb.yahoo.com via HTTP; Wed, 05 Jan 2005 16:17:15 CST Date: Wed, 5 Jan 2005 16:17:15 +0800 (CST) From: Carol Chang To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Sip] Looking forward to cooperate with you----Our company sell IPphone, ATA 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="===============2132502507==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 4.3 (++++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --===============2132502507== Content-Type: multipart/alternative; boundary="0-277676531-1104913035=:11950" --0-277676531-1104913035=:11950 Content-Type: text/plain; charset=gb2312 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA11093 Content-Transfer-Encoding: quoted-printable HI,All Friends, We take the liberty of writing to you with a view to building bussine= ss relations with your firm. We are a manufacturer of IP PHONE,ATA at= china, Our ip phone=A3=ACATA --YWH100,YWH10 and YGW10 series are well kn= own for its first-quality,good voice ,high stability ,low cost.=20 Now we have CE and FCC ,at the same time we own export liscense!=20 If you want to know more informations in details, please contact with us = or visit our website:=20 http://www.yntx.com =20 =20 Wishing you the best of business. Carol =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Contact person:Carol=20 MSN:Carol_chang8009@hotmail.com=20 Email:ync@vip.163.com=20 YahooID:Carol_chang8009=20 ICQ:200931135=20 Tel:8603717657239=20 http://www.yntx.com Zhengzhou Yuneng Communication Equipment Co.Ltd. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 --------------------------------- Do You Yahoo!? =D7=A2=B2=E1=CA=C0=BD=E7=D2=BB=C1=F7=C6=B7=D6=CA=B5=C4=D1=C5=BB=A2=C3=E2=B7= =D1=B5=E7=D3=CA --------------------------------- Do You Yahoo!? =D7=A2=B2=E1=CA=C0=BD=E7=D2=BB=C1=F7=C6=B7=D6=CA=B5=C4=D1=C5=BB=A2=C3=E2=B7= =D1=B5=E7=D3=CA --0-277676531-1104913035=:11950 Content-Type: text/html; charset=gb2312 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA11093 Content-Transfer-Encoding: quoted-printable
HI,All Friends,
    We take the liberty of writing to you with a view= to building bussiness relations with your firm.=20
    We are a manuf= acturer of IP PHONE,ATA at china, Our ip phone=A3=ACATA --YWH100,YWH10 an= d YGW10 series are well known for its first-quality,good voice ,high stab= ility ,low cost.
Now we have CE and FCC ,at the same time we own exp= ort liscense!
If you want to know more informations in details, pleas= e contact with us or visit our website:
http://www.yntx.com
 
 
Wishing you the best of business.
Carol
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Contact person:Carol
MSN:Carol_chang8009@hotmail.com
Em= ail:ync@vip.163.com
YahooID:Carol_chang8009
ICQ:200931135
Tel= :8603717657239
http://www.yntx.com
Zhengzhou Yuneng Communication Equipment Co.Ltd.
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D


Do You Yahoo!?
=D7=A2=B2=E1=CA=C0=BD=E7=D2=BB= =C1=F7=C6=B7=D6=CA=B5=C4=D1=C5=BB=A2=C3=E2=B7=D1=B5=E7=D3=CA


Do You Yahoo!?
=D7=A2=B2=E1=CA=C0=BD=E7=D2=BB=C1=F7=C6=B7=D6=CA=B5=C4= =D1=C5=BB=A2=C3=E2=B7=D1=B5=E7=D3=CA --0-277676531-1104913035=:11950-- --===============2132502507== 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 --===============2132502507==-- From sip-bounces@ietf.org Wed Jan 5 03:35:21 2005 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 DAA12551 for ; Wed, 5 Jan 2005 03:35:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm6q3-0006Ss-Gg for sip-web-archive@ietf.org; Wed, 05 Jan 2005 03:48:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm6Zi-00065Z-1m; Wed, 05 Jan 2005 03:31:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm6Rm-0003q6-It for sip@megatron.ietf.org; Wed, 05 Jan 2005 03:23:14 -0500 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 DAA11662 for ; Wed, 5 Jan 2005 03:23:12 -0500 (EST) Received: from web15305.mail.cnb.yahoo.com ([202.43.216.180] helo=web15305.mail.bjs.yahoo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cm6eI-00068l-4X for sip@ietf.org; Wed, 05 Jan 2005 03:36:12 -0500 Message-ID: <20050105082239.15248.qmail@web15305.mail.bjs.yahoo.com> Received: from [219.150.142.155] by web15305.mail.cnb.yahoo.com via HTTP; Wed, 05 Jan 2005 16:22:39 CST Date: Wed, 5 Jan 2005 16:22:39 +0800 (CST) From: Carol Chang To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 4.9 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Sip] Looking forward to cooperate with you----Our company sell IPphone, ATA 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="===============2080896664==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 4.4 (++++) X-Scan-Signature: 386e0819b1192672467565a524848168 --===============2080896664== Content-Type: multipart/alternative; boundary="0-1965184286-1104913359=:11946" --0-1965184286-1104913359=:11946 Content-Type: text/plain; charset=gb2312 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA11662 Content-Transfer-Encoding: quoted-printable HI,All Friends, We take the liberty of writing to you with a view to building bussin= ess relations with your firm. We are a manufacturer of IP PHONE,ATA = at china, Our ip phone=A3=ACATA --YWH100,YWH10 and YGW10 series are well = known for its first-quality,good voice ,high stability ,low cost.=20 Now we have CE and FCC ,at the same time we own export liscense!=20 If you want to know more informations in details, please contact with us = or visit our website:=20 http://www.yntx.com =20 =20 Wishing you the best of business. Carol =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Contact person:Carol=20 MSN:Carol_chang8009@hotmail.com=20 Email:ync@vip.163.com=20 YahooID:Carol_chang8009=20 ICQ:200931135=20 Tel:8603717657239=20 http://www.yntx.com Zhengzhou Yuneng Communication Equipment Co.Ltd. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 --------------------------------- Do You Yahoo!? =D7=A2=B2=E1=CA=C0=BD=E7=D2=BB=C1=F7=C6=B7=D6=CA=B5=C4=D1=C5=BB=A2=C3=E2=B7= =D1=B5=E7=D3=CA --0-1965184286-1104913359=:11946 Content-Type: text/html; charset=gb2312 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA11662 Content-Transfer-Encoding: quoted-printable
HI,All Friends,
     We take the liberty of writing to you with = a view to building bussiness relations with your firm.=20
     We are a= manufacturer of IP PHONE,ATA at china, Our ip phone=A3=ACATA --YWH100,YW= H10 and YGW10 series are well known for its first-quality,good voice ,hig= h stability ,low cost.
Now we have CE and FCC ,at the same time we o= wn export liscense!
If you want to know more informations in details,= please contact with us or visit our website:
http://www.yntx.com<= /FONT>
 
 
Wishing you the best of business.
Carol
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Contact person:Carol
MSN:Carol_chang8009@hotmail.com
Em= ail:ync@vip.163.com
YahooID:Carol_chang8009
ICQ:200931135
Tel= :8603717657239
http://www.yntx.com
Zhengzhou Yuneng Commu= nication Equipment Co.Ltd.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Do You Yahoo!?
=D7=A2=B2=E1=CA=C0=BD=E7=D2=BB=C1=F7=C6=B7=D6=CA=B5=C4= =D1=C5=BB=A2=C3=E2=B7=D1=B5=E7=D3=CA --0-1965184286-1104913359=:11946-- --===============2080896664== 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 --===============2080896664==-- From sip-bounces@ietf.org Wed Jan 5 10:28:31 2005 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 KAA13078 for ; Wed, 5 Jan 2005 10:28:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmDHx-0007Nl-V1 for sip-web-archive@ietf.org; Wed, 05 Jan 2005 10:41:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmD2l-0004si-JE; Wed, 05 Jan 2005 10:25:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmCxy-0002kX-Pr for sip@megatron.ietf.org; Wed, 05 Jan 2005 10:20:54 -0500 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 KAA12473 for ; Wed, 5 Jan 2005 10:20:52 -0500 (EST) Received: from web61205.mail.yahoo.com ([216.155.196.129]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmDAZ-0007CL-4L for sip@ietf.org; Wed, 05 Jan 2005 10:33:55 -0500 Received: (qmail 76713 invoked by uid 60001); 5 Jan 2005 15:20:20 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=zSYL5WJgMURdoWZ23jM4wpziXpDuWK+WaQ0lymecZpyhQoIdr4m8ltoX1iplYKQBF0SXQ3nu2CAeqHwq+OzLCHTuWzGRjBMkaEgBf+UVFO3mMJgpmocHPLqF5JFr6rVaHjlzK/BRqT3ke03PZwaT8XgMZ6OCvNExQVHtHlVTWhw= ; Message-ID: <20050105152020.76711.qmail@web61205.mail.yahoo.com> Received: from [208.45.178.5] by web61205.mail.yahoo.com via HTTP; Wed, 05 Jan 2005 07:20:20 PST Date: Wed, 5 Jan 2005 07:20:20 -0800 (PST) From: Vijay Gaur Subject: RE: [Sip] a question on tags when INVITE is challenged To: Nataraju A B , "'Wang, Jin-Gen'" , sip@ietf.org In-Reply-To: <000401c4f2ea$4104a8f0$7302a8c0@Nataraju> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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="===============0558749373==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d --===============0558749373== Content-Type: multipart/alternative; boundary="0-1862294084-1104938420=:76682" --0-1862294084-1104938420=:76682 Content-Type: text/plain; charset=us-ascii Hi Wang, Vendor1's SIP implementation should not expect same To-tag which is present in 401. There is no dialog established by 401 response. New INVITE with credentials is totaly different request. In fact few SIP implementations might send the same From tag of original INVITE. You can see similar call flows in the draft below: http://www.iptel.org/info/players/ietf/callflows/draft-ietf-sipping-basic-call-flows-02.txt Thanks, Vijay Gaur Nataraju A B wrote: Comments inline... Best Regards, Nataraju A.B. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Wang, Jin-Gen Sent: Wednesday, January 05, 2005 10:45 AM To: sip@ietf.org Subject: [Sip] a question on tags when INVITE is challenged We are running into an inter-op problem in SIP. It involves the interpretation of RFC 3261. Hopefully we can get some input from the list. Here is the call flow: UAC UAS | ----- INVITE (F1) ------> | | <--- 401 (F2) ------------ | | ------ ACK (F3) ---------> | | ------ INVITE (F4) ------> | | ............................... | | <----- 200 (F5) ---------- | | ------- ACK (F6) --------> | where INVITE (F1) has no credential and INVITE (F4) has credential. The vendor 1 believes INVITE (F1) and INVITE (F4) should have same From tag and 401 (F2) and 200 (F5) should have same To tag. The following quote from section 22.2 in RFC 3261 indicates F4 is an updated request. "When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request." It implicitly indicates that INVITE (F1) and INVITE (F4) are within the same dialog for a same call even though the dialog is created after INVITE (F4). [ABN] this might be confusing text... may needs to be modified... The vendor 2 believes INVITE (F1) and INVITE (F4) should have different >From tag and/or 401 (F2) and 200 (F5) should have different To tags because of the quote from section 19.3 in RFC 3261: "When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for "hairpinning" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags." Which vendor interprets the tag requirements correctly? [ABN] I feel the vendor 2 interprets correctly... Once the failure response received for an INVITE request and that transaction is closed the session will also be deleted since there are no other dialog exists as part of the same session. Hence the application (no the user) has to initiate a new session with new from tag to send the INVITE (F4) with challenge response... Thanks. Jin-Gen Wang Level3 Communications Inc. 1025 Eldorado Blvd. Broomfield, CO 80021 _______________________________________________ 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 Vijay Gaur It's how you deal with failure that determines how you achieve success. Au revoir, Adios, Namaste --------------------------------- Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. --0-1862294084-1104938420=:76682 Content-Type: text/html; charset=us-ascii
Hi Wang,
  Vendor1's SIP implementation should not expect same To-tag which is present in 401. There is no dialog established by 401 response. New INVITE with credentials is totaly different request. In fact few SIP implementations might send the same From tag of original INVITE.
 
You can see similar call flows in the draft below:
 
Thanks,
Vijay Gaur

Nataraju A B <bnataraju@kodiaknetworks.com> wrote:
Comments inline...

Best Regards,
Nataraju A.B.
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Wang, Jin-Gen
Sent: Wednesday, January 05, 2005 10:45 AM
To: sip@ietf.org
Subject: [Sip] a question on tags when INVITE is challenged

We are running into an inter-op problem in SIP. It involves the
interpretation of RFC 3261. Hopefully we can get some input from the
list. Here is the call flow:

UAC UAS
| ----- INVITE (F1) ------> |
| <--- 401 (F2) ------------ |
| ------ ACK (F3) ---------> |
| ------ INVITE (F4) ------> |
| ............................... |
| <----- 200 (F5) ---------- |
| ------- ACK (F6) --------> |

where INVITE (F1) has no credential and INVITE (F4) has credential.

The vendor 1 believes INVITE (F1) and INVITE (F4)! should have same From
tag and 401 (F2) and 200 (F5) should have same To tag. The following
quote from section 22.2 in RFC 3261 indicates F4 is an updated request.

"When a UAC resubmits a request with its credentials after receiving a
401 (Unauthorized) or 407 (Proxy Authentication Required) response,
it MUST increment the CSeq header field value as it would normally
when sending an updated request."

It implicitly indicates that INVITE (F1) and INVITE (F4) are within the
same dialog for a same call even though the dialog is created after
INVITE (F4).

[ABN] this might be confusing text... may needs to be modified...

The vendor 2 believes INVITE (F1) and INVITE (F4) should have different
>From tag and/or 401 (F2) and 200 (F5) should have different To tags
because of the quote from section 19.3 in RFC 3261:

"When a tag is generated by a UA for insertion into a request or
response, it MUST be globally unique and cryptographically random
with at least 32 bits of randomness. A property of this selection
requirement is that a UA will place a different tag into the From
header of an INVITE than it would place into the To header of the
response to the same INVITE. This is needed in order for a UA to
invite itself to a session, a common case for "hairpinning" of calls
in PSTN gateways. Similarly, two INVITEs for different calls will
have different From tags, and two responses for different calls will
have different To tags."

Which vendor interprets the tag requirements correctly?

[ABN] I feel the vendor 2 interprets correctly...
Once the failure response received for an INVITE request and that
transaction is closed the session will also be deleted since there are
no other dialog exists as part of the same session. Hence the
application (no the user) has to initiate a new session with new from
tag to send the INVITE (F4) with challenge response...

Thanks.

Jin-Gen Wang
Level3 Communications Inc.
1025 Eldorado Blvd.
Broomfield, CO 80021


_______________________________________________
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


Vijay Gaur
It's how you deal with failure that determines how you achieve success.
Au revoir, Adios, Namaste

Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone. --0-1862294084-1104938420=:76682-- --===============0558749373== 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 --===============0558749373==-- From sip-bounces@ietf.org Wed Jan 5 12:22:24 2005 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 MAA23435 for ; Wed, 5 Jan 2005 12:22:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmF4D-0003bT-RO for sip-web-archive@ietf.org; Wed, 05 Jan 2005 12:35:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmEpl-0000u5-Uk; Wed, 05 Jan 2005 12:20:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmEnr-0008Nb-Bb for sip@megatron.ietf.org; Wed, 05 Jan 2005 12:18:35 -0500 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 MAA23004 for ; Wed, 5 Jan 2005 12:18:32 -0500 (EST) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmF0R-0003NY-Ds for sip@ietf.org; Wed, 05 Jan 2005 12:31:37 -0500 Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id j05HIMmT075144; Wed, 5 Jan 2005 12:18:27 -0500 (EST) From: "Brett Tate" To: "'Shan Lu'" Subject: RE: [Sip] RFC 3261: 32 bit CSeq number Date: Wed, 5 Jan 2005 12:18:23 -0500 Message-ID: <000901c4f34a$90c70cb0$a601a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <00ce01c4e92b$b3fd1630$eb00000a@SAJAK> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable > But Section 8.1.1.5 does apply to in-dialog=20 > request -- for the side that acted as UAS=20 > in dialog creation.=20 >=20 > 12.2.1.1/RFC2161 >=20 > "If the local sequence number is empty,=20 > an initial value MUST be chosen using the=20 > guidelines of Section 8.1.1.5." I agree. It was discussed some within the following email if you would = like to provide comments. http://www1.ietf.org/mail-archive/web/sip/current/msg10905.html > Did I miss something? The original posting was more associated with the validity of a cseq = value between 2**31 and (2**32)-1. =20 Within the above link, it evolved into the potential issues associated = with a UAS choosing to return a 400 response when it thinks that the UAC = provided a cseq value between 2**31 and (2**32)-1 when it should not have done = so. _______________________________________________ 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 Jan 5 16:17:25 2005 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 QAA17600 for ; Wed, 5 Jan 2005 16:17:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmIjf-0005jm-NR for sip-web-archive@ietf.org; Wed, 05 Jan 2005 16:30:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmI0l-00050i-VY; Wed, 05 Jan 2005 15:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmHyl-0003yu-Of; Wed, 05 Jan 2005 15:42:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09866; Wed, 5 Jan 2005 15:42:01 -0500 (EST) Message-Id: <200501052042.PAA09866@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, 05 Jan 2005 15:42:01 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-with-norefersub-00.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: 34d35111647d654d033d58d318c0d21a --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 : Suppression of REFER Implicit Subscription Author(s) : O. Levin Filename : draft-ietf-sip-refer-with-norefersub-00.txt Pages : 13 Date : 2005-1-5 This specification defines the way to suppress an implicit subscription with REFER method in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub-00.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-refer-with-norefersub-00.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-refer-with-norefersub-00.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: <2005-1-5153205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-with-norefersub-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-with-norefersub-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-5153205.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 Thu Jan 6 09:09:52 2005 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 JAA09059 for ; Thu, 6 Jan 2005 09:09:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmYXb-00050F-Dh for sip-web-archive@ietf.org; Thu, 06 Jan 2005 09:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmYC4-0004Hr-OQ; Thu, 06 Jan 2005 09:00:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmY7z-0002vN-Ji for sip@megatron.ietf.org; Thu, 06 Jan 2005 08:56:39 -0500 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 IAA07809 for ; Thu, 6 Jan 2005 08:56:38 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmYKj-0006Ve-Kl for sip@ietf.org; Thu, 06 Jan 2005 09:09:53 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j06Du3me012410 for ; Thu, 6 Jan 2005 07:56:04 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 08:56:03 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC263@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'sip-ietf'" Date: Thu, 6 Jan 2005 08:56:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4F3F7.74CCAC7E" X-Spam-Score: 1.0 (+) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [Sip] Interpreting Missing Content-Disposition 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: 42e3ed3f10a1d8bef690f09da16f507a 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_000_01C4F3F7.74CCAC7E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F3F7.74CCAC7E" ------_=_NextPart_001_01C4F3F7.74CCAC7E Content-Type: text/plain; charset="iso-8859-1" Could someone help me interpret RFC 3261 related to the the case when the Content-Disposition header is missing from an Invite. The verbage below clearly specifies that if the handling parameter is missing from a Content disposition header, then it should be assumed that the Disposition is required. Extra-polating that, should a missing Content-Disposition header be treated as a required Disposition. Here is the snippet from RFC 3261, section 20.11 about Content Disposition. Several new "disposition-types" of the Content-Disposition header are defined by SIP. The value "session" indicates that the body part describes a session, for either calls or early (pre-call) media. The value "render" indicates that the body part should be displayed or otherwise rendered to the user. Note that the value "render" is used rather than "inline" to avoid the connotation that the MIME body is displayed as a part of the rendering of the entire message (since the MIME bodies of SIP messages oftentimes are not displayed to users). For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render". ------_=_NextPart_001_01C4F3F7.74CCAC7E Content-Type: text/html; charset="iso-8859-1" Blank
Could someone help me interpret RFC 3261 related to the the case when
the Content-Disposition header is missing from an Invite.
 
The verbage below clearly specifies that if the handling parameter is missing
from a Content disposition header, then it should be assumed that the Disposition
is required.  Extra-polating that, should a missing Content-Disposition header be
treated as a required Disposition. 
 
Here is the snippet from RFC 3261, section 20.11 about Content Disposition.
 

Several new "disposition-types" of the Content-Disposition header are

defined by SIP. The value "session" indicates that the body part

describes a session, for either calls or early (pre-call) media. The

value "render" indicates that the body part should be displayed or

otherwise rendered to the user. Note that the value "render" is used

rather than "inline" to avoid the connotation that the MIME body is

displayed as a part of the rendering of the entire message (since the

MIME bodies of SIP messages oftentimes are not displayed to users).

For backward-compatibility, if the Content-Disposition header field

is missing, the server SHOULD assume bodies of Content-Type

application/sdp are the disposition "session", while other content

types are "render".

------_=_NextPart_001_01C4F3F7.74CCAC7E-- ------_=_NextPart_000_01C4F3F7.74CCAC7E Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Blank Bkgrd.gif" Content-ID: <459554513@06012005-37a1> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------_=_NextPart_000_01C4F3F7.74CCAC7E 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_000_01C4F3F7.74CCAC7E-- From sip-bounces@ietf.org Thu Jan 6 09:18:07 2005 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 JAA09692 for ; Thu, 6 Jan 2005 09:18:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmYfa-0001Ji-95 for sip-web-archive@ietf.org; Thu, 06 Jan 2005 09:31:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmYKY-000064-Dq; Thu, 06 Jan 2005 09:09:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmYBZ-0004Cz-C1 for sip@megatron.ietf.org; Thu, 06 Jan 2005 09:00:21 -0500 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 JAA07988 for ; Thu, 6 Jan 2005 09:00:19 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmYOL-0000GB-Gb for sip@ietf.org; Thu, 06 Jan 2005 09:13:34 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j06E0IuV028590 for ; Thu, 6 Jan 2005 08:00:18 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 09:00:17 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC264@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'sip-ietf'" Date: Thu, 6 Jan 2005 09:00:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4F3F7.A66DFFF8" X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Sip] Refer-To header and Replaces option 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.5 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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_000_01C4F3F7.A66DFFF8 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F3F7.A66DFFF8" ------_=_NextPart_001_01C4F3F7.A66DFFF8 Content-Type: text/plain; charset="iso-8859-1" Dear All, Is the usage of Replaces parameter in a Refer-To header a standard usage. If it it could you please point me to the RFC that specifies the usage. Here is an example. Refer-To: ;transport=UDP?Require=replaces&Replaces=b7f4eb08d5674c5fa019ec2975173a4b4010.254.1.20 Thanks, Nagesh Shekar ------_=_NextPart_001_01C4F3F7.A66DFFF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Blank
Dear All,
 
Is the usage of Replaces = parameter in a=20 Refer-To header a standard usage. If
it it could you please point me = to the RFC=20 that specifies the usage.
 
Here is an example.
 

Refer-To:=20 <sip:650916143674820@10.254.1.20>;transport=3DUDP?Require=3D= replaces&Replaces=3Db7f4eb08d5674c5fa019ec2975173a4b4010.254.1.20

 
Thanks,
Nagesh=20 Shekar
------_=_NextPart_001_01C4F3F7.A66DFFF8-- ------_=_NextPart_000_01C4F3F7.A66DFFF8 Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Blank Bkgrd.gif" Content-ID: <995245713@06012005-37a8> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------_=_NextPart_000_01C4F3F7.A66DFFF8 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_000_01C4F3F7.A66DFFF8-- From sip-bounces@ietf.org Thu Jan 6 11:52:48 2005 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 LAA23119 for ; Thu, 6 Jan 2005 11:52:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmb5J-0003mi-2I for sip-web-archive@ietf.org; Thu, 06 Jan 2005 12:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmagp-0004kZ-1m; Thu, 06 Jan 2005 11:40:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaeZ-00049d-NS for sip@megatron.ietf.org; Thu, 06 Jan 2005 11:38:27 -0500 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 LAA21240 for ; Thu, 6 Jan 2005 11:38:24 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmarM-0004b1-NF for sip@ietf.org; Thu, 06 Jan 2005 11:51:42 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j06GOfiB013938; Thu, 6 Jan 2005 11:24:41 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jan 2005 11:21:16 -0500 Message-ID: From: Eric Burger To: "Shekar, Nagesh Soma (Shekar)** CTR **" Subject: RE: [Sip] Interpreting Missing Content-Disposition Date: Thu, 6 Jan 2005 11:21:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa No. The language is clear: "... if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render"." Answer: Yes, unless you have a good reason not to. -----Original Message----- From: Shekar, Nagesh Soma (Shekar)** CTR ** [mailto:shek@lucent.com] Sent: Thursday, January 06, 2005 8:56 AM To: 'sip-ietf' Subject: [Sip] Interpreting Missing Content-Disposition Could someone help me interpret RFC 3261 related to the the case when the Content-Disposition header is missing from an Invite. The verbage below clearly specifies that if the handling parameter is missing from a Content disposition header, then it should be assumed that the Disposition is required. Extra-polating that, should a missing Content-Disposition header be treated as a required Disposition. Here is the snippet from RFC 3261, section 20.11 about Content Disposition. Several new "disposition-types" of the Content-Disposition header are defined by SIP. The value "session" indicates that the body part describes a session, for either calls or early (pre-call) media. The value "render" indicates that the body part should be displayed or otherwise rendered to the user. Note that the value "render" is used rather than "inline" to avoid the connotation that the MIME body is displayed as a part of the rendering of the entire message (since the MIME bodies of SIP messages oftentimes are not displayed to users). For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render". _______________________________________________ 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 Jan 6 12:01:49 2005 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 MAA24197 for ; Thu, 6 Jan 2005 12:01:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmbE2-0000tV-IA for sip-web-archive@ietf.org; Thu, 06 Jan 2005 12:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmauB-0001W3-CR; Thu, 06 Jan 2005 11:54:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaoC-0007IK-Mf for sip@megatron.ietf.org; Thu, 06 Jan 2005 11:48:24 -0500 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 LAA22824 for ; Thu, 6 Jan 2005 11:48:22 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmb0z-0001j0-2V for sip@ietf.org; Thu, 06 Jan 2005 12:01:39 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j06Gln7U028187 for ; Thu, 6 Jan 2005 10:47:49 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 11:47:49 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC265@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'Eric Burger'" Subject: RE: [Sip] Interpreting Missing Content-Disposition Date: Thu, 6 Jan 2005 11:47:47 -0500 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.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Eric, Thanks for your response. The text that you indicate below talks about the default Disposition type based on the Content-Type. What I am looking for is a default Content Disposition Handling. Say for example, If a UAS receives a INVITE message with Content-Type: application/xxx and missing content disposition header missing from the INVITE. Should the Content handling be assumed as required or optional ?. In this case the Content Disposition would be session. Thanks, Shekar > -----Original Message----- > From: Eric Burger [mailto:eburger@brooktrout.com] > Sent: Thursday, January 06, 2005 11:21 AM > To: Shekar, Nagesh Soma (Shekar)** CTR ** > Cc: 'sip-ietf' > Subject: RE: [Sip] Interpreting Missing Content-Disposition > > > No. The language is clear: > "... if the Content-Disposition header field > is missing, the server SHOULD assume bodies of Content-Type > application/sdp are the disposition "session", while other content > types are "render"." > > Answer: Yes, unless you have a good reason not to. > > -----Original Message----- > From: Shekar, Nagesh Soma (Shekar)** CTR ** [mailto:shek@lucent.com] > Sent: Thursday, January 06, 2005 8:56 AM > To: 'sip-ietf' > Subject: [Sip] Interpreting Missing Content-Disposition > > > Could someone help me interpret RFC 3261 related to the the case when > the Content-Disposition header is missing from an Invite. > > The verbage below clearly specifies that if the handling parameter is > missing > from a Content disposition header, then it should be assumed that the > Disposition > is required. Extra-polating that, should a missing > Content-Disposition > header be > treated as a required Disposition. > > Here is the snippet from RFC 3261, section 20.11 about > Content Disposition. > > Several new "disposition-types" of the Content-Disposition header are > defined by SIP. The value "session" indicates that the body part > describes a session, for either calls or early (pre-call) media. The > value "render" indicates that the body part should be displayed or > otherwise rendered to the user. Note that the value "render" is used > rather than "inline" to avoid the connotation that the MIME body is > displayed as a part of the rendering of the entire message (since the > MIME bodies of SIP messages oftentimes are not displayed to users). > For backward-compatibility, if the Content-Disposition header field > is missing, the server SHOULD assume bodies of Content-Type > application/sdp are the disposition "session", while other content > types are "render". > _______________________________________________ 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 Jan 6 12:52:04 2005 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 MAA27419 for ; Thu, 6 Jan 2005 12:52:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmc0g-0005f9-CV for sip-web-archive@ietf.org; Thu, 06 Jan 2005 13:05:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmbik-0003er-W9; Thu, 06 Jan 2005 12:46:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmbiR-0003PL-2q for sip@megatron.ietf.org; Thu, 06 Jan 2005 12:46:31 -0500 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 MAA27069 for ; Thu, 6 Jan 2005 12:46:28 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmbvE-0005XC-W2 for sip@ietf.org; Thu, 06 Jan 2005 12:59:46 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2005 12:45:59 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j06HjuDX009400; Thu, 6 Jan 2005 12:45:56 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOD28551; Thu, 6 Jan 2005 12:45:55 -0500 (EST) Message-ID: <41DD7952.904@cisco.com> Date: Thu, 06 Jan 2005 12:45:54 -0500 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: "Shekar, Nagesh Soma (Shekar)** CTR **" Subject: Re: [Sip] Interpreting Missing Content-Disposition References: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC265@oh0012exch004u.cb.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: "'sip-ietf'" , "'Eric Burger'" 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: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > Eric, > > Thanks for your response. The text that you indicate below > talks about the default Disposition type based on the > Content-Type. What I am looking for is a default Content > Disposition Handling. > > Say for example, If a UAS receives a INVITE message > with > Content-Type: application/xxx > > and missing content disposition header missing from the > INVITE. Should the Content handling be assumed as > required or optional ?. In this case the Content Disposition > would be session. I disagree. The content disposition in this case would be "render" (because the content-type is not application/sdp.) I would interpret the text that eric quotes ("the server SHOULD assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render".") to mean there is a default content disposition header of form Content-Disposition: render This header then does not have a "handling" parameter, so the other rule says the default value for that is "required". Bottom line: if you want a body part to be optional, then you must include a content-disposition header that has handling=optional. Paul > Thanks, > Shekar > > >>-----Original Message----- >>From: Eric Burger [mailto:eburger@brooktrout.com] >>Sent: Thursday, January 06, 2005 11:21 AM >>To: Shekar, Nagesh Soma (Shekar)** CTR ** >>Cc: 'sip-ietf' >>Subject: RE: [Sip] Interpreting Missing Content-Disposition >> >> >>No. The language is clear: >>"... if the Content-Disposition header field >>is missing, the server SHOULD assume bodies of Content-Type >>application/sdp are the disposition "session", while other content >>types are "render"." >> >>Answer: Yes, unless you have a good reason not to. >> >>-----Original Message----- >>From: Shekar, Nagesh Soma (Shekar)** CTR ** [mailto:shek@lucent.com] >>Sent: Thursday, January 06, 2005 8:56 AM >>To: 'sip-ietf' >>Subject: [Sip] Interpreting Missing Content-Disposition >> >> >>Could someone help me interpret RFC 3261 related to the the case when >>the Content-Disposition header is missing from an Invite. >> >>The verbage below clearly specifies that if the handling parameter is >>missing >>from a Content disposition header, then it should be assumed that the >>Disposition >>is required. Extra-polating that, should a missing >>Content-Disposition >>header be >>treated as a required Disposition. >> >>Here is the snippet from RFC 3261, section 20.11 about >>Content Disposition. >> >>Several new "disposition-types" of the Content-Disposition header are >>defined by SIP. The value "session" indicates that the body part >>describes a session, for either calls or early (pre-call) media. The >>value "render" indicates that the body part should be displayed or >>otherwise rendered to the user. Note that the value "render" is used >>rather than "inline" to avoid the connotation that the MIME body is >>displayed as a part of the rendering of the entire message (since the >>MIME bodies of SIP messages oftentimes are not displayed to users). >>For backward-compatibility, if the Content-Disposition header field >>is missing, the server SHOULD assume bodies of Content-Type >>application/sdp are the disposition "session", while other content >>types are "render". >> > > > _______________________________________________ > 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 Jan 6 23:19:42 2005 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 XAA26239 for ; Thu, 6 Jan 2005 23:19:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmlo6-0003dU-20 for sip-web-archive@ietf.org; Thu, 06 Jan 2005 23:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmlVL-0003Zr-V6; Thu, 06 Jan 2005 23:13:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmlS8-0002Q6-HS for sip@megatron.ietf.org; Thu, 06 Jan 2005 23:10:21 -0500 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 XAA25815 for ; Thu, 6 Jan 2005 23:10:17 -0500 (EST) Received: from web30005.mail.mud.yahoo.com ([68.142.200.68]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cmlez-0003TN-P5 for sip@ietf.org; Thu, 06 Jan 2005 23:23:41 -0500 Received: (qmail 45944 invoked by uid 60001); 7 Jan 2005 04:09:45 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=VYZhqdgqJEAgnmFOuzLcCtyM2COwBmEve73M1gBV0Ovj9sBNOcQ9QuR4etCx9DG+CVZ8BlNsV337DTF+zhRUcE3753SNthLHWZaenj7ZngZyTtEU4nMBYBshFF7uLqxwlzo2jbiSNdcnAy2Edeze/NYH7CxaFslScpos/fnahO0= ; Message-ID: <20050107040945.45942.qmail@web30005.mail.mud.yahoo.com> Received: from [24.128.137.99] by web30005.mail.mud.yahoo.com via HTTP; Thu, 06 Jan 2005 20:09:45 PST Date: Thu, 6 Jan 2005 20:09:45 -0800 (PST) From: Vijay Gaur Subject: Re: [Sip] Interpreting Missing Content-Disposition To: "Shekar, Nagesh Soma \(Shekar\)** CTR **" , "'sip-ietf'" In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC263@oh0012exch004u.cb.lucent.com> MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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="===============0598053605==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============0598053605== Content-Type: multipart/alternative; boundary="0-471994644-1105070985=:44847" --0-471994644-1105070985=:44847 Content-Type: text/plain; charset=us-ascii Hi Shekar, This is what I interpreted from RFC 3261 and RFC 3204. RFC 3261 says that for unknown Content-Disposition and Content-Types if handling parameter is missing then assume its value as required and reject the INVITE with 415. If there is no Content-Disposition header present and Content-Type is unknown then reject INVITE with 415 message. Because for unknown message bodies application doesn't know how to deal with the body, simply rendering unknown bodies don't help. Old SIP implementation will render the bodies instead of rejecting the INVIE. Thanks, Vijay Gaur "Shekar, Nagesh Soma (Shekar)** CTR **" wrote: BODY { MARGIN-TOP: 25px; FONT-SIZE: 10pt; MARGIN-LEFT: 25px; COLOR: #000000; FONT-FAMILY: Arial, Helvetica}P.msoNormal { MARGIN-TOP: 0px; FONT-SIZE: 10pt; MARGIN-LEFT: 0px; COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"}LI.msoNormal { MARGIN-TOP: 0px; FONT-SIZE: 10pt; MARGIN-LEFT: 0px; COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"}Could someone help me interpret RFC 3261 related to the the case when the Content-Disposition header is missing from an Invite. The verbage below clearly specifies that if the handling parameter is missing from a Content disposition header, then it should be assumed that the Disposition is required. Extra-polating that, should a missing Content-Disposition header be treated as a required Disposition. Here is the snippet from RFC 3261, section 20.11 about Content Disposition. Several new "disposition-types" of the Content-Disposition header are defined by SIP. The value "session" indicates that the body part describes a session, for either calls or early (pre-call) media. The value "render" indicates that the body part should be displayed or otherwise rendered to the user. Note that the value "render" is used rather than "inline" to avoid the connotation that the MIME body is displayed as a part of the rendering of the entire message (since the MIME bodies of SIP messages oftentimes are not displayed to users). For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render". > ATTACHMENT part 2 image/gif name=Blank Bkgrd.gif _______________________________________________ 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 Vijay Gaur It's how you deal with failure that determines how you achieve success. Au revoir, Adios, Namaste __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-471994644-1105070985=:44847 Content-Type: text/html; charset=us-ascii
Hi Shekar,
  This is what I interpreted from RFC 3261 and RFC 3204.
 
   RFC 3261 says that for unknown Content-Disposition and Content-Types if handling parameter is missing then assume its value as required and reject the INVITE with 415. If there is no Content-Disposition header present and Content-Type is unknown then reject INVITE with 415 message. Because for unknown message bodies application doesn't know how to deal with the body, simply rendering unknown bodies don't help.
 
Old SIP implementation will render the bodies instead of rejecting the INVIE.
 
Thanks,
Vijay Gaur

"Shekar, Nagesh Soma (Shekar)** CTR **" <shek@lucent.com> wrote:
Could someone help me interpret RFC 3261 related to the the case when
the Content-Disposition header is missing from an Invite.
 
The verbage below clearly specifies that if the handling parameter is missing
from a Content disposition header, then it should be assumed that the Disposition
is required.  Extra-polating that, should a missing Content-Disposition header be
treated as a required Disposition. 
 
Here is the snippet from RFC 3261, section 20.11 about Content Disposition.
 

Several new "disposition-types" of the Content-Disposition header are

defined by SIP. The value "session" indicates that the body part

describes a session, for either calls or early (pre-call) media. The

value "render" indicates that the body part should be displayed or

otherwise rendered to the user. Note that the value "render" is used

rather than "inline" to avoid the connotation that the MIME body is

displayed as a part of the rendering of the entire message (since the

MIME bodies of SIP messages oftentimes are not displayed to users).

For backward-compatibility, if the Content-Disposition header field

is missing, the server SHOULD assume bodies of Content-Type

application/sdp are the disposition "session", while other content

types are "render".



> ATTACHMENT part 2 image/gif name=Blank Bkgrd.gif
_______________________________________________
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


Vijay Gaur
It's how you deal with failure that determines how you achieve success.
Au revoir, Adios, Namaste

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-471994644-1105070985=:44847-- --===============0598053605== 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 --===============0598053605==-- From sip-bounces@ietf.org Thu Jan 6 23:45:01 2005 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 XAA28139 for ; Thu, 6 Jan 2005 23:45:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmmCc-0004nV-AR for sip-web-archive@ietf.org; Thu, 06 Jan 2005 23:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmlvP-0001GC-1W; Thu, 06 Jan 2005 23:40:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmlsJ-0007fk-2f for sip@megatron.ietf.org; Thu, 06 Jan 2005 23:37:23 -0500 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 XAA27629 for ; Thu, 6 Jan 2005 23:37:20 -0500 (EST) Received: from web30007.mail.mud.yahoo.com ([68.142.200.70]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cmm5A-0004CK-K0 for sip@ietf.org; Thu, 06 Jan 2005 23:50:44 -0500 Received: (qmail 19830 invoked by uid 60001); 7 Jan 2005 04:36:48 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=wN7ZEk1Oe1kMZJmieSLxigBuHx/HBv8YHcZq2ZDFpFu2RL/foy+/mMlazmVhc3soWwjl8T6JbwQooKtRFFaNrLXoyDOX+SHyXEkBsAAiuHqImQqm5yipOnUz2WcRVGJDYaMd9FkLXY26zHaFdA4GwXz7ZN/gcjVk2bHPtUKDh/o= ; Message-ID: <20050107043648.19828.qmail@web30007.mail.mud.yahoo.com> Received: from [208.45.178.5] by web30007.mail.mud.yahoo.com via HTTP; Thu, 06 Jan 2005 20:36:48 PST Date: Thu, 6 Jan 2005 20:36:48 -0800 (PST) From: Vijay Gaur Subject: Re: [Sip] Refer-To header and Replaces option To: "Shekar, Nagesh Soma \(Shekar\)** CTR **" , "'sip-ietf'" In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC264@oh0012exch004u.cb.lucent.com> MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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="===============0634738004==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============0634738004== Content-Type: multipart/alternative; boundary="0-1800098121-1105072608=:18461" --0-1800098121-1105072608=:18461 Content-Type: text/plain; charset=us-ascii Hi Shekar, In different call transfer scenarios like Attended, call park Replaces parameter is used in Refer-To header. You can refer draft for the usage of Replaces parameter: http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-07.txt Thanks, Vijay "Shekar, Nagesh Soma (Shekar)** CTR **" wrote: BODY { MARGIN-TOP: 25px; FONT-SIZE: 10pt; MARGIN-LEFT: 25px; COLOR: #000000; FONT-FAMILY: Arial, Helvetica}P.msoNormal { MARGIN-TOP: 0px; FONT-SIZE: 10pt; MARGIN-LEFT: 0px; COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"}LI.msoNormal { MARGIN-TOP: 0px; FONT-SIZE: 10pt; MARGIN-LEFT: 0px; COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"}Dear All, Is the usage of Replaces parameter in a Refer-To header a standard usage. If it it could you please point me to the RFC that specifies the usage. Here is an example. Refer-To: ;transport=UDP?Require=replaces&Replaces=b7f4eb08d5674c5fa019ec2975173a4b4010.254.1.20 Thanks, Nagesh Shekar > ATTACHMENT part 2 image/gif name=Blank Bkgrd.gif _______________________________________________ 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 Vijay Gaur It's how you deal with failure that determines how you achieve success. Au revoir, Adios, Namaste --------------------------------- Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. --0-1800098121-1105072608=:18461 Content-Type: text/html; charset=us-ascii

Hi Shekar,
  In different call transfer scenarios like Attended, call park Replaces parameter is used in Refer-To header.
  You can refer draft for the usage of Replaces parameter:
 
Thanks,
Vijay

"Shekar, Nagesh Soma (Shekar)** CTR **" <shek@lucent.com> wrote:
Dear All,
 
Is the usage of Replaces parameter in a Refer-To header a standard usage. If
it it could you please point me to the RFC that specifies the usage.
 
Here is an example.
 

Refer-To: <sip:650916143674820@10.254.1.20>;transport=UDP?Require=replaces&Replaces=b7f4eb08d5674c5fa019ec2975173a4b4010.254.1.20

 
Thanks,
Nagesh Shekar


> ATTACHMENT part 2 image/gif name=Blank Bkgrd.gif
_______________________________________________
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


Vijay Gaur
It's how you deal with failure that determines how you achieve success.
Au revoir, Adios, Namaste

Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses. --0-1800098121-1105072608=:18461-- --===============0634738004== 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 --===============0634738004==-- From sip-bounces@ietf.org Fri Jan 7 02:44:00 2005 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 CAA22444 for ; Fri, 7 Jan 2005 02:44:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmozs-0006Iw-2L for sip-web-archive@ietf.org; Fri, 07 Jan 2005 02:57:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmoe9-0007vn-Fb; Fri, 07 Jan 2005 02:34:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmoaS-00068p-0o for sip@megatron.ietf.org; Fri, 07 Jan 2005 02:31:08 -0500 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 CAA21038 for ; Fri, 7 Jan 2005 02:31:04 -0500 (EST) Received: from [61.95.205.153] (helo=cellcloud.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmonH-0005oy-S1 for sip@ietf.org; Fri, 07 Jan 2005 02:44:28 -0500 Received: from [172.16.3.94] (helo=GirishPai) by cellcloud.com with smtp (Exim 3.22 #6) id 1CmoLy-00037m-00; Fri, 07 Jan 2005 12:46:10 +0530 Message-ID: <3a8701c4f426$754a8890$5e0310ac@btslblr> From: "girish" To: , "'sip-ietf'" Date: Fri, 7 Jan 2005 01:02:28 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] Invite Headrs 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="===============1969829674==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. --===============1969829674== Content-Type: multipart/alternative; boundary="----=_NextPart_000_3A84_01C4F454.8EF94EB0" This is a multi-part message in MIME format. ------=_NextPart_000_3A84_01C4F454.8EF94EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI, To establish a Pre established session , a INVITE has to be sent to = the UAS .=20 What would be the TO and From header of the INVITE Message? Will = they be the same ? Girish Pai Bharti Telesoft Intl. Pvt. Ltd. Bangalore ------=_NextPart_000_3A84_01C4F454.8EF94EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI,
   To establish a Pre established session , a INVITE has = to be=20 sent to the UAS .
    What would be the TO and From header of the = INVITE=20 Message? Will they be the same ?
 
 
 
Girish Pai
Bharti Telesoft Intl. Pvt. Ltd.
Bangalore
 
------=_NextPart_000_3A84_01C4F454.8EF94EB0-- --===============1969829674== 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 --===============1969829674==-- From sip-bounces@ietf.org Fri Jan 7 05:10:27 2005 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 FAA01246 for ; Fri, 7 Jan 2005 05:10:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmrHd-00008C-LO for sip-web-archive@ietf.org; Fri, 07 Jan 2005 05:23:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmr0R-00075l-2F; Fri, 07 Jan 2005 05:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmqym-0005lN-La for sip@megatron.ietf.org; Fri, 07 Jan 2005 05:04:24 -0500 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 FAA00928 for ; Fri, 7 Jan 2005 05:04:22 -0500 (EST) Received: from smtp14.clb.oleane.net ([213.56.31.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmrBk-00081s-C7 for sip@ietf.org; Fri, 07 Jan 2005 05:17:48 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp14.clb.oleane.net with ESMTP id j07A3qLr004379 for ; Fri, 7 Jan 2005 11:03:53 +0100 Message-Id: <200501071003.j07A3qLr004379@smtp14.clb.oleane.net> From: "gunther" To: Date: Fri, 7 Jan 2005 11:03:49 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT0oC6hK4b8Db3SR2KNRtNiyjigRA== X-Spam-Score: 0.2 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [Sip] WiFi Voice Conference - Paris - France 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="===============0683950329==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This is a multi-part message in MIME format. --===============0683950329== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C4F4A8.90DD1EB0" This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C4F4A8.90DD1EB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The second edition of the WiFi Voice Conference will stand in Paris on 10 to 13 May, 2005. - What about the standardization process and the regulatory issues? - What are the market drivers for VoWLAN? - How will VoWLAN systems prioritize and deliver data packets? - What are the planning and engineering issues? - What about security and privacy? Distinguished experts and key players in the field will address these questions with detailed and technical explanations. Get details at: http://www.upperside.fr/wifi05/wifivoice2005intro.htm ------=_NextPart_000_0058_01C4F4A8.90DD1EB0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The second edition of the WiFi Voice = Conference will stand in Paris on 10 to 13 May, 2005. =

 

- What about the standardization process and = the regulatory issues?
- What are the market drivers for VoWLAN?
- How will VoWLAN systems prioritize and deliver data packets?
- What are the planning and engineering issues? 
- What about security and privacy? 

Distinguished experts and key players in the field will address these = questions with detailed and technical explanations.

Get details = at:

http://www.upperside.fr/wifi05/wifivoice2005intro.htm=

 

------=_NextPart_000_0058_01C4F4A8.90DD1EB0-- --===============0683950329== 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 --===============0683950329==-- From sip-bounces@ietf.org Fri Jan 7 19:44:11 2005 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 TAA11844 for ; Fri, 7 Jan 2005 19:44:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn4vH-0002JR-Gf for sip-web-archive@ietf.org; Fri, 07 Jan 2005 19:57:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn4g5-0001RP-KX; Fri, 07 Jan 2005 19:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn4YC-0008Iq-BH for sip@megatron.ietf.org; Fri, 07 Jan 2005 19:33:53 -0500 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 TAA11501 for ; Fri, 7 Jan 2005 19:33:49 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn4lF-0001jO-8n for sip@ietf.org; Fri, 07 Jan 2005 19:47:24 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id j080Yod7025390 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 7 Jan 2005 18:34:51 -0600 In-Reply-To: <3a8701c4f426$754a8890$5e0310ac@btslblr> References: <3a8701c4f426$754a8890$5e0310ac@btslblr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/mixed; boundary=Apple-Mail-20-135677000 Message-Id: From: Dean Willis Subject: Re: [Sip] Invite Headrs Date: Fri, 7 Jan 2005 18:33:32 -0600 To: "girish" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 Cc: "'sip-ietf'" , sip@vovida.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: 56904003e9d74831849863e83b1962ec --Apple-Mail-20-135677000 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable WARNING: LONG Normally, I wouldn't respond to something like this here, but would =20 refer it to the sip-implementors list. However, this does pose a =20 reasonable example for running down SIP details across the multiple =20 bodies developing specifications related to SIP. Consequently, I'll =20 give a long-winded, rambling, and potentially pointless discussion of =20= how one might try to run this sort of question down. Perhaps somebody =20= can suggest a more direct route . . . On Jan 6, 2005, at 1:32 PM, girish wrote: > HI, > =A0=A0 To establish a Pre established session , a INVITE has to be = sent to =20 > the UAS . > =A0=A0=A0 What would be the TO and =46rom header of the INVITE = Message? Will =20 > they be the same ? > What difference does it make, and why? "Pre Established Session", as I understand it, is an OMA POC =20 optimization technique wherein a POC client maintains a long-lived =20 dialog with a POC application server, and that POC application server =20= acts a B2BUA to bridge the long-lived dialog together with short-lived =20= dialogs created dynamically between the POC application server and =20 other network elements. Since the To and =46rom of the INVITE that establishes the long-lived =20= dialog is only seen by the POC application server, it may not matter a =20= whole lot what goes in there. However, assuming we use a "POC as conferencing" design model, which =20 then envisions the POC application server as a sort of specialized =20 conference bridge, it would seem reasonable to populate To: with the =20 identity of the POC application server or service provider, and From: =20= with the AOR of the user sending that INVITE. This would facilitate =20 reuse of the From: field by the POC Application Server in the =20 establishment of further short-lived dialogs. But assuming we're taking about "pre established sessions" in the OMA =20= POC sense, we should observe that what goes into To: and From: isn't =20 really in the domain of the IETF. Rather, OMA specifications are likely =20= to describe what they expect here, and unless they need some guidance =20= on the matter from IETF (whether they know it or not) we generally =20 don't have a lot to say about their specifications. If you're interested, the POC working group of OMA has some of their =20 working documents categorized as "public" and they can be retrieved =20 from the OMA web site at: http://member.openmobilealliance.org/ftp/public_documents/POC/=20 Permanent_documents/ Note: The page at =20 http://www.openmobilealliance.org/tech/wg_committees/poc.html makes a =20= lot more sense as a starting point. The Architecture, Control plane, and User Plane documents may be of =20 interest: see: OMA-AD-PoC-V1_0-20041117-D.zip OMA-CP-POC-V1_0-20041111-D.zip OMA-UP-PoC-V1_0-20041005-D.zip And in: OMA-TS-PoC_ControlPlane-V1_0-20041117-D.zip I found: -------------- 6.1.3.2.1 PoC Client initiates a Pre-established Session Upon receiving a requestfrom a PoC User to initiate a Pre-established =20= Session the PoC Client: -=A0=A0=A0=A0=A0=A0=A01.=A0SHALL generate an initial SIP INVITE request = as specified in =20 subclause 6.1.3.1 "General"; -=A0=A0=A0=A0=A0=A0=A02.=A0SHALL set the Request-URI of the SIP INVITE = request to the =20 Conference-factory-URI for the PoC Service in the Home PoC Network of =20= the PoC User; -=A0=A0=A0=A0=A0=A0=A03.=A0SHALL include a MIME SDP body as a SDP offer = according to =20 rules and procedures of [RFC3264] and [RFC2327] as follows; a)=A0=A0=A0set the IP address and the port number for the RTP Session b)=A0=A0set the supported codecs of the PoC Client c)=A0=A0if another IP address or port number is used instead of the = default =20 IP address and port number specified by [RFC3550], set the IP address =20= and port number for the RTCP Session at the PoC Clientaccording to =20 rules and procedures of=A0[RFC3605]; d) set the offered Talk Burst Control Protocol and the port number(s) =20= for the Talk Burst Control Protocol e) if the PoC Client is not able/willing to receive media streams =20 immediately then the PoC Client SHALL set the media to "'inactive"' as =20= specified in [RFC3108] when generating the SDP offer; -=A0=A0=A0=A0=A0=A0=A05.=A0SHALL send the SIP INVITE request towards the = PoC Server =20 according torules andprocedures of the SIP/IP core. Upon receiving a SIP 200 "OK" response to the SIP INVITE request the =20 PoC Client: -=A0=A0=A0=A0=A0=A0=A01.=A0SHALL store the content of the received = Contact header as =20 the PoC Session Identity -=A0=A0=A0=A0=A0=A0=A02.=A0SHALL interact with the User Plane as = specified in =20 [OMA-PoC-UP] "PoC Client procedure at Pre-established Session =20 initialization". When the SIP/IP Core corresponds with 3GPP/3GPP2 IMS, the PoC Client =20 SHALL use 3GPP/3GPP2 IMS Session establishment mechanisms according to =20= rules and procedures of=A0[TS24.229] / [3GPP2X.S0013.4]with the =20 clarifications given in this subclause. -------------- Noting that this refers to 6.1.3.1, we look there and see: -------------- --Apple-Mail-20-135677000 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable 6.1.3.1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0General The PoC Client SHALL generate an initial SIP INVITE request according=20 to rules and procedures of=A0[RFC3261].=A0The PoC Client -=A0=A0=A0=A0=A0=A0=A01. SHALL include an Accept-Contact header with the = Poc=20 feature-tag '+g.poc.talkburst' along with =91require=92 and =91explicit=92= =20 parameters according to the rules and procedures of=A0[RFC 3841]in all=20= initial SIP INVITE requests. -=A0=A0=A0=A0=A0=A0=A02. SHALL include User-Agent header to indicate the = PoC release=20 version. -=A0=A0=A0=A0=A0=A0=A03. SHALL include value ''id'' in a Privacy header = if anonymity=20 is requested according to rules and procedures of [RFC3325]. NOTE 1:=A0=A0If anonymity is not allowed for the PoC Group indicated = with=20 the Request-URI of the SIP INVITE based on the rules specified in the=20 [POC XDM Specification] the PoC Session will not be allowed by the PoC=20= server hosting the PoC Group. -=A0=A0=A0=A0=A0=A0=A04. SHALL include the feature tag = '+g.poc.talkburst' in the=20 Contact header. -=A0=A0=A0=A0=A0=A0=A05. SHALL include the option tag 'timer' in the = Supported header. -=A0=A0=A0=A0=A0=A0=A06. SHOULD include an Allow header with all = supported SIP=20 methods. -=A0=A0=A0=A0=A0=A0=A07. SHOULD include the Session-Expires header with = the refresher=20 parameter set to ''uac''according to rules and procedures=20 of[draft-ietf-sip-session-timer]. NOTE:=A0=A0The use of the option tag 'precondition', as specified in=20 [RFC3312], and the option tag '100rel', specified in [RFC3262], is not=20= defined for POC-1 reference point. On receipt of a final response to the SIP INVITE request, the PoC=20 Client SHALLstore the list of SIP methods that the PoC Server=20 supportsif received in the Allow header. On receipt of the SIP 200 "OK" response to the initial SIP INVITE=20 request the PoC Client SHALL start the SIP Session timer usingthe value=20= received in the Session-Expires headeraccording to rules and procedures=20= of[draft-ietf-sip-session-timer]. When the SIP/IP Core corresponds with 3GPP/3GPP2 IMS, the PoC Client=20 SHALL use 3GPP/3GPP2 IMS Session establishment mechanisms according to=20= rules and procedures of=A0[TS24.229] / [3GPP2X.S0013.4]with the=20 clarifications given in this subclause. -------------- So, in the final analysis, OMA doesn't seem to say anything direct=20 about populating the To: and From: fields of an INVITE intended to=20 establish a "pre-established session". Instead, they defer to the rules=20= of the "SIP/IP Core", referencing 3GPP's TS 24.229, which one can see=20 at: http://www.3gpp.org/ftp/Specs/html-info/24229.htm Note that this reference is not normative unless one happens to be=20 running POC on IMS. Looking at 24.229, we find in=20= --Apple-Mail-20-135677000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 5.1.2A=A0=A0=A0"Generic procedures applicable to all methods excluding = the=20 REGISTER method": ----------- Where privacy is required, in any initial request for a dialog or=20 request for a standalone transaction, the UE shall set the =46rom header=20= to "Anonymous". NOTE=A04:=A0=A0=A0=A0=A0=A0=A0=A0The contents of the =46rom header = should not be relied=20 upon to be modified by the network based on any privacy specified by=20 the user either within the UE indication of privacy or by network=20 subscription or network policy. Therefore the user should include the=20 value "Anonymous" whenever privacy is explicitly required.As the user=20 may well have privacy requirements, terminal manufacturers should not=20 automatically derive and include values in this header from the public=20= user identity or other values stored in or derived from the UICC. Where=20= the user has not expressed a preference in the configuration of the=20 terminal implementation, the implementation should assume that privacy=20= is required. Users that require to identify themselves, and are making=20= calls to SIP destinations beyond the IM CN subsystem, where the=20 destination does not implement RFC=A03325=A0[34], will need to include a=20= value in the =46rom header other than Anonymous. ------------ 24.229, as far as I can tell, says little about the From: header field,=20= and almost nothing about the From: header field needed for IMS. So, the=20= reference from the OMA document seems a little spurious. Digging=20 deeper, we find that there are examples in 24.228. Unfortunately,=20 although they discuss the use of the user's requested public identity=20 in From: fields, these example do little to illuminate the use of the=20 To: field (generally using a Tel: URL). Now, since I vaguely recall=20 from years of working with 3GPP that 24.x specs are "stage 3" based on=20= the 23.x stage 2 specs, I decided to fall back to stage 2 and see if=20 there is anything helpful. In 23.228, we find something useful: -------------- --Apple-Mail-20-135677000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 4.3.3=A0=A0=A0Identification of users There are various identities that may be associated with a user of IP=20 multimedia services. This section describes these identities and their=20= use. --Apple-Mail-20-135677000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 4.3.3.1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Private user identities --Apple-Mail-20-135677000 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Every IM CN subsystem user shall have one or more private user=20 identities. The private identity is assigned by the home network=20 operator, and used, for example, for Registration, Authorisation,=20 Administration, and Accounting purposes. This identity shall take the=20 form of a Network Access Identifier (NAI) as defined in RFC 2486 [14].=20= It is possible for a representation of the IMSI to be contained within=20= the NAI for the private identity. -=A0=A0The Private User Identity is not used for routing of SIP = messages. -=A0=A0The Private User Identity shall be contained in all Registration=20= requests, (including Re-registration and De-registration requests)=20 passed from the UE to the home network. -=A0=A0An ISIM application shall securely store one Private User = Identity.=20 It shall not be possible for the UE to modify the Private User Identity=20= information stored on the ISIM application. -=A0=A0The Private User Identity is a unique global identity defined by = the=20 Home Network Operator, which may be used within the home network to=20 uniquely identify the user from a network perspective. -=A0=A0The Private User Identity shall be permanently allocated to a = user=20 (it is not a dynamic identity), and is valid for the duration of the=20 user=92s subscription with the home network. -=A0=A0The Private User Identity is used to identify the user=92s = information=20 (for example authentication information) stored within the HSS (for use=20= for example during Registration). -=A0=A0The Private User Identity may be present in charging records = based=20 on operator policies. -=A0=A0The Private User Identity identifies the subscription (e.g. IM=20 service capability) not the user. -=A0=A0The Private User Identity is authenticated only during = registration=20 of the user, (including re-registration and de-registration). -=A0=A0The HSS needs to store the Private User Identity. -=A0=A0The S-CSCF needs to obtain and store the Private User Identity = upon=20 registration and unregistered termination. --Apple-Mail-20-135677000 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable 4.3.3.2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Public user identities Every IM CN subsystem user shall have one or more public user=20 identities [8]. The public user identity/identities are used by any=20 user for requesting communications to other users. For example, this=20 might be included on a business card. -=A0=A0Both telecom numbering and Internet naming schemes can be used to=20= address users depending on the Public User identities that the users=20 have. -=A0=A0The public user identity/identities shall take the form of SIP = URL=20 (as defined in RFC 3261 [12] and RFC2396 [13]) or the "tel:"-URL format=20= [15]. -=A0=A0An ISIM application shall securely store at least one Public User=20= Identity (it shall not be possible for the UE to modify the Public User=20= Identity), but it is not required that all additional Public User=20 Identities be stored on the ISIM application. -=A0=A0=A0=A0=A0=A0=A0A Public User Identity shall be registered either = explicitly or=20 implicitly before the identity can be used to originate IMS sessions=20 and IMS session unrelated procedures. -=A0=A0=A0=A0=A0=A0=A0A Public User Identity shall be registered either = explicitly or=20 implicitly before terminating IMS sessions and terminating IMS session=20= unrelated procedures can be delivered to the UE of the user that the=20 Public User Identity belongs to. Subscriber-specific services for=20 unregistered users may nevertheless be executed as described in chapter=20= 5.12. -=A0=A0It shall be possible to register globally (i.e. through one = single=20 UE request) a user that has more than one public identity via a=20 mechanism within the IP multimedia CN subsystem (e.g. by using an=20 Implicit Registration Set). This shall not preclude the user from=20 registering individually some of his/her public identities if needed. -=A0=A0Public User Identities are not authenticated by the network = during=20 registration. -=A0=A0Public User Identities may be used to identify the user=92s=20 information within the HSS (for example during mobile terminated=20 session set-up). -------------- So, from this we learn that the From: should be populated (if we aren't=20= requesting anonymity) with a sip: or tel: URL and display name string=20 corresponding to a public identity of the requesting user. And if we=20 ARE requesting anonymity (which doesn't seem all that useful in this=20 context), we set it to "Anonymous". I'm not at all sure why some people think figuring this stuff out is=20 easy. After all, I've only been working with this stuff for about six=20 years, and I was able to address this basic question with only an hour=20= or so of research, And I still don't know what goes in the To:. But I suspect it doesn't=20 really matter very much. -- Dean --Apple-Mail-20-135677000 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 --Apple-Mail-20-135677000-- From sip-bounces@ietf.org Mon Jan 10 07:44:33 2005 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 HAA14692 for ; Mon, 10 Jan 2005 07:44:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnz82-0007Hv-A1 for sip-web-archive@ietf.org; Mon, 10 Jan 2005 07:58:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnyt3-0005Po-7I; Mon, 10 Jan 2005 07:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnysK-0005GJ-Kx for sip@megatron.ietf.org; Mon, 10 Jan 2005 07:42:24 -0500 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 HAA14609 for ; Mon, 10 Jan 2005 07:42:23 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnz5v-0007D2-Qf for sip@ietf.org; Mon, 10 Jan 2005 07:56:28 -0500 Received: by rproxy.gmail.com with SMTP id r35so837666rna for ; Mon, 10 Jan 2005 04:42:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=R6Ps/qudPdoAIka68Cwb8QK7L398ZsVu314SGtxO6BZ95uuNemCBXPEwWtNYmeWEg5IODdEZ3w9x/GDUzx5T9H8mAoytyxx3xiBO/9FukaIcro9MeawkSguWFZ8I4S6aLXRWfjYgrW5H4OvXNx5Gc/59oQJ7uAXlKnACcjuXG2A= Received: by 10.38.13.52 with SMTP id 52mr246939rnm; Mon, 10 Jan 2005 04:42:17 -0800 (PST) Received: by 10.38.74.74 with HTTP; Mon, 10 Jan 2005 04:42:17 -0800 (PST) Message-ID: <6e749dc6050110044265861b63@mail.gmail.com> Date: Mon, 10 Jan 2005 18:12:17 +0530 From: Aby K Samuel To: sip@ietf.org Subject: RE: [Sip] a question on tags when INVITE is challenged In-Reply-To: <2250692434406070456@unknownmsgid> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2250692434406070456@unknownmsgid> 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 Reply-To: Aby K Samuel 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 Can someone tell me how having the same tag in the From fields of INVITE(F1) and INVITE(F4), affect a call ?? > > Message: 5 > Date: Wed, 5 Jan 2005 07:20:20 -0800 (PST) > From: Vijay Gaur > Subject: RE: [Sip] a question on tags when INVITE is challenged > To: Nataraju A B , "'Wang, Jin-Gen'" > , sip@ietf.org > Message-ID: <20050105152020.76711.qmail@web61205.mail.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Wang, > Vendor1's SIP implementation should not expect same To-tag which is present in 401. There is no dialog established by 401 response. New INVITE with credentials is totaly different request. In fact few SIP implementations might send the same From tag of original INVITE. > > You can see similar call flows in the draft below: > http://www.iptel.org/info/players/ietf/callflows/draft-ietf-sipping-basic-call-flows-02.txt > > Thanks, > Vijay Gaur > > Nataraju A B wrote: > Comments inline... > > Best Regards, > Nataraju A.B. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Wang, Jin-Gen > Sent: Wednesday, January 05, 2005 10:45 AM > To: sip@ietf.org > Subject: [Sip] a question on tags when INVITE is challenged > > We are running into an inter-op problem in SIP. It involves the > interpretation of RFC 3261. Hopefully we can get some input from the > list. Here is the call flow: > > UAC UAS > | ----- INVITE (F1) ------> | > | <--- 401 (F2) ------------ | > | ------ ACK (F3) ---------> | > | ------ INVITE (F4) ------> | > | ............................... | > | <----- 200 (F5) ---------- | > | ------- ACK (F6) --------> | > > where INVITE (F1) has no credential and INVITE (F4) has credential. > > The vendor 1 believes INVITE (F1) and INVITE (F4) should have same From > tag and 401 (F2) and 200 (F5) should have same To tag. The following > quote from section 22.2 in RFC 3261 indicates F4 is an updated request. > > "When a UAC resubmits a request with its credentials after receiving a > 401 (Unauthorized) or 407 (Proxy Authentication Required) response, > it MUST increment the CSeq header field value as it would normally > when sending an updated request." > > It implicitly indicates that INVITE (F1) and INVITE (F4) are within the > same dialog for a same call even though the dialog is created after > INVITE (F4). > > [ABN] this might be confusing text... may needs to be modified... > > The vendor 2 believes INVITE (F1) and INVITE (F4) should have different > >From tag and/or 401 (F2) and 200 (F5) should have different To tags > because of the quote from section 19.3 in RFC 3261: > > "When a tag is generated by a UA for insertion into a request or > response, it MUST be globally unique and cryptographically random > with at least 32 bits of randomness. A property of this selection > requirement is that a UA will place a different tag into the From > header of an INVITE than it would place into the To header of the > response to the same INVITE. This is needed in order for a UA to > invite itself to a session, a common case for "hairpinning" of calls > in PSTN gateways. Similarly, two INVITEs for different calls will > have different From tags, and two responses for different calls will > have different To tags." > > Which vendor interprets the tag requirements correctly? > > [ABN] I feel the vendor 2 interprets correctly... > Once the failure response received for an INVITE request and that > transaction is closed the session will also be deleted since there are > no other dialog exists as part of the same session. Hence the > application (no the user) has to initiate a new session with new from > tag to send the INVITE (F4) with challenge response... > > Thanks. > > Jin-Gen Wang > Level3 Communications Inc. > 1025 Eldorado Blvd. > Broomfield, CO 80021 > > _______________________________________________ > 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 > > Vijay Gaur > It's how you deal with failure that determines how you achieve success. > Au revoir, Adios, Namaste > > --------------------------------- > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile phone. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www1.ietf.org/pipermail/sip/attachments/20050105/0f235b2f/attachment.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 9, Issue 2 > ********************************* > _______________________________________________ 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 Jan 10 08:16:26 2005 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 IAA16738 for ; Mon, 10 Jan 2005 08:16:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnzcq-0000F9-6E for sip-web-archive@ietf.org; Mon, 10 Jan 2005 08:30:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnzNE-000243-T2; Mon, 10 Jan 2005 08:14:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnzIc-0001FN-K4 for sip@megatron.ietf.org; Mon, 10 Jan 2005 08:09:34 -0500 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 IAA16364 for ; Mon, 10 Jan 2005 08:09:33 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnzW8-0008Om-5C for sip@ietf.org; Mon, 10 Jan 2005 08:23:38 -0500 Received: from Nataraju (egn@[192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id j0AD7po17462 for ; Mon, 10 Jan 2005 18:37:53 +0530 From: "Nataraju A B" To: Subject: RE: [Sip] a question on tags when INVITE is challenged Date: Mon, 10 Jan 2005 18:32:54 +0530 Message-ID: <000401c4f714$b42fbad0$7302a8c0@Nataraju> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <6e749dc6050110044265861b63@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Best Regards, Nataraju A.B. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Aby K Samuel Sent: Monday, January 10, 2005 6:12 PM To: sip@ietf.org Subject: RE: [Sip] a question on tags when INVITE is challenged Can someone tell me how having the same tag in the From fields of INVITE(F1) and INVITE(F4), affect a call ?? > > Message: 5 > Date: Wed, 5 Jan 2005 07:20:20 -0800 (PST) > From: Vijay Gaur > Subject: RE: [Sip] a question on tags when INVITE is challenged > To: Nataraju A B , "'Wang, Jin-Gen'" > , sip@ietf.org > Message-ID: <20050105152020.76711.qmail@web61205.mail.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Wang, > Vendor1's SIP implementation should not expect same To-tag which is present in 401. There is no dialog established by 401 response. New INVITE with credentials is totaly different request. In fact few SIP implementations might send the same From tag of original INVITE. > > You can see similar call flows in the draft below: > http://www.iptel.org/info/players/ietf/callflows/draft-ietf-sipping-basi c-call-flows-02.txt > > Thanks, > Vijay Gaur > > Nataraju A B wrote: > Comments inline... > > Best Regards, > Nataraju A.B. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Wang, Jin-Gen > Sent: Wednesday, January 05, 2005 10:45 AM > To: sip@ietf.org > Subject: [Sip] a question on tags when INVITE is challenged > > We are running into an inter-op problem in SIP. It involves the > interpretation of RFC 3261. Hopefully we can get some input from the > list. Here is the call flow: > > UAC UAS > | ----- INVITE (F1) ------> | > | <--- 401 (F2) ------------ | > | ------ ACK (F3) ---------> | > | ------ INVITE (F4) ------> | > | ............................... | > | <----- 200 (F5) ---------- | > | ------- ACK (F6) --------> | > > where INVITE (F1) has no credential and INVITE (F4) has credential. > > The vendor 1 believes INVITE (F1) and INVITE (F4) should have same From > tag and 401 (F2) and 200 (F5) should have same To tag. The following > quote from section 22.2 in RFC 3261 indicates F4 is an updated request. > > "When a UAC resubmits a request with its credentials after receiving a > 401 (Unauthorized) or 407 (Proxy Authentication Required) response, > it MUST increment the CSeq header field value as it would normally > when sending an updated request." > > It implicitly indicates that INVITE (F1) and INVITE (F4) are within the > same dialog for a same call even though the dialog is created after > INVITE (F4). > > [ABN] this might be confusing text... may needs to be modified... > > The vendor 2 believes INVITE (F1) and INVITE (F4) should have different > >From tag and/or 401 (F2) and 200 (F5) should have different To tags > because of the quote from section 19.3 in RFC 3261: > > "When a tag is generated by a UA for insertion into a request or > response, it MUST be globally unique and cryptographically random > with at least 32 bits of randomness. A property of this selection > requirement is that a UA will place a different tag into the From > header of an INVITE than it would place into the To header of the > response to the same INVITE. This is needed in order for a UA to > invite itself to a session, a common case for "hairpinning" of calls > in PSTN gateways. Similarly, two INVITEs for different calls will > have different From tags, and two responses for different calls will > have different To tags." > > Which vendor interprets the tag requirements correctly? > > [ABN] I feel the vendor 2 interprets correctly... > Once the failure response received for an INVITE request and that > transaction is closed the session will also be deleted since there are > no other dialog exists as part of the same session. Hence the > application (no the user) has to initiate a new session with new from > tag to send the INVITE (F4) with challenge response... > > Thanks. > > Jin-Gen Wang > Level3 Communications Inc. > 1025 Eldorado Blvd. > Broomfield, CO 80021 > > _______________________________________________ > 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 > > Vijay Gaur > It's how you deal with failure that determines how you achieve success. > Au revoir, Adios, Namaste > > --------------------------------- > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile phone. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www1.ietf.org/pipermail/sip/attachments/20050105/0f235b2f/attachm ent.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 9, Issue 2 > ********************************* > _______________________________________________ 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 Mon Jan 10 13:05:28 2005 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 NAA09922 for ; Mon, 10 Jan 2005 13:05:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co48f-0002sl-K7 for sip-web-archive@ietf.org; Mon, 10 Jan 2005 13:19:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3lf-00067E-D6; Mon, 10 Jan 2005 12:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3gk-000588-UJ for sip@megatron.ietf.org; Mon, 10 Jan 2005 12:50:47 -0500 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 MAA08638 for ; Mon, 10 Jan 2005 12:50:44 -0500 (EST) Received: from ausmtp01.au.ibm.com ([202.81.18.186]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3uL-0002Mz-Tg for sip@ietf.org; Mon, 10 Jan 2005 13:04:53 -0500 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id j0AHpjl7099294 for ; Tue, 11 Jan 2005 04:51:46 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0AHq9QM235016 for ; Tue, 11 Jan 2005 04:52:09 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11/8.12.11) with ESMTP id j0AHo5Nf001114 for ; Tue, 11 Jan 2005 04:50:05 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75]) by d23av02.au.ibm.com (8.12.11/8.12.11) with ESMTP id j0AHo5cB001111 for ; Tue, 11 Jan 2005 04:50:05 +1100 From: Ke Ke Qi To: sip@ietf.org Message-ID: Date: Tue, 11 Jan 2005 01:43:16 +0800 X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 6.51HF338 | June 21, 2004) at 11/01/2005 01:43:18 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] Ke Ke Qi/China/IBM is out of the office. 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="===============0074575786==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 --===============0074575786== Content-type: multipart/alternative; Boundary="0__=C7BBE516DFF2DEE48f9e8a93df938690918cC7BBE516DFF2DEE4" Content-Disposition: inline --0__=C7BBE516DFF2DEE48f9e8a93df938690918cC7BBE516DFF2DEE4 Content-type: text/plain; charset=US-ASCII I will be out of the office starting 2005-01-10 and will not return until 2005-01-12. I will respond to your message when I return. Any urgent thing, please contact with my manager Yan Da Lai --0__=C7BBE516DFF2DEE48f9e8a93df938690918cC7BBE516DFF2DEE4 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 2005-01-10 and will not return until 2005-01-12.

I will respond to your message when I return.
Any urgent thing, please contact with my manager Yan Da Lai --0__=C7BBE516DFF2DEE48f9e8a93df938690918cC7BBE516DFF2DEE4-- --===============0074575786== 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 --===============0074575786==-- From sip-bounces@ietf.org Wed Jan 12 07:51:16 2005 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 HAA07927 for ; Wed, 12 Jan 2005 07:51:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoiBr-0004Ko-Do for sip-web-archive@ietf.org; Wed, 12 Jan 2005 08:05:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cohsf-00008v-PL; Wed, 12 Jan 2005 07:45:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CohjR-0007Hb-9O for sip@megatron.ietf.org; Wed, 12 Jan 2005 07:36:13 -0500 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 HAA07079 for ; Wed, 12 Jan 2005 07:36:12 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CohxQ-0003t6-Qy for sip@ietf.org; Wed, 12 Jan 2005 07:50:42 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0CCa9h5003130 for ; Wed, 12 Jan 2005 13:36:09 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 13:36:09 +0100 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZCW2T7HL; Wed, 12 Jan 2005 13:36:09 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A4A1C189CC for ; Wed, 12 Jan 2005 14:36:08 +0200 (EET) Message-ID: <41E519B8.7090700@ericsson.com> Date: Wed, 12 Jan 2005 14:36:08 +0200 X-Sybari-Trust: 70e6736b a5e9b67f 61e0878d 00000139 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2005 12:36:09.0115 (UTC) FILETIME=[4AC74EB0:01C4F8A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Sip] Draft defining the Accept-Disposition header field 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 Folks, I have submitted a draft that defines the Accept-Disposition header field. The usage of this header field would be similar to the usage of Accept, Accept-Encoding, or Accept-Language, but it would indicate support for disposition types. http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept-disposition-00.txt Your comments are welcome. Thanks, Gonzalo _______________________________________________ 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 Jan 12 09:32:12 2005 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 JAA16631 for ; Wed, 12 Jan 2005 09:32:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cojli-000794-ST for sip-web-archive@ietf.org; Wed, 12 Jan 2005 09:46:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojUE-00043i-LH; Wed, 12 Jan 2005 09:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojRt-0003EQ-UY for sip@megatron.ietf.org; Wed, 12 Jan 2005 09:26:13 -0500 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 JAA16137 for ; Wed, 12 Jan 2005 09:26:12 -0500 (EST) 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 1Cojfs-0006y5-VW for sip@ietf.org; Wed, 12 Jan 2005 09:40:44 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Jan 2005 07:37:53 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0CEPajw013325; Wed, 12 Jan 2005 06:25:37 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOG72473; Wed, 12 Jan 2005 09:25:35 -0500 (EST) Message-ID: <41E5335F.6080002@cisco.com> Date: Wed, 12 Jan 2005 09:25:35 -0500 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: Gonzalo Camarillo Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: <41E519B8.7090700@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: sip 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: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Gonzalo, I think work on this general subject area is long overdue. The whole notion of content disposition is significantly underspecified in sip. I would like to see it go further, in several respects: - define the meaning when no Accept-Disposition is present. Are there any disposition types that are required to be supported by default? (E.g. is support for 'render' a default?) - Define how to report the following situation: A request as been received containing a body part with content type T and content disposition D. Type T is supported with some dispositions, but not with disp D, and disposition D is supported, but not with type T. (E.g. if a MESSAGE was received containing body with c-t:application/sdp and c-d:render.) - We really need better specification of specific content dispositions. E.g. I don't know how to decide if I support 'render', because I don't know what that means. And what do I do if I can support 'render' for MESSAGE, but not for SUBSCRIBE? - There is a real need for further specification of how content dispostion is used with multipart bodies. The contained body parts may have independent dispositions. Is the content type of the container related to that of the contents, or independent of it? If independent, then what should it be. (Most examples just don't include a c-d in multiparts, which means they default to 'render'. What does it mean to 'render' a multipart that contains parts with dispostions other than 'render'?) - There is need for specification of what c-d to use with the distinguished parts of special multipart containers. E.g. the signature part of a multipart/signed. - What should the disposition be for body parts that contain content-id and are then referenced from elsewhere in the message using a cid: uri? If such body parts have a dispostion and type that implies processing independent of the reference, are they to be processed both ways? (Strained example: message has an Alert-Info header with a cid: uri referencing a body part with c-d of 'render'. Should it be used to alert *and* also be rendered as part of the session?) It seems likely that resolving all of the above would require more than one draft. But I think we should recognize that there is a program of required work, and adjust the charter accordingly, with the needed deliverables being scheduled. I would be willing to work on this. Paul Gonzalo Camarillo wrote: > Folks, > > I have submitted a draft that defines the Accept-Disposition header > field. The usage of this header field would be similar to the usage of > Accept, Accept-Encoding, or Accept-Language, but it would indicate > support for disposition types. > > http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept-disposition-00.txt > > > Your comments are welcome. > > Thanks, > > Gonzalo > > > > _______________________________________________ > 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 Jan 13 05:42:27 2005 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 FAA24419 for ; Thu, 13 Jan 2005 05:42:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2f8-0007vZ-DR for sip-web-archive@ietf.org; Thu, 13 Jan 2005 05:57:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2KM-0000AH-39; Thu, 13 Jan 2005 05:35:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2Fz-0007tG-3V for sip@megatron.ietf.org; Thu, 13 Jan 2005 05:31:11 -0500 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 FAA23820 for ; Thu, 13 Jan 2005 05:31:08 -0500 (EST) From: innovation.interops@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2UA-0007iC-CF for sip@ietf.org; Thu, 13 Jan 2005 05:45:52 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 72B6C2052E for ; Thu, 13 Jan 2005 15:55:00 +0530 (IST) Received: from blr-ec-bh1.wipro.com (unknown [10.200.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 56D3F2052A for ; Thu, 13 Jan 2005 15:55:00 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 16:00:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Jan 2005 16:00:33 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFA4@blr-k1-msg.wipro.com> Thread-Topic: Processing REGISTER REQUESTS - STEP 6 Thread-Index: AcT5WumyxhAcLubyT3CK6lff+WuHFg== To: X-OriginalArrivalTime: 13 Jan 2005 10:30:29.0671 (UTC) FILETIME=[E7553370:01C4F95A] X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sip] Processing REGISTER REQUESTS - STEP 6 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="===============0253208912==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. --===============0253208912== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F95A.E9C0E1ED" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F95A.E9C0E1ED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 As per section 10.3 step 6 the bindings must not be removed if there is = an incoming REGISTER request with... =20 CallID=3D=3DOne stored CSeq=3D=3DSame as stored Contact : * Expires: 0 =20 But I found couple of Registrar implementations removing the bindings = and sends 200Ok.It should have dropped the request. =20 Any thoughts or inputs?? =20 Thanks karthikeyan =20 =20 ------_=_NextPart_001_01C4F95A.E9C0E1ED Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,
=0A=
 
=0A=
As per section 10.3 step 6 the bindings = must not be =0A= removed if there is an incoming REGISTER request with...
=0A=
 
=0A=
CallID=3D=3DOne stored
=0A=
CSeq=3D=3DSame as stored
=0A=
Contact : *
=0A=
Expires: 0
=0A=
 
=0A=
But I found couple of Registrar = implementations =0A= removing the bindings and sends 200Ok.It should have dropped the =0A= request.
=0A=
 
=0A=
Any thoughts or inputs??
=0A=
 
=0A=
Thanks
=0A=
karthikeyan
=0A=
 
=0A=
 
------_=_NextPart_001_01C4F95A.E9C0E1ED-- --===============0253208912== 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 --===============0253208912==-- From sip-bounces@ietf.org Thu Jan 13 05:45:17 2005 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 FAA24597 for ; Thu, 13 Jan 2005 05:45:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2hr-0007zi-W0 for sip-web-archive@ietf.org; Thu, 13 Jan 2005 06:00:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2Rp-0001d2-SI; Thu, 13 Jan 2005 05:43:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp2Kq-0000E0-DT for sip@megatron.ietf.org; Thu, 13 Jan 2005 05:36:12 -0500 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 FAA24044 for ; Thu, 13 Jan 2005 05:36:09 -0500 (EST) From: innovation.interops@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp2Z1-0007ng-P0 for sip@ietf.org; Thu, 13 Jan 2005 05:50:53 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B98F2052E for ; Thu, 13 Jan 2005 16:00:03 +0530 (IST) Received: from blr-ec-bh2.wipro.com (unknown [10.200.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 263D72052A for ; Thu, 13 Jan 2005 16:00:03 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 16:05:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Jan 2005 16:05:17 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFA5@blr-k1-msg.wipro.com> Thread-Topic: PROCESSING REGISTER REQUESTS - Section 10.3 Thread-Index: AcT5W5K59l2Ae5j6RyC3nuGvvng1bw== To: X-OriginalArrivalTime: 13 Jan 2005 10:35:35.0926 (UTC) FILETIME=[9DE00160:01C4F95B] X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] PROCESSING REGISTER REQUESTS - Section 10.3 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="===============1497746986==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. --===============1497746986== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F95B.92B91DD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F95B.92B91DD4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 As per RFC 3261 the Registrars must ignore Record-Route field in any = incoming REGISTER request and should not include the same in the = response. =20 But I find couple of Registrar implementations including the Record = Route Field in the 200OK Response. =20 Any advice or suggestion?? =20 Thanks karthikeyan ------_=_NextPart_001_01C4F95B.92B91DD4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
=0A=
 
=0A=
As per RFC 3261 the Registrars must = ignore =0A= Record-Route field in any incoming REGISTER request and should not = include the =0A= same in the response.
=0A=
 
=0A=
But I find couple of Registrar = implementations =0A= including the Record Route Field in the 200OK Response.
=0A=
 
=0A=
Any advice or suggestion??
=0A=
 
=0A=
Thanks
=0A=
karthikeyan
------_=_NextPart_001_01C4F95B.92B91DD4-- --===============1497746986== 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 --===============1497746986==-- From sip-bounces@ietf.org Thu Jan 13 06:48:03 2005 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 GAA29543 for ; Thu, 13 Jan 2005 06:48:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp3gb-0000zH-7W for sip-web-archive@ietf.org; Thu, 13 Jan 2005 07:02:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3NV-0007ge-AV; Thu, 13 Jan 2005 06:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3Jv-0006sf-Q5 for sip@megatron.ietf.org; Thu, 13 Jan 2005 06:39:19 -0500 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 GAA29142 for ; Thu, 13 Jan 2005 06:39:16 -0500 (EST) From: mslabrador@sztele.com Received: from [194.140.66.14] (helo=salix1.sztele.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp3Y6-0000oF-1a for sip@ietf.org; Thu, 13 Jan 2005 06:54:01 -0500 Received: from jerez.ipt.es ([10.161.28.22]) by salix1.sztele.com (Lotus Domino Release 5.0.8) with ESMTP id 2005011312380612:75629 ; Thu, 13 Jan 2005 12:38:06 +0100 To: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 13 Jan 2005 12:38:05 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on Juglans/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 13/01/2005 12:38:06, Itemize by SMTP Server on Salix1/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 13/01/2005 12:38:06, Serialize by Router on Salix1/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 13/01/2005 12:39:15, Serialize complete at 13/01/2005 12:39:15 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Messenger Connection TLS 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Hello everybody, I'm trying to connect messenger 5 to my SIP proxy, but when I try to us= e a TLS connection, messenger gives me an error --> service non available. I can log in with TCP connection but I would like to do it with TLS... Any proposal? Thank you Mar=EDa S=E1nchez = _______________________________________________ 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 Jan 13 07:11:56 2005 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 HAA01285 for ; Thu, 13 Jan 2005 07:11:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp43k-0001TM-Ne for sip-web-archive@ietf.org; Thu, 13 Jan 2005 07:26:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3jq-0003Mb-EN; Thu, 13 Jan 2005 07:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3e1-00029s-BK for sip@megatron.ietf.org; Thu, 13 Jan 2005 07:00:05 -0500 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 HAA00551 for ; Thu, 13 Jan 2005 07:00:01 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp3s3-0001FN-4w for sip@ietf.org; Thu, 13 Jan 2005 07:14:46 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0DBxph5008658 for ; Thu, 13 Jan 2005 12:59:51 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 12:59:51 +0100 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAPFHRY1; Thu, 13 Jan 2005 12:59:51 +0100 Received: from ericsson.com (rvi2-94-80.sw.ericsson.se [153.88.94.80]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4782D18A90; Thu, 13 Jan 2005 13:59:50 +0200 (EET) Message-ID: <41E662B6.9030002@ericsson.com> Date: Thu, 13 Jan 2005 13:59:50 +0200 X-Sybari-Trust: 8807ae24 96d33411 cd4c1d26 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2005 11:59:51.0777 (UTC) FILETIME=[6365A510:01C4F967] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Henning Schulzrinne Subject: [Sip] Re: question on draft-ietf-sip-sctp-05.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.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cullen, thanks for pointing this out. This problem was caused by the documentation process we followed. The original idea was to define everything in the SIP over SCTP draft, but then some parts were moved to RFC 3261 (e.g., the definition of the token for the via header and the value for the transport parameter) and to RFC 3263 (e.g., the definition of the SIP+D2S service). We obviously forgot to define (somewhere) both tokens and the new service for TLS over SCTP. I will prepare a new revision of the draft including these definitions. Thanks, Gonzalo Cullen Jennings wrote: > What do the following two lines look like if I am using TLS over SCTP? > > sip:Bob.Johnson@example.com;transport=sctp > Via: SIP/2.0/SCTP ws1234.example.com:5060 > > And could you explicitly mention what the SRV lookups are like (particularly > with TLS and SCTP) > > Thanks, Cullen > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ 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 Jan 13 07:23:51 2005 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 HAA02214 for ; Thu, 13 Jan 2005 07:23:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp4FG-0001jA-HW for sip-web-archive@ietf.org; Thu, 13 Jan 2005 07:38:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3yb-0006Nt-VJ; Thu, 13 Jan 2005 07:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3we-0005Xb-3X for sip@megatron.ietf.org; Thu, 13 Jan 2005 07:19:20 -0500 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 HAA01866 for ; Thu, 13 Jan 2005 07:19:16 -0500 (EST) Received: from web40802.mail.yahoo.com ([66.218.78.179]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cp4Aq-0001c6-N2 for sip@ietf.org; Thu, 13 Jan 2005 07:34:02 -0500 Received: (qmail 27444 invoked by uid 60001); 13 Jan 2005 12:18:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=hcP6iaT5v8KvLOHlMwAo49GsejZV9tJ5Bo+Pf1olzq6Ag8aqQ5p+DMo7bmiDZG41pysbdEa0uPZCRH8BW5Fk6oLngv2BhRhgd3t7UoC8/Ciios6KGxNOM2zp60D2Hdzl9QYq8qMYQm8RkCnIGc7srk0WAjJSax41VNS6/ntFq0A= ; Message-ID: <20050113121844.27442.qmail@web40802.mail.yahoo.com> Received: from [203.145.183.39] by web40802.mail.yahoo.com via HTTP; Thu, 13 Jan 2005 04:18:44 PST Date: Thu, 13 Jan 2005 04:18:44 -0800 (PST) From: Raghavendra S To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] Is there any code or books available for SIP application level gateway for linux? 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="===============2083076071==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 --===============2083076071== Content-Type: multipart/alternative; boundary="0-543837585-1105618724=:26758" --0-543837585-1105618724=:26758 Content-Type: text/plain; charset=us-ascii --------------------------------- Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. --0-543837585-1105618724=:26758 Content-Type: text/html; charset=us-ascii

Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more. --0-543837585-1105618724=:26758-- --===============2083076071== 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 --===============2083076071==-- From sip-bounces@ietf.org Thu Jan 13 08:15:25 2005 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 IAA06624 for ; Thu, 13 Jan 2005 08:15:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp53A-0003Gs-Mm for sip-web-archive@ietf.org; Thu, 13 Jan 2005 08:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4f7-000827-H8; Thu, 13 Jan 2005 08:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4WL-0004op-A6 for sip@megatron.ietf.org; Thu, 13 Jan 2005 07:56:13 -0500 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 HAA04635 for ; Thu, 13 Jan 2005 07:56:10 -0500 (EST) Received: from [61.95.205.153] (helo=cellcloud.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp4kX-0002cD-FQ for sip@ietf.org; Thu, 13 Jan 2005 08:10:54 -0500 Received: from [172.16.3.94] (helo=GirishPai) by cellcloud.com with smtp (Exim 3.22 #6) id 1Cp4I1-00069P-00; Thu, 13 Jan 2005 18:11:25 +0530 Message-ID: <02f801c4f96e$26e7c9e0$5e0310ac@btslblr> From: "girish" To: , , "'sip-ietf'" Date: Thu, 13 Jan 2005 18:18:16 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.8 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sip] PoC service indication 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="===============0669443334==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 3.1 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. --===============0669443334== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F5_01C4F99C.40969000" This is a multi-part message in MIME format. ------=_NextPart_000_02F5_01C4F99C.40969000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, What do we mean by PoC service indication in a SIP Message. What = does it imply ? Girish Pai Bharti Telesoft Intl Pvt. Ltd. Airport Road Bangalore ------=_NextPart_000_02F5_01C4F99C.40969000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
   What do we mean by     PoC service indication  in a SIP Message. = What does it=20 imply ?
 
 
Girish Pai
Bharti Telesoft Intl Pvt. = Ltd.
Airport=20 Road
Bangalore
------=_NextPart_000_02F5_01C4F99C.40969000-- --===============0669443334== 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 --===============0669443334==-- From sip-bounces@ietf.org Thu Jan 13 08:20:10 2005 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 IAA07343 for ; Thu, 13 Jan 2005 08:20:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp57l-0003Sr-HS for sip-web-archive@ietf.org; Thu, 13 Jan 2005 08:34:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4lG-0001Iu-S6; Thu, 13 Jan 2005 08:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4cZ-0007El-3H for sip@megatron.ietf.org; Thu, 13 Jan 2005 08:02:39 -0500 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 IAA05280 for ; Thu, 13 Jan 2005 08:02:37 -0500 (EST) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp4qm-0002pE-Eq for sip@ietf.org; Thu, 13 Jan 2005 08:17:21 -0500 Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id j0DD1o7B015592; Thu, 13 Jan 2005 08:01:58 -0500 (EST) From: "Brett Tate" To: , Subject: RE: [Sip] PROCESSING REGISTER REQUESTS - Section 10.3 Date: Thu, 13 Jan 2005 08:01:53 -0500 Message-ID: <000501c4f970$10935180$a601a8c0@brett1> 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 In-Reply-To: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFA5@blr-k1-msg.wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit > As per RFC 3261 the Registrars must > ignore Record-Route field in any > incoming REGISTER request and should > not include the same in the response. > > But I find couple of Registrar > implementations including the > Record Route Field in the 200OK Response. > > Any advice or suggestion?? The Registrar is compliant to RFC2543 concerning the Record-Route. The Registrar has not yet become compliant to that particular "MUST NOT" within RFC3261. There is likely no consequences. Such questions should be posted to sip-implementors@cs.columbia.edu instead of this list. _______________________________________________ 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 Jan 13 09:09:49 2005 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 JAA11810 for ; Thu, 13 Jan 2005 09:09:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp5tp-0004vE-St for sip-web-archive@ietf.org; Thu, 13 Jan 2005 09:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp5bj-00018t-J7; Thu, 13 Jan 2005 09:05:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp5WU-00081d-Ck for sip@megatron.ietf.org; Thu, 13 Jan 2005 09:00:26 -0500 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 JAA10874 for ; Thu, 13 Jan 2005 09:00:24 -0500 (EST) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp5ki-0004f4-EP for sip@ietf.org; Thu, 13 Jan 2005 09:15:09 -0500 Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id j0DE0Klw018039; Thu, 13 Jan 2005 09:00:24 -0500 (EST) From: "Brett Tate" To: , Subject: RE: [Sip] Processing REGISTER REQUESTS - STEP 6 Date: Thu, 13 Jan 2005 09:00:23 -0500 Message-ID: <000b01c4f978$3a803910$a601a8c0@brett1> 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 In-Reply-To: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFA4@blr-k1-msg.wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit > As per section 10.3 step 6 the bindings > must not be removed if there is an > incoming REGISTER request with... > > CallID==One stored > CSeq==Same as stored > Contact : * > Expires: 0 > > But I found couple of Registrar implementations > removing the bindings and sends 200Ok. > It should have dropped the request. > > Any thoughts or inputs?? The Registrar is compliant to RFC2543 and has not yet become compliant to that particular "MUST" within RFC3261. The situation can occur if the REGISTER forked. If a merged request was observed, a 482 response might be returned. If the merge was not detected, the REGISTER might trigger a second deletion and return a 200 response. During a race condition with a new REGISTER, this second removal might be problematic. I do not know if RFC3261 discusses this race condition or provides a solution. _______________________________________________ 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 Jan 13 09:32:18 2005 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 JAA14207 for ; Thu, 13 Jan 2005 09:32:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp6Fb-0005Z2-JP for sip-web-archive@ietf.org; Thu, 13 Jan 2005 09:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp5qU-0005lK-T1; Thu, 13 Jan 2005 09:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp5ec-0001u5-Uw for sip@megatron.ietf.org; Thu, 13 Jan 2005 09:08:51 -0500 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 JAA11751 for ; Thu, 13 Jan 2005 09:08:47 -0500 (EST) Received: from morbo.e-centre.net ([66.154.82.3] helo=cubert.e-centre.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp5sq-0004u5-Iy for sip@ietf.org; Thu, 13 Jan 2005 09:23:33 -0500 Received: from [10.3.1.19] (helo=guestrelay.stayonline.net) by cubert.e-centre.net with esmtp (Exim 3.35 #1 (Debian)) id 1Cp5dk-0003yc-00; Thu, 13 Jan 2005 09:07:56 -0500 Received: from et-bnh-9.site.stayonline.net (unknown [66.155.209.82]) by guestrelay.stayonline.net (Spam Firewall) with ESMTP id 54C9C20CAB81; Thu, 13 Jan 2005 09:07:50 -0500 (EST) Received: from IBM-7B137D96EC3.ZDSL.com ([192.168.50.101]) by et-bnh-9.site.stayonline.net (8.12.6/8.12.6) with ESMTP id j0DE6iae014209; Thu, 13 Jan 2005 14:06:44 GMT Message-Id: <6.2.0.14.2.20050113090557.04640270@pop3.zdsl.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 13 Jan 2005 09:07:49 -0500 To: "girish" , , , "'sip-ietf'" From: Peter Macaulay Subject: Re: [Sip] PoC service indication In-Reply-To: <02f801c4f96e$26e7c9e0$5e0310ac@btslblr> References: <02f801c4f96e$26e7c9e0$5e0310ac@btslblr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 One meaning of PoC is .. Push-To-Talk (PTT) over Cellular (PoC). /PETER MACAULAY At 07:48 AM 1/13/2005, girish wrote: >Hi, > What do we mean by PoC service indication in a SIP Message. What > does it imply ? > > >Girish Pai >Bharti Telesoft Intl Pvt. Ltd. >Airport Road >Bangalore >_______________________________________________ >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 Jan 13 14:38:30 2005 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 OAA07299 for ; Thu, 13 Jan 2005 14:38:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpB1u-0004As-W9 for sip-web-archive@ietf.org; Thu, 13 Jan 2005 14:53:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpAiG-0003iW-9E; Thu, 13 Jan 2005 14:32:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpAcg-0000t5-Tm for sip@megatron.ietf.org; Thu, 13 Jan 2005 14:27:11 -0500 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 OAA05950 for ; Thu, 13 Jan 2005 14:27:09 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAqm-0003qx-FZ for sip@ietf.org; Thu, 13 Jan 2005 14:41:57 -0500 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0DHoxvD024450; Thu, 13 Jan 2005 18:50:59 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 18:50:57 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 18:50:57 +0100 Received: from ericsson.com (rvi2-94-80.sw.ericsson.se [153.88.94.80]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 053CC189CC; Thu, 13 Jan 2005 19:50:55 +0200 (EET) Message-ID: <41E6B4FE.2010902@ericsson.com> Date: Thu, 13 Jan 2005 19:50:54 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Re: question on draft-ietf-sip-sctp-05.txt References: <41E662B6.9030002@ericsson.com> In-Reply-To: <41E662B6.9030002@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2005 17:50:57.0495 (UTC) FILETIME=[6F8B1E70:01C4F998] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Henning Schulzrinne 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 Cullen, please, have a look at Sections 4, 6, and 8 of the new revision of the draft (you can fetch it from the link below) and let me know if they address your concerns: http://users.piuha.net/gonzalo/temp/draft-ietf-sip-sctp-06.txt Thanks, Gonzalo Gonzalo Camarillo wrote: > Cullen, > > thanks for pointing this out. This problem was caused by the > documentation process we followed. The original idea was to define > everything in the SIP over SCTP draft, but then some parts were moved to > > RFC 3261 (e.g., the definition of the token for the via header and the > value for the transport parameter) and to RFC 3263 (e.g., the definition > > of the SIP+D2S service). We obviously forgot to define (somewhere) both > tokens and the new service for TLS over SCTP. > > I will prepare a new revision of the draft including these definitions. > > Thanks, > > Gonzalo > > > Cullen Jennings wrote: > > >>What do the following two lines look like if I am using TLS over SCTP? >> >> sip:Bob.Johnson@example.com;transport=sctp >> Via: SIP/2.0/SCTP ws1234.example.com:5060 >> >>And could you explicitly mention what the SRV lookups are like > > (particularly > >>with TLS and SCTP) >> >>Thanks, Cullen >> > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ 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 Jan 13 21:01:11 2005 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 VAA16124 for ; Thu, 13 Jan 2005 21:01:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpH0L-0006rj-DH for sip-web-archive@ietf.org; Thu, 13 Jan 2005 21:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpGi6-0005TA-BG; Thu, 13 Jan 2005 20:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpGez-00049B-PC for sip@megatron.ietf.org; Thu, 13 Jan 2005 20:53:58 -0500 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 UAA15741 for ; Thu, 13 Jan 2005 20:53:55 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpGtK-0006id-2R for sip@ietf.org; Thu, 13 Jan 2005 21:08:47 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Jan 2005 17:59:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0E1rLjw025883; Thu, 13 Jan 2005 17:53:21 -0800 (PST) Received: from [10.0.147.181] (sjc-vpn7-411.cisco.com [10.21.145.155]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVO86290; Thu, 13 Jan 2005 17:53:19 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 13 Jan 2005 17:53:18 -0800 Subject: Re: [Sip] Re: question on draft-ietf-sip-sctp-05.txt From: Cullen Jennings To: "gonzalo.camarillo@ericsson.com" Message-ID: In-Reply-To: <41E6B4FE.2010902@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Henning Schulzrinne 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 Yes - that dealt with everything I was worried about. Looks good. Thanks. On 1/13/05 9:50 AM, "Gonzalo Camarillo" wrote: > Cullen, > > please, have a look at Sections 4, 6, and 8 of the new revision of the > draft (you can fetch it from the link below) and let me know if they > address your concerns: > > http://users.piuha.net/gonzalo/temp/draft-ietf-sip-sctp-06.txt > > Thanks, > > Gonzalo > > Gonzalo Camarillo wrote: > >> Cullen, >> >> thanks for pointing this out. This problem was caused by the >> documentation process we followed. The original idea was to define >> everything in the SIP over SCTP draft, but then some parts were moved to >> >> RFC 3261 (e.g., the definition of the token for the via header and the >> value for the transport parameter) and to RFC 3263 (e.g., the definition >> >> of the SIP+D2S service). We obviously forgot to define (somewhere) both >> tokens and the new service for TLS over SCTP. >> >> I will prepare a new revision of the draft including these definitions. >> >> Thanks, >> >> Gonzalo >> >> >> Cullen Jennings wrote: >> >> >>> What do the following two lines look like if I am using TLS over SCTP? >>> >>> sip:Bob.Johnson@example.com;transport=sctp >>> Via: SIP/2.0/SCTP ws1234.example.com:5060 >>> >>> And could you explicitly mention what the SRV lookups are like >> >> (particularly >> >>> with TLS and SCTP) >>> >>> Thanks, Cullen >>> >> >> _______________________________________________ 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 Jan 13 22:24:15 2005 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 WAA20879 for ; Thu, 13 Jan 2005 22:24:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpIIm-0008Of-N2 for sip-web-archive@ietf.org; Thu, 13 Jan 2005 22:39:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpI3D-0004tl-NK; Thu, 13 Jan 2005 22:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpI2a-0004Wq-P7 for sip@megatron.ietf.org; Thu, 13 Jan 2005 22:22:24 -0500 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 WAA20816 for ; Thu, 13 Jan 2005 22:22:22 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpIGr-0008MZ-T6 for sip@ietf.org; Thu, 13 Jan 2005 22:37:15 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAA008ZWENV3J@szxga02-in.huawei.com> for sip@ietf.org; Fri, 14 Jan 2005 11:21:31 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAA008U9ENVAA@szxga02-in.huawei.com> for sip@ietf.org; Fri, 14 Jan 2005 11:21:31 +0800 (CST) Received: from Z41317 ([10.110.108.85]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IAA00GA7ES6IV@szxml01-in.huawei.com> for sip@ietf.org; Fri, 14 Jan 2005 11:24:06 +0800 (CST) Date: Fri, 14 Jan 2005 11:22:20 +0800 From: =?gb2312?B?1uzA1w==?= To: sip@ietf.org Message-id: <001601c4f9e8$422de750$556c6e0a@china.huawei.com> Organization: HUAWEI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] ask SIP questions first time 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="===============1999572190==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a multi-part message in MIME format. --===============1999572190== Content-type: multipart/alternative; boundary="Boundary_(ID_ETXM9frCvdN+9v0X2DQvQw)" This is a multi-part message in MIME format. --Boundary_(ID_ETXM9frCvdN+9v0X2DQvQw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT hello all Can I ask some questions about RFC3261 for discuessing? Zhu Lei Huawei Technologies Co.,LTD. Telephone: 01082882838 E-mail Addr: lei.zhu@huawei.com --Boundary_(ID_ETXM9frCvdN+9v0X2DQvQw) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
hello all
Can I ask some questions about RFC3261 for discuessing?
 
Zhu Lei
Huawei Technologies Co.,LTD.
Telephone: 01082882838
E-mail Addr: lei.zhu@huawei.com
--Boundary_(ID_ETXM9frCvdN+9v0X2DQvQw)-- --===============1999572190== 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 --===============1999572190==-- From sip-bounces@ietf.org Fri Jan 14 16:39:38 2005 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 QAA25496 for ; Fri, 14 Jan 2005 16:39:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZOw-0007HJ-Ox for sip-web-archive@ietf.org; Fri, 14 Jan 2005 16:54:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZ0U-0007MP-Rv; Fri, 14 Jan 2005 16:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpYdo-0007xr-6U for sip@megatron.ietf.org; Fri, 14 Jan 2005 16:05:56 -0500 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 QAA18074 for ; Fri, 14 Jan 2005 16:05:54 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpYsG-0004tH-JT for sip@ietf.org; Fri, 14 Jan 2005 16:20:55 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id j0EL6q90015893 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Jan 2005 15:06:53 -0600 In-Reply-To: <001601c4f9e8$422de750$556c6e0a@china.huawei.com> References: <001601c4f9e8$422de750$556c6e0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <06BA87BB-6670-11D9-B0CD-000D93594350@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] ask SIP questions first time Date: Fri, 14 Jan 2005 15:05:31 -0600 To: =?ISO-2022-JP?B?GyRCPGtNaxsoQg==?= X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On Jan 13, 2005, at 9:22 PM, $B hello all > Can I ask some questions about RFC3261 for discuessing? > > Zhu Lei > Huawei Technologies Co.,LTD. > Telephone: 01082882838 > E-mail Addr: lei.zhu@huawei.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 The general recommendation for discussing current(as opposed to "being developed") SIP specifications is to use the sip-implementors list at: sip-implementors@cs.columbia.edu The address for this list is conveniently attached to the footer of messages on the SIP mailing list by our mail server. If you're suggesting requirements for changing or extending RFC3261, then probably the SIPPING list is right. If you think you've found an error in RFC 3261 that needs to be reported, then this is the right list. -- Dean Willis SIP Co-Chair _______________________________________________ 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 Jan 14 17:34:19 2005 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 RAA02307 for ; Fri, 14 Jan 2005 17:34:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpaFs-0000gh-N9 for sip-web-archive@ietf.org; Fri, 14 Jan 2005 17:49:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZqB-0007Oc-RI; Fri, 14 Jan 2005 17:22:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZaY-0002wI-KW for sip@megatron.ietf.org; Fri, 14 Jan 2005 17:06:38 -0500 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 RAA29879 for ; Fri, 14 Jan 2005 17:06:36 -0500 (EST) Received: from mailout.excelswitching.com ([208.236.123.107]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZp4-0008TA-3J for sip@ietf.org; Fri, 14 Jan 2005 17:21:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Jan 2005 17:06:05 -0500 Message-ID: <656BE56E7D48F6419054CC1C811149270239FAA9@exch01.corp.xl.com> Thread-Topic: Minor anomaly in RFC 3261 Registration example? Thread-Index: AcT6hT8Qm2U6slv0SQuaGpeh5FLvKQ== From: "Jain, Rajnish" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [Sip] Minor anomaly in RFC 3261 Registration example? 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="===============0436396020==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 This is a multi-part message in MIME format. --===============0436396020== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FA85.3E57954D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FA85.3E57954D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks: Not sure if this minor anomaly has been reported before and is already logged in SIP bugzilla (which seems to be down right now). Apologies if this is a repetition. Section 10.3 of RFC 3261 states the following: 8. The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field. Section 24.1 of RFC 3261 gives an example of 200 OK for a REGISTER as the following: SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 ;received=3D192.0.2.4 To: Bob ;tag=3D2493k59kd From: Bob ;tag=3D456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 The "expires" parameter in the 200 OK's Contact header is missing in this example whereas it's a MUST in the text. Thanks, Rajnish Email mailto:rjain@excelswitching.com=20 SIP sip:rjain@voip.excelswitching.com PSTN 508-862-3215=20 ------_=_NextPart_001_01C4FA85.3E57954D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minor anomaly in RFC 3261 Registration example?

Folks:

Not sure if this minor anomaly = has been reported before and is already logged in SIP bugzilla (which = seems to be down right now). Apologies if this is a = repetition.


Section 10.3 of RFC 3261 states = the following:

      8. = The registrar returns a 200 (OK) response.  The response = MUST
         contain Contact = header field values enumerating all current
         bindings.  = Each Contact value MUST feature an "expires"
         parameter = indicating its expiration interval chosen by the
         registrar.  = The response SHOULD include a Date header field.


Section 24.1 of RFC 3261 gives an = example of 200 OK for a REGISTER as the following:

        SIP/2.0 200 OK
        Via: SIP/2.0/UDP = bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7
         = ;received=3D192.0.2.4
        To: Bob = <sip:bob@biloxi.com>;tag=3D2493k59kd
        From: Bob = <sip:bob@biloxi.com>;tag=3D456248
        Call-ID: = 843817637684230@998sdasdh09
        CSeq: 1826 = REGISTER
        Contact: = <sip:bob@192.0.2.4>
        Expires: 7200
        Content-Length: 0


The "expires" parameter = in the 200 OK's Contact header is missing in this example whereas it's a = MUST in the text.

Thanks,
Rajnish

Email     = mailto:rjain@excelswitching.com
SIP       sip:rjain@voip.excelswitching.com
PSTN      508-862-3215=20

------_=_NextPart_001_01C4FA85.3E57954D-- --===============0436396020== 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 --===============0436396020==-- From sip-bounces@ietf.org Mon Jan 17 01:54:20 2005 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 BAA23035 for ; Mon, 17 Jan 2005 01:54:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqR1L-0004E1-Ty for sip-web-archive@ietf.org; Mon, 17 Jan 2005 02:09:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqQgL-0003ZV-Sb; Mon, 17 Jan 2005 01:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqQcT-0003LZ-Nv for sip@megatron.ietf.org; Mon, 17 Jan 2005 01:44:11 -0500 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 BAA22392 for ; Mon, 17 Jan 2005 01:44:08 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqQrS-00040H-9d for sip@ietf.org; Mon, 17 Jan 2005 01:59:40 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j0H6kiWt015597 for ; Sun, 16 Jan 2005 23:46:44 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id j0H6gVrC015960 for ; Mon, 17 Jan 2005 00:42:32 -0600 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Jan 2005 12:13:58 +0530 Message-ID: <653138C25D8AD6118292000347080A3714EA4E02@zin05exm02.corp.mot.com> From: Avasarala Ranjit-A20990 To: girish , sip-implementors@cs.columbia.edu, sip@vovida.org, "'sip-ietf'" Subject: RE: [Sip] PoC service indication Date: Mon, 17 Jan 2005 12:13:57 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.0 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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="===============1331238209==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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. --===============1331238209== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FC5F.EB5823B2" 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_01C4FC5F.EB5823B2 Content-Type: text/plain Hi PoC service indication in SIP INVITE message provides the originating user an early indication of start to speak even before invited users accept the invitation. Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of girish Sent: Thursday, January 13, 2005 6:18 PM To: sip-implementors@cs.columbia.edu; sip@vovida.org; 'sip-ietf' Subject: [Sip] PoC service indication Hi, What do we mean by PoC service indication in a SIP Message. What does it imply ? Girish Pai Bharti Telesoft Intl Pvt. Ltd. Airport Road Bangalore ------_=_NextPart_001_01C4FC5F.EB5823B2 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S Pg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW PjxTUEFOIGNsYXNzPTQ1MDU0NDAwNi0xNzAxMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgDQpzaXplPTI+SGk8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00 NTA1NDQwMDYtMTcwMTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0y PiZuYnNwOyZuYnNwOyZuYnNwOyBQb0Mgc2VydmljZSBpbmRpY2F0aW9uIGluIFNJUCBJTlZJVEUg bWVzc2FnZSBwcm92aWRlcyANCnRoZSBvcmlnaW5hdGluZyB1c2VyIGFuIGVhcmx5IGluZGljYXRp b24gb2YmbmJzcDtzdGFydCB0byZuYnNwO3NwZWFrIGV2ZW4gYmVmb3JlIA0KaW52aXRlZCB1c2Vy cyBhY2NlcHQgdGhlIGludml0YXRpb24uPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9ydGYgZm9y bWF0IC0tPg0KPFA+PFNQQU4gbGFuZz1lbi11cz48ST48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDgwODAgDQpzaXplPTI+UmVnYXJkczwvRk9OVD48L0k+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1l bi11cz48ST48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwODA4MCBzaXplPTI+UmFuaml0PC9G T05UPjwvST48L1NQQU4+IDwvUD48QlI+PEJSPg0KPERJVj48L0RJVj4NCjxESVYgY2xhc3M9T3V0 bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFj ZT1UYWhvbWEgDQpzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8 L0I+IHNpcC1ib3VuY2VzQGlldGYub3JnIA0KW21haWx0bzpzaXAtYm91bmNlc0BpZXRmLm9yZ10g PEI+T24gQmVoYWxmIE9mIDwvQj5naXJpc2g8QlI+PEI+U2VudDo8L0I+IA0KVGh1cnNkYXksIEph bnVhcnkgMTMsIDIwMDUgNjoxOCBQTTxCUj48Qj5Ubzo8L0I+IA0Kc2lwLWltcGxlbWVudG9yc0Bj cy5jb2x1bWJpYS5lZHU7IHNpcEB2b3ZpZGEub3JnOyAnc2lwLWlldGYnPEJSPjxCPlN1YmplY3Q6 PC9CPiANCltTaXBdIFBvQyBzZXJ2aWNlIGluZGljYXRpb248QlI+PEJSPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD5IaSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWw+Jm5ic3A7Jm5ic3A7IFdoYXQgZG8gd2UgbWVhbiBieSA8Rk9OVCBzaXplPTI+PEZPTlQg DQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+PC9GT05U PjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog J1RpbWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4t VVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQpmYWNlPVZlcmRhbmEgc2l6ZT0z PlBvQyBzZXJ2aWNlIGluZGljYXRpb24mbmJzcDsgaW4gYSBTSVAgTWVzc2FnZS4gV2hhdCBkb2Vz IGl0IA0KaW1wbHkgPzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9TUEFOPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mz48U1BBTiBsYW5n PUVOLUdCIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcg Um9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1h bnNpLWxhbmd1YWdlOiBFTi1HQjsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLVVTOyBtc28tYmlk aS1sYW5ndWFnZTogQVItU0EiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+R2lyaXNoIFBhaTxCUj5CaGFydGkgVGVsZXNvZnQgSW50bCBQdnQuIEx0ZC48 QlI+QWlycG9ydCANClJvYWQ8QlI+QmFuZ2Fsb3JlPEJSPjwvRk9OVD48L0RJVj48L0JPRFk+PC9I VE1MPg0K ------_=_NextPart_001_01C4FC5F.EB5823B2-- --===============1331238209== 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 --===============1331238209==-- From sip-bounces@ietf.org Mon Jan 17 04:06:21 2005 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 EAA18547 for ; Mon, 17 Jan 2005 04:06:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqT58-0007Vn-VR for sip-web-archive@ietf.org; Mon, 17 Jan 2005 04:21:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqSlJ-0002wu-32; Mon, 17 Jan 2005 04:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqSiy-0002af-2Y for sip@megatron.ietf.org; Mon, 17 Jan 2005 03:59:00 -0500 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 DAA18152 for ; Mon, 17 Jan 2005 03:58:56 -0500 (EST) Received: from [61.95.205.153] (helo=cellcloud.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqSxx-0007O0-5r for sip@ietf.org; Mon, 17 Jan 2005 04:14:30 -0500 Received: from [172.16.3.94] (helo=GirishPai) by cellcloud.com with smtp (Exim 3.22 #6) id 1CqSUL-0002RJ-00; Mon, 17 Jan 2005 14:13:53 +0530 Message-ID: <000b01c4fc71$a0de6550$5e0310ac@btslblr> From: "girish" To: "Avasarala Ranjit-A20990" , , , "'sip-ietf'" References: <653138C25D8AD6118292000347080A3714EA4E02@zin05exm02.corp.mot.com> Subject: Re: [Sip] PoC service indication Date: Mon, 17 Jan 2005 14:20:43 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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="===============0055580869==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 This is a multi-part message in MIME format. --===============0055580869== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4FC9F.BA8F7560" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4FC9F.BA8F7560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageHi Ranjit, Thanks for the explanation on the poc service indication . Could you = please tell me how exactly is it indicated in the SIP Message .What is = the keyword used to identify the poc service indication Girish Pai Bharti Telesoft Intl Pvt. Ltd. Airport Road Bangalore ----- Original Message -----=20 From: Avasarala Ranjit-A20990=20 To: girish ; sip-implementors@cs.columbia.edu ; sip@vovida.org ; = 'sip-ietf'=20 Sent: Monday, January 17, 2005 12:13 PM Subject: RE: [Sip] PoC service indication Hi PoC service indication in SIP INVITE message provides the = originating user an early indication of start to speak even before = invited users accept the invitation. Regards=20 Ranjit=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = girish Sent: Thursday, January 13, 2005 6:18 PM To: sip-implementors@cs.columbia.edu; sip@vovida.org; 'sip-ietf' Subject: [Sip] PoC service indication Hi, What do we mean by PoC service indication in a SIP Message. = What does it imply ? Girish Pai Bharti Telesoft Intl Pvt. Ltd. Airport Road Bangalore ------=_NextPart_000_0008_01C4FC9F.BA8F7560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi Ranjit,
  Thanks for the explanation on the poc = service=20 indication . Could you please tell me how exactly is it indicated in the = SIP=20 Message .What is the keyword used to identify the poc service=20 indication
 
 
Girish Pai
Bharti Telesoft Intl Pvt. Ltd.
Airport=20 Road
Bangalore
----- Original Message -----
From:=20 Avasarala=20 Ranjit-A20990
To: girish ; sip-implementors@cs.colu= mbia.edu=20 ; sip@vovida.org ; 'sip-ietf' =
Sent: Monday, January 17, 2005 = 12:13=20 PM
Subject: RE: [Sip] PoC service=20 indication

Hi
    PoC service indication in SIP INVITE = message=20 provides the originating user an early indication of start = to speak=20 even before invited users accept the invitation.
 
 

Regards
Ranjit



-----Original Message-----
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of = girish
Sent:=20 Thursday, January 13, 2005 6:18 PM
To: sip-implementors@cs.colu= mbia.edu;=20 sip@vovida.org;=20 'sip-ietf'
Subject: [Sip] PoC service=20 indication

Hi,
   What do we mean by     PoC service indication  in a SIP Message. = What does=20 it imply ?
 
 
Girish Pai
Bharti Telesoft Intl Pvt. = Ltd.
Airport=20 Road
Bangalore
------=_NextPart_000_0008_01C4FC9F.BA8F7560-- --===============0055580869== 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 --===============0055580869==-- From sip-bounces@ietf.org Mon Jan 17 04:58:30 2005 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 EAA21368 for ; Mon, 17 Jan 2005 04:58:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqTtc-0008V4-D5 for sip-web-archive@ietf.org; Mon, 17 Jan 2005 05:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTZa-0000Qv-5j; Mon, 17 Jan 2005 04:53:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTS9-00083l-Ng for sip@megatron.ietf.org; Mon, 17 Jan 2005 04:45:41 -0500 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 EAA20571 for ; Mon, 17 Jan 2005 04:45:39 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqThA-0008E7-Mt for sip@ietf.org; Mon, 17 Jan 2005 05:01:13 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0H9lWJD025620 for ; Mon, 17 Jan 2005 02:47:32 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id j0H9iHdV021511 for ; Mon, 17 Jan 2005 03:44:19 -0600 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Jan 2005 15:15:35 +0530 Message-ID: <653138C25D8AD6118292000347080A3714F7A71A@zin05exm02.corp.mot.com> From: Avasarala Ranjit-A20990 To: girish , sip-implementors@cs.columbia.edu, sip@vovida.org, "'sip-ietf'" Subject: RE: [Sip] PoC service indication Date: Mon, 17 Jan 2005 15:15:35 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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="===============0988500669==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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. --===============0988500669== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FC79.4ADF7F60" 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_01C4FC79.4ADF7F60 Content-Type: text/plain This is done using 'p' headers. Refer this draft for more details: draft-allen-sipping-poc-p-headers-00.txt Regards Ranjit -----Original Message----- From: girish [mailto:girish.pai@bhartitelesoft.com] Sent: Monday, January 17, 2005 2:21 PM To: Avasarala Ranjit-A20990; sip-implementors@cs.columbia.edu; sip@vovida.org; 'sip-ietf' Subject: Re: [Sip] PoC service indication Hi Ranjit, Thanks for the explanation on the poc service indication . Could you please tell me how exactly is it indicated in the SIP Message .What is the keyword used to identify the poc service indication Girish Pai Bharti Telesoft Intl Pvt. Ltd. Airport Road Bangalore ----- Original Message ----- From: Avasarala Ranjit-A20990 To: girish ; sip-implementors@cs.columbia.edu ; sip@vovida.org ; 'sip-ietf' Sent: Monday, January 17, 2005 12:13 PM Subject: RE: [Sip] PoC service indication Hi PoC service indication in SIP INVITE message provides the originating user an early indication of start to speak even before invited users accept the invitation. Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of girish Sent: Thursday, January 13, 2005 6:18 PM To: sip-implementors@cs.columbia.edu ; sip@vovida.org ; 'sip-ietf' Subject: [Sip] PoC service indication Hi, What do we mean by PoC service indication in a SIP Message. What does it imply ? Girish Pai Bharti Telesoft Intl Pvt. Ltd. Airport Road Bangalore ------_=_NextPart_001_01C4FC79.4ADF7F60 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S Pg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW PjxTUEFOIGNsYXNzPTczNjQzNDQwOS0xNzAxMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPlRoaXMgDQppcyBkb25lIHVzaW5nICdwJyBoZWFkZXJzLiBSZWZlciB0aGlz IGRyYWZ0IGZvciBtb3JlIGRldGFpbHM6IDxBIA0KaHJlZj0iaHR0cDovL2lldGZyZXBvcnQuaXNv Yy5vcmcvaWRyZWYvZHJhZnQtYWxsZW4tc2lwcGluZy1wb2MtcC1oZWFkZXJzL3JmY21hcmt1cD9y ZXBvc2l0b3J5PS9hd2F5L2lldGYmYW1wO3VybD0vYXdheS9pZXRmL2FsbC1pZHMvZHJhZnQtYWxs ZW4tc2lwcGluZy1wb2MtcC1oZWFkZXJzLTAwLnR4dCI+PEZPTlQgDQpzaXplPTM+ZHJhZnQtYWxs ZW4tc2lwcGluZy1wb2MtcC1oZWFkZXJzLTAwLnR4dDwvRk9OVD48L0E+PEJSPjwvRk9OVD48L1NQ QU4+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48IS0tIENvbnZl cnRlZCBmcm9tIHRleHQvcnRmIGZvcm1hdCAtLT4NCjxQPjxTUEFOIGxhbmc9ZW4tdXM+PEk+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0Kc2l6ZT0yPlJlZ2FyZHM8L0ZPTlQ+PC9JPjwv U1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEk+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMw MDgwODAgc2l6ZT0yPlJhbmppdDwvRk9OVD48L0k+PC9TUEFOPiA8L1A+PEJSPjxCUj4NCjxESVY+ PC9ESVY+DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VGFob21hIA0Kc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBnaXJpc2ggDQpbbWFpbHRvOmdpcmlzaC5wYWlAYmhh cnRpdGVsZXNvZnQuY29tXSA8QlI+PEI+U2VudDo8L0I+IE1vbmRheSwgSmFudWFyeSAxNywgMjAw NSANCjI6MjEgUE08QlI+PEI+VG86PC9CPiBBdmFzYXJhbGEgUmFuaml0LUEyMDk5MDsgc2lwLWlt cGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHU7IA0Kc2lwQHZvdmlkYS5vcmc7ICdzaXAtaWV0Zic8 QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbU2lwXSBQb0Mgc2VydmljZSANCmluZGljYXRpb248QlI+ PEJSPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5IaSBSYW5qaXQsPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyBUaGFua3MgZm9yIHRoZSBleHBs YW5hdGlvbiBvbiB0aGUgcG9jIHNlcnZpY2UgDQppbmRpY2F0aW9uIC4gQ291bGQgeW91IHBsZWFz ZSB0ZWxsIG1lIGhvdyBleGFjdGx5IGlzIGl0IGluZGljYXRlZCBpbiB0aGUgU0lQIA0KTWVzc2Fn ZSAuV2hhdCBpcyB0aGUga2V5d29yZCB1c2VkIHRvIGlkZW50aWZ5IHRoZSBwb2Mgc2VydmljZSAN CmluZGljYXRpb248L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+R2lyaXNoIFBhaTxCUj5CaGFydGkg VGVsZXNvZnQgSW50bCBQdnQuIEx0ZC48QlI+QWlycG9ydCANClJvYWQ8QlI+QmFuZ2Fsb3JlPEJS PjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBw dCBhcmlhbCI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViANCiAg c3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgYXJpYWw7IGZvbnQtY29sb3I6 IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPXJhbmppdEBtb3Rvcm9sYS5jb20gaHJl Zj0ibWFpbHRvOnJhbmppdEBtb3Rvcm9sYS5jb20iPkF2YXNhcmFsYSANCiAgUmFuaml0LUEyMDk5 MDwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlRvOjwvQj4g PEEgDQogIHRpdGxlPWdpcmlzaC5wYWlAYmhhcnRpdGVsZXNvZnQuY29tIA0KICBocmVmPSJtYWls dG86Z2lyaXNoLnBhaUBiaGFydGl0ZWxlc29mdC5jb20iPmdpcmlzaDwvQT4gOyA8QSANCiAgdGl0 bGU9c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgDQogIGhyZWY9Im1haWx0bzpzaXAt aW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSI+c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJp YS5lZHU8L0E+IA0KICA7IDxBIHRpdGxlPXNpcEB2b3ZpZGEub3JnIGhyZWY9Im1haWx0bzpzaXBA dm92aWRhLm9yZyI+c2lwQHZvdmlkYS5vcmc8L0E+IDsgPEEgDQogIHRpdGxlPXNpcEBpZXRmLm9y ZyBocmVmPSJtYWlsdG86c2lwQGlldGYub3JnIj4nc2lwLWlldGYnPC9BPiA8L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+U2VudDo8L0I+IE1vbmRheSwgSmFudWFyeSAx NywgMjAwNSAxMjoxMyANCiAgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlh bCI+PEI+U3ViamVjdDo8L0I+IFJFOiBbU2lwXSBQb0Mgc2VydmljZSANCiAgaW5kaWNhdGlvbjwv RElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz00NTA1NDQwMDYtMTcw MTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+SGk8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ1MDU0NDAwNi0xNzAxMjAwNT48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsg UG9DIHNlcnZpY2UgaW5kaWNhdGlvbiBpbiBTSVAgSU5WSVRFIG1lc3NhZ2UgDQogIHByb3ZpZGVz IHRoZSBvcmlnaW5hdGluZyB1c2VyIGFuIGVhcmx5IGluZGljYXRpb24gb2YmbmJzcDtzdGFydCB0 byZuYnNwO3NwZWFrIA0KICBldmVuIGJlZm9yZSBpbnZpdGVkIHVzZXJzIGFjY2VwdCB0aGUgaW52 aXRhdGlvbi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElW PiZuYnNwOzwvRElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9ydGYgZm9ybWF0IC0tPg0KICA8 UD48U1BBTiBsYW5nPWVuLXVzPjxJPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAg c2l6ZT0yPlJlZ2FyZHM8L0ZPTlQ+PC9JPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEk+ PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwODA4MCBzaXplPTI+UmFuaml0PC9GT05UPjwv ST48L1NQQU4+IDwvUD48QlI+PEJSPg0KICA8RElWPjwvRElWPg0KICA8RElWIGNsYXNzPU91dGxv b2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIA0KICBm YWNlPVRhaG9tYSBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8 L0I+IDxBIA0KICBocmVmPSJtYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1ib3VuY2Vz QGlldGYub3JnPC9BPiANCiAgW21haWx0bzpzaXAtYm91bmNlc0BpZXRmLm9yZ10gPEI+T24gQmVo YWxmIE9mIDwvQj5naXJpc2g8QlI+PEI+U2VudDo8L0I+IA0KICBUaHVyc2RheSwgSmFudWFyeSAx MywgMjAwNSA2OjE4IFBNPEJSPjxCPlRvOjwvQj4gPEEgDQogIGhyZWY9Im1haWx0bzpzaXAtaW1w bGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSI+c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5l ZHU8L0E+OyANCiAgPEEgaHJlZj0ibWFpbHRvOnNpcEB2b3ZpZGEub3JnIj5zaXBAdm92aWRhLm9y ZzwvQT47IA0KICAnc2lwLWlldGYnPEJSPjxCPlN1YmplY3Q6PC9CPiBbU2lwXSBQb0Mgc2Vydmlj ZSANCmluZGljYXRpb248QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsPkhpLDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyZuYnNw OyBXaGF0IGRvIHdlIG1lYW4gYnkgPEZPTlQgc2l6ZT0yPjxGT05UIA0KICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+PC9GT05UPjxTUEFOIGxhbmc9RU4t R0IgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5z aS1sYW5ndWFnZTogRU4tR0I7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGkt bGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgZmFjZT1WZXJkYW5hIHNpemU9Mz5Qb0Mgc2Vydmlj ZSBpbmRpY2F0aW9uJm5ic3A7IGluIGEgU0lQIE1lc3NhZ2UuIFdoYXQgZG9lcyANCiAgaXQgaW1w bHkgPzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBzaXplPTM+PFNQQU4gbGFuZz1FTi1HQiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQjsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IEVOLVVTOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mz48U1BBTiBsYW5nPUVO LUdCIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS b21hbic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFu c2ktbGFuZ3VhZ2U6IEVOLUdCOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRp LWxhbmd1YWdlOiBBUi1TQSI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9O VCBmYWNlPUFyaWFsPkdpcmlzaCBQYWk8QlI+QmhhcnRpIFRlbGVzb2Z0IEludGwgUHZ0LiBMdGQu PEJSPkFpcnBvcnQgDQogIFJvYWQ8QlI+QmFuZ2Fsb3JlPEJSPjwvRk9OVD48L0RJVj48L0JMT0NL UVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C4FC79.4ADF7F60-- --===============0988500669== 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 --===============0988500669==-- From sip-bounces@ietf.org Tue Jan 18 00:24:09 2005 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 AAA29053 for ; Tue, 18 Jan 2005 00:24:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqm5p-0004tj-U0 for sip-web-archive@ietf.org; Tue, 18 Jan 2005 00:39:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqloe-0002TW-Pu; Tue, 18 Jan 2005 00:22:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqlnb-0002OZ-0H for sip@megatron.ietf.org; Tue, 18 Jan 2005 00:21:03 -0500 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 AAA28904 for ; Tue, 18 Jan 2005 00:20:59 -0500 (EST) From: innovation.interops@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqm2l-0004po-RB for sip@ietf.org; Tue, 18 Jan 2005 00:36:45 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 7038B2052D for ; Tue, 18 Jan 2005 10:44:43 +0530 (IST) Received: from blr-ec-bh1.wipro.com (unknown [10.200.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 561ED2052A for ; Tue, 18 Jan 2005 10:44:43 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jan 2005 10:50:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Jan 2005 10:49:42 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFAB@blr-k1-msg.wipro.com> Thread-Topic: Address-of-record not valid for the domain in the Request-URI - Example Thread-Index: AcT9HVDXcv0+Nn6lSnWjt+cpR8pJqg== To: X-OriginalArrivalTime: 18 Jan 2005 05:20:23.0985 (UTC) FILETIME=[698B9210:01C4FD1D] X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] Address-of-record not valid for the domain in the Request-URI - Example 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="===============1323251936==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. --===============1323251936== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FD1D.50E37646" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FD1D.50E37646 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. =20 As per RFC 3261 section 10.3 Registration, REGISTRAR on receipt of a = REGISTER request including a To header from which the extracted = address-of-record is not valid for the domain in the Request-URI, sends = a Request Failure (404 Not Found) response. =20 Is there an example available for this Scenario?? =20 Regds karthikeyan.k =20 =20 =20 ------_=_NextPart_001_01C4FD1D.50E37646 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=
Hello.
=0A=
 
=0A=
As per RFC 3261 section = 10.3 =0A= Registration, REGISTRAR on receipt of a REGISTER request including = a To =0A= header from which the extracted address-of-record is not valid for the = domain in =0A= the Request-URI, sends a Request
Failure (404 Not Found) =0A= response.
=0A=
 
=0A=
Is there an example available for this =0A= Scenario??
=0A=
 
=0A=
Regds
=0A=
karthikeyan.k
=0A=
=0A=

 

=0A=
 
=0A=
 
------_=_NextPart_001_01C4FD1D.50E37646-- --===============1323251936== 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 --===============1323251936==-- From sip-bounces@ietf.org Tue Jan 18 10:52:09 2005 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 KAA04714 for ; Tue, 18 Jan 2005 10:52:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqvtf-0003FU-4A for sip-web-archive@ietf.org; Tue, 18 Jan 2005 11:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvWw-00065r-Jk; Tue, 18 Jan 2005 10:44:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvQY-0004NA-Lg for sip@megatron.ietf.org; Tue, 18 Jan 2005 10:37:54 -0500 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 KAA03080 for ; Tue, 18 Jan 2005 10:37:51 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqvfp-0002kE-Dp for sip@ietf.org; Tue, 18 Jan 2005 10:53:42 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] FW: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 18 Jan 2005 15:37:04 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E533F4@baker.datcon.co.uk> Thread-Topic: [Sip] FW: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt Thread-Index: AcT8+w31Hp+FXzaZTKmu4bB7TAxUBAAZ4vLA From: "Paul D.Smith" To: "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Content-Transfer-Encoding: quoted-printable 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: a4cdc653ecdd96665f2aa1c1af034c9e Content-Transfer-Encoding: quoted-printable Robert, I have added comments in-line below but first a comment about SIPits and SIP software in general. It seems that one of our disconnects is that you, quite rightly, point out that partner implementations shouldn't . You then use this to argue that my software must therefore act in one specific manner based on this assumption that the partner will play nice. Unfortunately, one of the things we hit often is partner implementations that are far from perfect and do all manner of bizarre things. Whilst we always point these out to our customers, we have to bow to their response that "we don't care what implementation X does, why can't you just keep the call up"? Now proving that most implementations at SIPits "play nice" does not mean that the real world is nice. Many implementations never seem to go to SIPits and even different software levels of implementations that do, don't always get things right. This means that our implementation has to be as resilient as possible against bad SIP. I believe Jon Postel said "be conservative in what you send, and liberal in what you receive". I interpret this as "obey the protocol when you send, but don't be surprised if other don't". I still don't agree that a blanket 481 means "the dialog has gone" because that is not what the definitions in RFCs 3262 and 3265 say. They have mangled the definition of 481 to relate to transactions and subscriptions respectively. OK, so where does this leave us? I think we should progress as follows. 1. 481 should not be used to indicate "what was this errant PRACK for"? A new status code should be defined meaning "the dialog was there but I have no outstanding reliable provisional response - your PRACK is in error". RFC3262 must be amended accordingly. This new status code does not cause the dialog to end. 2. 481 should not be used to indicate "this NOTIFY was within a valid dialog but I know nothing about this subscription". A new status code should be defined for this. RFC3265 must be amended accordingly. This new status code does not cause the dialog to end. 3. 481 means one thing, and one thing only. The dialog is not known and as far as everyone is concerned, it no longer exists. For a period of time, 481s may be sent in error and may cause the odd call to be lost but we will live with this. Long term we have a single, clear meaning of 481 and we can get back to more interesting aspects of the protocol. Does this sound like a reasonable way forward? If so, I believe the next step raise this through more specific postings to the WG for further discussion with a view to getting the final decision possible raised in BUGZILLA. Do you agree? Paul D Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 18 January 2005 01:14 To: SIP Public Folder (E-mail) Subject: Re: [Sip] FW: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt On Jan 17, 2005, at 6:48 PM, Paul Kyzivat wrote: > > > Robert Sparks wrote: >> On Jan 17, 2005, at 7:53 AM, Paul D.Smith wrote: > >>> However, RFCs 3262 and 3265 have changed the use of 481 status = codes. >>> RFC3262 states: >>> >>> If a PRACK request is received by the UA core that does not match = >>> any >>> unacknowledged reliable provisional response, the UAS MUST=20 >>> respond to >>> the PRACK with a 481 response. >>> >>> RFC3265 states: >>> >>> Designers of such mechanisms are also >>> warned to make a distinction between sending a NOTIFY message to = a >>> subscriber who is aware of the subscription, and sending a NOTIFY >>> message to an unsuspecting node. The latter behavior is invalid, = >>> and >>> MUST receive a "481 Subscription does not exist" response (unless >>> some other 400- or 500-class error code is more applicable), as >>> described in section 3.2.4. >>> >>> In both of these, the 481 is _NOT_ indicating that the dialog is=20 >>> flawed, >>> rather it is a transaction or subscription specific error. >> A subscription _is_ a usage in a dialog. > > One of potentially several usages. > >> In both of these cases, the dialog should be destroyed. > > Why? That might break another usage. Because the _DIALOG STATE_ is no longer there on the peer you touched. Things like CSeq are not there anymore. Any other usage is already broken. [PDS] What is wrong with CSeq? The previous request failed but so what? My next reINVITE etc. simply increments the CSeq and on the dialog goes. > > Each usage has its own way of timing out, etc. anyway. > It makes much more sense to me to simply destroy the corresponding=20 > usage. If there are then no usages, the dialog can be destroyed. CSeq. Remote target Local target Do I need to go on? > > Of course I know you will bring up that multiple usages per dialog is=20 > evil, but there are still use cases for them. > >> I think you are thinking that if you are working along happily with >> a dialog with identifier A and a message shows up with identifier B >> then dialog A gets destroyed - this is clearly not the case. >> What these requirement cover is when Element 1 thinks it is in >> a dialog with Element 2, and Element 2 disagrees (for whatever=20 >> reason). >> The 481 is the response that lets Element 1 know that things are in=20 >> trouble, >> and they are in trouble at the dialog level. > > Yes, but it is rooted in the fact that 3261 created the concept of=20 > multiple usages per dialog, but mostly pretends that they aren't=20 > there. > > There is clearly a difference between: > - I don't recognize this dialog id > - I don't recognize this subscription on this dialog id > > But there is only one status for them both, and no contextual way to=20 > tell which is the intended meaning. > >>> Now consider my user, busily talking on their SIP phone. The=20 >>> arrival of >>> an errant PRACK or NOTIFY probably has no affect on their call. >> A PRACK with dialog identifers B will never affect the dialog with=20 >> identifier A. >> There is no "probably" here. > > I thought the intended case was a prack within the same dialog. > In this case, PRACK is only meaningful in the context of an invite=20 > usage. So one might assume that getting an errant one implies=20 > something is wrong with your peer in the invite usage. So I can see=20 > killing the invite usage. > > But if there is another usage sharing the same dialog, then while they = > are related (or else they wouldn't be sharing a dialog), they may not=20 > need to be fate shared in this case. > >>> And if >>> it does, then they are in a position to determine this and = terminated >>> the >>> dialog. But the combination of RFC3261, and your assertion that 481 >>> must >>> mean "dialog is terminated" results in their call being dropped,=20 >>> despite >>> there really being no reason why it should. >> Have I seen where you misunderstood the intent? All these = requirements >> indicate that an element receiving a 481 with dialog identifier B=20 >> treats >> dialog B as terminated. This says nothing about any other dialogs = that >> are in play at that endpoint. >> If I haven't understood your concern yet, try again - preferably=20 >> showing an >> example call-flow where you see a problem. > > OK, how about this: > > - A calls B (which perhaps is a conference focus) > this creates a dialog, and an invite usage. > > - within that dialog, A sends a REFER to B, to bring somebody > else into the call. This creates an implicit subscription > (usage) in the same dialog. > > - B starts sending NOTIFYs to A with refer status. > > - The refer completes and B sends A a final notify, > terminating the subscription. > > - A sends a 200 for the final notify. It also destroys > the usage. (But the dialog remains for the invite.) A went non-standard on your second sentence. The transaction will have to complete before it removes the usage (the NOTIFY might get a 401 for example). [PDS] I assume that this is because A should maintain=20 the transaction for a period which allows B to retransmit NOTIFYs. Surely though network interactions might allow a late NOTIFY to arrive after A has given up waiting? Legitimately, A will now send a 481 meaning "no such subcription", but the dialog is perfectly healthy. > > - The 200 is lost in the network. > > - Eventually, B times out the 200 and retransmits the > NOTIFY. > > - A gets the NOTIFY, but has no corresponding usage, so > responds with a 481. A is broken. > > - When B gets the 481 it destroys the complete dialog, > taking down the call. WRONG! No - B has no way to know that what it saw was because A was broken, so it needs to behave as if A legitimately didn't find that dialog state. [PDS] As above, RFC3265 has changed the meaning of 481. It states there is no subscription, not there is no dialog. Can you create an example where one party hasn't violated the protocol and terminating the dialog is the wrong thing to do? > >>> I hope this has got across my concerns regarding "481 means=20 >>> terminated >>> dialog". I appreciate that at least some of this might be tidied up = >>> in >>> later versions of specifications, but SIP hardware is already using=20 >>> the >>> current specifications, and will not adopt new behaviour for some=20 >>> time. >>> Until that time, having all 481 responses cause dialogs to end will >>> contribute to poor perception of SIP hardware as dialogs fail >>> unnecessarily. >> I disagree. This is something we've tested heavily at SIPIts. = Existing >> equipment is following the specifications, and the effect on the=20 >> applications >> is correct. > > Well, maybe not every corner case. > > 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 Jan 18 13:10:24 2005 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 NAA16603 for ; Tue, 18 Jan 2005 13:10:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqy3T-0007Ei-TK for sip-web-archive@ietf.org; Tue, 18 Jan 2005 13:26:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqxdJ-0005Jw-R7; Tue, 18 Jan 2005 12:59:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqxaI-0004fy-Vf for sip@megatron.ietf.org; Tue, 18 Jan 2005 12:56:06 -0500 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 MAA15811 for ; Tue, 18 Jan 2005 12:56:03 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqxpa-0006xM-Nr for sip@ietf.org; Tue, 18 Jan 2005 13:11:56 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0IHu3h5012470 for ; Tue, 18 Jan 2005 18:56:03 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jan 2005 18:56:03 +0100 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YDRM7QAW; Tue, 18 Jan 2005 18:56:02 +0100 Received: from ericsson.com by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA15791; Tue, 18 Jan 2005 18:56:01 +0100 (MET) Message-ID: <41ED4DB1.9040506@ericsson.com> Date: Tue, 18 Jan 2005 18:56:01 +0100 X-Sybari-Trust: c54a342b b8ec86c7 ded7018e 00000139 From: =?ISO-8859-1?Q?P=E9ter_Barta?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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-OriginalArrivalTime: 18 Jan 2005 17:56:03.0326 (UTC) FILETIME=[F9E5F9E0:01C4FD86] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Sip] Sessions in B2BUA 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Dear All, as I understood from RFC 3261 and from various posts of this list, a B2BUA is basically two SIP UAs with no clear definition of how they interact or work together to manage sessions through the B2BUA. Does the B2BUA terminate sessions completely, so sessions are completely independent on the two session legs? If yes, it means that all session related descriptors have to be changed. How does the B2BUA then match the two legs? Is there some parameter that remains unaltered? If, e.g., Call-ID would remain the same then it were easy to correlate the signaling legs, but otherwise the B2BUA has to maintain some kind of mapping to identify that certain legs belong to the same session. Is this behavior specified somewhere? Regards Peter _______________________________________________ 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 Jan 18 13:26:02 2005 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 NAA17760 for ; Tue, 18 Jan 2005 13:26:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqyIc-0007dH-GP for sip-web-archive@ietf.org; Tue, 18 Jan 2005 13:41:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqy0M-0001Os-Ps; Tue, 18 Jan 2005 13:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqxzT-0001Db-NI for sip@megatron.ietf.org; Tue, 18 Jan 2005 13:22:07 -0500 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 NAA17553 for ; Tue, 18 Jan 2005 13:22:03 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqyEk-0007Y7-Qh for sip@ietf.org; Tue, 18 Jan 2005 13:37:55 -0500 Received: from [10.0.1.38] (customer-208-212.pdchawaii.com [66.192.208.212] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0IILwXO020688 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 18 Jan 2005 12:21:59 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E533F4@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F803E533F4@baker.datcon.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] FW: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt Date: Tue, 18 Jan 2005 12:21:48 -0600 To: "Paul D.Smith" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: 7bit 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: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: 7bit You know that I am a strong champion of Postel's Maxim - its a major point we drive home carefully at every SIPIt and is the cornerstone of the open source work I'm involved in. Everyone must work hard to be liberal in what they receive. However, you also have to be aware of the line past which not following the protocol yourself will do more damage. This is a place where it will. Building new protocol, as you suggest below, might be warranted (I respond more favorably for your point on SUBSCRIBE than I do on PRACK because I can think of corner cases (network race conditions) where things following protocol can get into this condition. I'm not yet convinced that ignoring a PRACK to a provisional response you didn't send is a sane thing to do. There is definitely need for clarification through multiple drafts, and I will make the appropriate bugzilla entries. Other comments inline. On Jan 18, 2005, at 9:37 AM, Paul D.Smith wrote: > Robert, > > I have added comments in-line below but first a comment about > SIPits and SIP software in general. It seems that one of our > disconnects is that you, quite rightly, point out that partner > implementations shouldn't choice here>. You then use this to argue that my software > must therefore act in one specific manner based on this > assumption that the partner will play nice. > > Unfortunately, one of the things we hit often is partner > implementations that are far from perfect and do all manner > of bizarre things. Whilst we always point these out to our > customers, we have to bow to their response that "we don't > care what implementation X does, why can't you just keep the > call up"? > > Now proving that most implementations at SIPits "play nice" > does not mean that the real world is nice. Many > implementations never seem to go to SIPits and even different > software levels of implementations that do, don't always get > things right. This means that our implementation has to > be as resilient as possible against bad SIP. > > I believe Jon Postel said "be conservative in what you send, > and liberal in what you receive". I interpret this as > "obey the protocol when you send, but don't be surprised if > other don't". I still don't agree that a blanket 481 > means "the dialog has gone" because that is not what > the definitions in RFCs 3262 and 3265 say. They have > mangled the definition of 481 to relate to transactions > and subscriptions respectively. I completely disagree with your interpretation of 3262 and 3265. Looking at the path you are pointing at below, there may be semantics you would _like_ to have that those don't ask for. > > OK, so where does this leave us? I think we should progress as > follows. > > 1. 481 should not be used to indicate "what was this errant > PRACK for"? A new status code should be defined meaning > "the dialog was there but I have no outstanding reliable > provisional response - your PRACK is in error". RFC3262 > must be amended accordingly. This new status code does > not cause the dialog to end. > > 2. 481 should not be used to indicate "this NOTIFY was within > a valid dialog but I know nothing about this subscription". > A new status code should be defined for this. RFC3265 must > be amended accordingly. This new status code does not > cause the dialog to end. > > 3. 481 means one thing, and one thing only. The dialog is not > known and as far as everyone is concerned, it no longer > exists. Nuance - The 481 means the recipient of the request doesn't know the dialog, and the sender should stop talking to the recipient about it. > > For a period of time, 481s may be sent in error and may cause > the odd call to be lost but we will live with this. Long term > we have a single, clear meaning of 481 and we can get back to > more interesting aspects of the protocol. > > Does this sound like a reasonable way forward? If so, I > believe the next step raise this through more specific > postings to the WG for further discussion with a view to > getting the final decision possible raised in BUGZILLA. > > Do you agree? > > 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: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: 18 January 2005 01:14 > To: SIP Public Folder (E-mail) > Subject: Re: [Sip] FW: [Sipping] I-D > ACTION:draft-ietf-sipping-dialog-package-05.txt > > > > On Jan 17, 2005, at 6:48 PM, Paul Kyzivat wrote: > >> >> >> Robert Sparks wrote: >>> On Jan 17, 2005, at 7:53 AM, Paul D.Smith wrote: >> >>>> However, RFCs 3262 and 3265 have changed the use of 481 status >>>> codes. >>>> RFC3262 states: >>>> >>>> If a PRACK request is received by the UA core that does not match >>>> any >>>> unacknowledged reliable provisional response, the UAS MUST >>>> respond to >>>> the PRACK with a 481 response. >>>> >>>> RFC3265 states: >>>> >>>> Designers of such mechanisms are also >>>> warned to make a distinction between sending a NOTIFY message to >>>> a >>>> subscriber who is aware of the subscription, and sending a NOTIFY >>>> message to an unsuspecting node. The latter behavior is invalid, >>>> and >>>> MUST receive a "481 Subscription does not exist" response (unless >>>> some other 400- or 500-class error code is more applicable), as >>>> described in section 3.2.4. >>>> >>>> In both of these, the 481 is _NOT_ indicating that the dialog is >>>> flawed, >>>> rather it is a transaction or subscription specific error. >>> A subscription _is_ a usage in a dialog. >> >> One of potentially several usages. >> >>> In both of these cases, the dialog should be destroyed. >> >> Why? That might break another usage. > > Because the _DIALOG STATE_ is no longer there on the > peer you touched. Things like CSeq are not there anymore. > Any other usage is already broken. > > [PDS] What is wrong with CSeq? The previous request failed but > so what? My next reINVITE etc. simply increments the CSeq and > on the dialog goes. > >> >> Each usage has its own way of timing out, etc. anyway. >> It makes much more sense to me to simply destroy the corresponding >> usage. If there are then no usages, the dialog can be destroyed. > CSeq. > Remote target > Local target > > Do I need to go on? > >> >> Of course I know you will bring up that multiple usages per dialog is >> evil, but there are still use cases for them. >> >>> I think you are thinking that if you are working along happily with >>> a dialog with identifier A and a message shows up with identifier B >>> then dialog A gets destroyed - this is clearly not the case. >>> What these requirement cover is when Element 1 thinks it is in >>> a dialog with Element 2, and Element 2 disagrees (for whatever >>> reason). >>> The 481 is the response that lets Element 1 know that things are in >>> trouble, >>> and they are in trouble at the dialog level. >> >> Yes, but it is rooted in the fact that 3261 created the concept of >> multiple usages per dialog, but mostly pretends that they aren't >> there. >> >> There is clearly a difference between: >> - I don't recognize this dialog id >> - I don't recognize this subscription on this dialog id >> >> But there is only one status for them both, and no contextual way to >> tell which is the intended meaning. >> >>>> Now consider my user, busily talking on their SIP phone. The >>>> arrival of >>>> an errant PRACK or NOTIFY probably has no affect on their call. >>> A PRACK with dialog identifers B will never affect the dialog with >>> identifier A. >>> There is no "probably" here. >> >> I thought the intended case was a prack within the same dialog. >> In this case, PRACK is only meaningful in the context of an invite >> usage. So one might assume that getting an errant one implies >> something is wrong with your peer in the invite usage. So I can see >> killing the invite usage. >> >> But if there is another usage sharing the same dialog, then while they >> are related (or else they wouldn't be sharing a dialog), they may not >> need to be fate shared in this case. >> >>>> And if >>>> it does, then they are in a position to determine this and >>>> terminated >>>> the >>>> dialog. But the combination of RFC3261, and your assertion that 481 >>>> must >>>> mean "dialog is terminated" results in their call being dropped, >>>> despite >>>> there really being no reason why it should. >>> Have I seen where you misunderstood the intent? All these >>> requirements >>> indicate that an element receiving a 481 with dialog identifier B >>> treats >>> dialog B as terminated. This says nothing about any other dialogs >>> that >>> are in play at that endpoint. >>> If I haven't understood your concern yet, try again - preferably >>> showing an >>> example call-flow where you see a problem. >> >> OK, how about this: >> >> - A calls B (which perhaps is a conference focus) >> this creates a dialog, and an invite usage. >> >> - within that dialog, A sends a REFER to B, to bring somebody >> else into the call. This creates an implicit subscription >> (usage) in the same dialog. >> >> - B starts sending NOTIFYs to A with refer status. >> >> - The refer completes and B sends A a final notify, >> terminating the subscription. >> >> - A sends a 200 for the final notify. It also destroys >> the usage. (But the dialog remains for the invite.) > A went non-standard on your second sentence. The > transaction will have to complete before it removes > the usage (the NOTIFY might get a 401 for example). > > [PDS] I assume that this is because A should maintain > the transaction for a period which allows B to > retransmit NOTIFYs. Surely though network interactions > might allow a late NOTIFY to arrive after A has given > up waiting? Legitimately, A will now send a 481 meaning > "no such subcription", but the dialog is perfectly healthy. > >> >> - The 200 is lost in the network. >> >> - Eventually, B times out the 200 and retransmits the >> NOTIFY. >> >> - A gets the NOTIFY, but has no corresponding usage, so >> responds with a 481. > A is broken. >> >> - When B gets the 481 it destroys the complete dialog, >> taking down the call. WRONG! > No - B has no way to know that what it saw was because A > was broken, so it needs to behave as if A legitimately didn't > find that dialog state. > > [PDS] As above, RFC3265 has changed the meaning of 481. It > states there is no subscription, not there is no dialog. > > Can you create an example where one party hasn't > violated the protocol and terminating the dialog is > the wrong thing to do? > >> >>>> I hope this has got across my concerns regarding "481 means >>>> terminated >>>> dialog". I appreciate that at least some of this might be tidied up >>>> in >>>> later versions of specifications, but SIP hardware is already using >>>> the >>>> current specifications, and will not adopt new behaviour for some >>>> time. >>>> Until that time, having all 481 responses cause dialogs to end will >>>> contribute to poor perception of SIP hardware as dialogs fail >>>> unnecessarily. >>> I disagree. This is something we've tested heavily at SIPIts. >>> Existing >>> equipment is following the specifications, and the effect on the >>> applications >>> is correct. >> >> Well, maybe not every corner case. >> >> 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 Jan 18 15:03:00 2005 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 PAA25314 for ; Tue, 18 Jan 2005 15:03:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzoS-0001gM-8P for sip-web-archive@ietf.org; Tue, 18 Jan 2005 15:18:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqzRN-0002iy-4b; Tue, 18 Jan 2005 14:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqzPh-0002FR-Al for sip@megatron.ietf.org; Tue, 18 Jan 2005 14:53:17 -0500 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 OAA24554 for ; Tue, 18 Jan 2005 14:53:15 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqzf0-0001Pv-Bw for sip@ietf.org; Tue, 18 Jan 2005 15:09:07 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j0IJsUti007117 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 18 Jan 2005 13:54:32 -0600 In-Reply-To: <41ED4DB1.9040506@ericsson.com> References: <41ED4DB1.9040506@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <95883D40-698A-11D9-9DB6-000D93594350@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] Sessions in B2BUA Date: Tue, 18 Jan 2005 13:53:11 -0600 To: =?ISO-8859-1?Q?P=E9ter_Barta?= X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable On Jan 18, 2005, at 11:56 AM, P=E9ter Barta wrote: > Dear All, > > as I understood from RFC 3261 and from various posts of this list, a=20= > B2BUA is basically two SIP UAs with no clear definition of how they=20= > interact or work together to manage sessions through the B2BUA. > That's it precisely. > Does the B2BUA terminate sessions completely, so sessions are=20 > completely independent on the two session legs? If yes, it means that=20= > all session related descriptors have to be changed. How does the B2BUA=20= > then match the two legs? Is there some parameter that remains=20 > unaltered? If, e.g., Call-ID would remain the same then it were easy=20= > to correlate the signaling legs, but otherwise the B2BUA has to=20 > maintain some kind of mapping to identify that certain legs belong to=20= > the same session. > That's up to the B2BUA. Some "hide" the two sessions from each other,=20 perhaps even masking or altering the identities expressed (an=20 "anonymizer") function. Others try to preserve higher-order=20 transparency functions, acting as much like a proxy as they can while=20 still breaking the rules of being a proxy. > Is this behavior specified somewhere? > No. Individual B2BUA implementations may specify their own behavior. This=20 behavior will be contingent on the purpose and mission of the specific=20= B2BUA, as well as the operational requirements, design philosophy, and=20= toolset used for implementation, and quite possibly on the intoxication=20= level of the developer who writes the code. This question keeps coming up. It's no more possible to specify what=20 all B2BUAs do than it is to specify what all possible "C" programs do.=20= It's an unbounded set. It MIGHT be possible to learn from the world of object oriented=20 programming and talk about "B2BUA patterns", meaning archetypal=20 behavior sets that might be used to solve certain classes of problems.=20= This would probably be an interesting doctoral problem for someone who=20= is also interested in software engineering and systems modeling. But=20 I'm not aware of any serious work ongoing on the topic. -- 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 Tue Jan 18 15:34:01 2005 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 PAA29045 for ; Tue, 18 Jan 2005 15:34:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr0IS-0002QM-OS for sip-web-archive@ietf.org; Tue, 18 Jan 2005 15:49:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr01P-0000zY-69; Tue, 18 Jan 2005 15:32:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqzzV-0000EX-CH for sip@megatron.ietf.org; Tue, 18 Jan 2005 15:30:17 -0500 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 PAA28832 for ; Tue, 18 Jan 2005 15:30:15 -0500 (EST) Received: from natpreptil.rzone.de ([81.169.145.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr0Eo-0002LR-JE for sip@ietf.org; Tue, 18 Jan 2005 15:46:08 -0500 Received: from cloudcity.ohlmeier.home (Gab9b.g.pppool.de [80.185.171.155]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j0IKU3Y4021211 for ; Tue, 18 Jan 2005 21:30:03 +0100 (MET) From: Nils Ohlmeier To: sip@ietf.org Date: Tue, 18 Jan 2005 21:30:02 +0100 User-Agent: KMail/1.7.2 X-Dont-Stare: at me Organization: Snom Technologies AG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501182130.02486.nils.ohlmeier@snom.de> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Sip] Running ESC and proxy together 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Hello, section 7. of RFC3903 states that the ESC should include PUBLISH in the Allow header of an OPTIONS reply. But according to RFC3261 a proxy SHOULD omit the Allow header because it usually is able to route any request method. So how should a UAS signal that it accepts PUBLISH as ESC but is also able to route such requests? Or is it simply not desirable to run an ESC and a proxy together and thus we always have to include an "ESC target option" in every UA? Root of the problem: I do not see any other option to check for RFC3903 support then using OPTIONS. Regards Nils Ohlmeier _______________________________________________ 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 Jan 18 16:16:11 2005 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 QAA06514 for ; Tue, 18 Jan 2005 16:16:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr0xI-00055e-Mn for sip-web-archive@ietf.org; Tue, 18 Jan 2005 16:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr08n-0004Z4-OK; Tue, 18 Jan 2005 15:39:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr07S-0003rA-KR; Tue, 18 Jan 2005 15:38:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29509; Tue, 18 Jan 2005 15:38:28 -0500 (EST) Message-Id: <200501182038.PAA29509@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 18 Jan 2005 15:38:28 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-06.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 : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes Filename : draft-ietf-sip-history-info-06.txt Pages : 48 Date : 2005-1-18 This document defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.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-history-info-06.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-history-info-06.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: <2005-1-18160615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-history-info-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-history-info-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-18160615.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 Tue Jan 18 16:37:10 2005 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 QAA09789 for ; Tue, 18 Jan 2005 16:37:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr1Hb-0006BY-TN for sip-web-archive@ietf.org; Tue, 18 Jan 2005 16:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr0zC-0000Jh-BQ; Tue, 18 Jan 2005 16:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr0ws-0006Oy-11 for sip@megatron.ietf.org; Tue, 18 Jan 2005 16:31:38 -0500 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 QAA08948 for ; Tue, 18 Jan 2005 16:31:35 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr1CC-0005wm-Km for sip@ietf.org; Tue, 18 Jan 2005 16:47:29 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0ILV4S26133 for ; Tue, 18 Jan 2005 16:31:04 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jan 2005 16:31:04 -0500 Message-ID: From: "Mary Barnes" To: "'sip@ietf.org'" Subject: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-06.txt Date: Tue, 18 Jan 2005 16:30:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4FDA3.AE4AFD2F" X-Spam-Score: 1.6 (+) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 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.6 (+) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c 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_000_01C4FDA3.AE4AFD2F Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FDA3.AE4AFD2F" ------_=_NextPart_001_01C4FDA3.AE4AFD2F Content-Type: text/plain Hi all, Just to let you know the context of this new version; I received a set of comments just after last call ended, which were not incorporated in the -05 version. They were primarily in the nit category of tightening the specification in preparation for IETF LC/IESG review. The changes are summarized in detail at the back of the document, with the largest change being removing the paragraphs in the security section describing the alternatives such as adding message bodies, AIB and securing inserted information documents. There were no normative changes. The text that was removed had been previously in section 3 (in the -03 version) and had been moved in the -03 to -04 updates to section 6, my thoughts at the time being that it was still useful for informational purposes. However, since it doesn't impact or add any normative value to the History-Info header at this time, it's appropriate and sensible to remove and thus also remove some informational references that are likely to be outdated by the time the document is published as an RFC. Of course, if you do review and see any errors that I may have inadvertently introduced in this last round of edits, please let me know. Thanks, Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, January 18, 2005 2:38 PM To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes Filename : draft-ietf-sip-history-info-06.txt Pages : 48 Date : 2005-1-18 This document defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.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-history-info-06.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-history-info-06.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_001_01C4FDA3.AE4AFD2F Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-06.txt

Hi all,

Just to let you know the context of this new = version;  I received a set of comments just after last call ended, = which were not incorporated in the -05 version.  They were = primarily in the nit category of tightening the specification in = preparation for IETF LC/IESG review.  The changes are summarized = in detail at the back of the document, with the largest change being = removing the paragraphs in the security section describing the = alternatives such as adding message bodies, AIB and securing inserted = information documents.  There were no normative changes. The text = that was removed had been previously in section 3 (in the -03 version) = and had been moved in the -03 to -04 updates to section 6, my thoughts = at the time being that it was still useful for informational = purposes.  However, since it doesn't impact or add any normative = value to the History-Info header at this time, it's appropriate and = sensible to remove and thus also remove some informational references = that are likely to be outdated by the time the document is published as = an RFC.

Of course, if you do review and see any errors that I = may have inadvertently introduced in this last round of edits, please = let me know.

Thanks,
Mary.


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org
Sent: Tuesday, January 18, 2005 2:38 PM
To: i-d-announce@ietf.org
Cc: sip@ietf.org
Subject: [Sip] I-D = ACTION:draft-ietf-sip-history-info-06.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Session Initiation = Protocol Working Group of the IETF.

        Title           : = An Extension to the Session Initiation Protocol
        =         =           for = Request History Information
        Author(s)       : M. = Barnes
        Filename        : = draft-ietf-sip-history-info-06.txt
        Pages           : = 48
        Date    =         : 2005-1-18
       =20
This document defines a standard mechanism for = capturing the history
   information associated with a SIP = request.  This capability enables
   many enhanced services by providing the = information as to how and why
   a call arrives at a specific = application or user.  This document
   defines a new optional SIP header, = History-Info, for capturing the
   history information in requests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-his= tory-info-06.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-history-info-06.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-history-info-06.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C4FDA3.AE4AFD2F-- ------_=_NextPart_000_01C4FDA3.AE4AFD2F Content-Type: application/octet-stream; name="ATT2707975.TXT" Content-Disposition: attachment; filename="ATT2707975.TXT" Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-18160615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-history-info-06.txt ------_=_NextPart_000_01C4FDA3.AE4AFD2F Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-sip-history-info-06.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_000_01C4FDA3.AE4AFD2F Content-Type: text/plain; name="ATT2707976.txt" Content-Disposition: attachment; filename="ATT2707976.txt" _______________________________________________ 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_01C4FDA3.AE4AFD2F 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_000_01C4FDA3.AE4AFD2F-- From sip-bounces@ietf.org Tue Jan 18 18:53:24 2005 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 SAA19881 for ; Tue, 18 Jan 2005 18:53:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr3PS-0000c8-Ug for sip-web-archive@ietf.org; Tue, 18 Jan 2005 19:09:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr39I-0007oR-Pq; Tue, 18 Jan 2005 18:52:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr383-0007Yy-9y for sip@megatron.ietf.org; Tue, 18 Jan 2005 18:51:19 -0500 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 SAA19749 for ; Tue, 18 Jan 2005 18:51:16 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr3NO-0000Z3-JQ for sip@ietf.org; Tue, 18 Jan 2005 19:07:11 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2005 15:57:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0INoiM8026768; Tue, 18 Jan 2005 15:50:45 -0800 (PST) Received: from [10.0.0.204] (rtp-vpn2-268.cisco.com [10.82.241.12]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVR68884; Tue, 18 Jan 2005 15:50:39 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 18 Jan 2005 13:24:27 -1000 Subject: Re: [Sip] Draft defining the Accept-Disposition header field From: Cullen Jennings To: "gonzalo.camarillo@ericsson.com" , "sip@ietf.org" Message-ID: In-Reply-To: <41E519B8.7090700@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit I'm not really sure what the problem is that this solves. Ignoring that, it seems that the dispositions need to be mime specific. For example, I may be able to have a session with SDP but I doubt that just because a UA support render means I can render SDP. Do we have any MIME types where the UA could support that MIME type and more than one disposition would be useful for that MIME type? Cullen On 1/12/05 4:36 AM, "Gonzalo Camarillo" wrote: > Folks, > > I have submitted a draft that defines the Accept-Disposition header > field. The usage of this header field would be similar to the usage of > Accept, Accept-Encoding, or Accept-Language, but it would indicate > support for disposition types. > > http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept-disposition-00. > txt > > Your comments are welcome. > > Thanks, > > Gonzalo > > > > _______________________________________________ > 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 Jan 18 19:28:01 2005 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 TAA22335 for ; Tue, 18 Jan 2005 19:28:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr3wz-0001RQ-JL for sip-web-archive@ietf.org; Tue, 18 Jan 2005 19:43:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr3g8-0006pj-GQ; Tue, 18 Jan 2005 19:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr3e3-0006Bf-4X for sip@megatron.ietf.org; Tue, 18 Jan 2005 19:24:23 -0500 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 TAA22106 for ; Tue, 18 Jan 2005 19:24:19 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr3tO-0001LB-DC for sip@ietf.org; Tue, 18 Jan 2005 19:40:16 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2005 16:24:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j0J0NlRO022662; Tue, 18 Jan 2005 16:23:48 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOK70933; Tue, 18 Jan 2005 19:23:46 -0500 (EST) Message-ID: <41EDA892.40509@cisco.com> Date: Tue, 18 Jan 2005 19:23:46 -0500 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: Cullen Jennings Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "gonzalo.camarillo@ericsson.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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I'm not really sure what the problem is that this solves. > > Ignoring that, it seems that the dispositions need to be mime specific. For > example, I may be able to have a session with SDP but I doubt that just > because a UA support render means I can render SDP. > > Do we have any MIME types where the UA could support that MIME type and more > than one disposition would be useful for that MIME type? application/sdp: session & early-session application/sipfrag: render? (for refer notifies), ??? (for smime) text/plain: render (for MESSAGE), alert, ... image/*: render (for MESSAGE), icon multipart/*: what disposition are these supposed to get??? 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 Jan 19 09:45:02 2005 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 JAA17309 for ; Wed, 19 Jan 2005 09:45:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrHKR-000470-Vq for sip-web-archive@ietf.org; Wed, 19 Jan 2005 10:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrH0c-0005Qs-IC; Wed, 19 Jan 2005 09:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrGya-00055H-8e for sip@megatron.ietf.org; Wed, 19 Jan 2005 09:38:28 -0500 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 JAA16657 for ; Wed, 19 Jan 2005 09:38:26 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrHE2-0003uz-Sd for sip@ietf.org; Wed, 19 Jan 2005 09:54:28 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id B51D2A9698; Wed, 19 Jan 2005 15:37:53 +0100 (CET) Received: from [192.168.1.27] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id 9FC11A9683; Wed, 19 Jan 2005 15:37:52 +0100 (CET) In-Reply-To: References: <53F74F5A7B94D511841C00B0D0AB16F803E533F4@baker.datcon.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] FW: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt Date: Wed, 19 Jan 2005 15:37:51 +0100 To: Robert Sparks X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: SIP WG , "Paul D.Smith" 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 Content-Transfer-Encoding: 7bit On Jan 18, 2005, at 7:21 PM, Robert Sparks wrote: > >> >> OK, so where does this leave us? I think we should progress as >> follows. >> >> 1. 481 should not be used to indicate "what was this errant >> PRACK for"? A new status code should be defined meaning >> "the dialog was there but I have no outstanding reliable >> provisional response - your PRACK is in error". RFC3262 >> must be amended accordingly. This new status code does >> not cause the dialog to end. >> >> 2. 481 should not be used to indicate "this NOTIFY was within >> a valid dialog but I know nothing about this subscription". >> A new status code should be defined for this. RFC3265 must >> be amended accordingly. This new status code does not >> cause the dialog to end. >> >> 3. 481 means one thing, and one thing only. The dialog is not >> known and as far as everyone is concerned, it no longer >> exists. > Nuance - > The 481 means the recipient of the request doesn't know the dialog, > and the sender should stop talking to the recipient about it. > Robert, I agree with you here, but you need to consider the dialog stateful intermediaries in the case that an endpoint no longer knows about a dialog and sends a 481. Should the dialog stateful intermediaries terminate that dialog abnormally or should they wait for the BYE coming from the originator. I suggest the former. Any statistics on what current dialog stateful proxy implementations do? Regards, Hisham _______________________________________________ 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 Jan 19 11:38:06 2005 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 LAA26880 for ; Wed, 19 Jan 2005 11:38:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrJ5t-0006z8-PM for sip-web-archive@ietf.org; Wed, 19 Jan 2005 11:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrIhj-0007du-Uw; Wed, 19 Jan 2005 11:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrIhA-0007IA-Hn for sip@megatron.ietf.org; Wed, 19 Jan 2005 11:28:36 -0500 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 LAA26223 for ; Wed, 19 Jan 2005 11:28:34 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrIwf-0006jX-Je for sip@ietf.org; Wed, 19 Jan 2005 11:44:38 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0JGSXwo007968 for ; Wed, 19 Jan 2005 10:28:33 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Jan 2005 11:28:33 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC2C7@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'Cullen Jennings'" , "gonzalo.camarillo@ericsson.com" , sip@ietf.org Subject: RE: [Sip] Draft defining the Accept-Disposition header field Date: Wed, 19 Jan 2005 11:28:32 -0500 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: d185fa790257f526fedfd5d01ed9c976 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: 73734d43604d52d23b3eba644a169745 A formal specification of the Acceptable Disposition types is useful. I do not necessarily agree that the proposed way is the best way to do it. The Accept-Disposition needs to be associated with the corresponding Acceped Content Types. A Accept-Disposition header by itself will not be effective unless there is an associated Content Type specififed. I think that an effective way to specify the Disposition is to Change the Accept Header to also specify a required implicit/explicit Disposition Type. Example: Accept:application/sdp;session Thanks, Shekar > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, January 18, 2005 6:24 PM > To: gonzalo.camarillo@ericsson.com; sip@ietf.org > Subject: Re: [Sip] Draft defining the Accept-Disposition header field > > > > > I'm not really sure what the problem is that this solves. > > Ignoring that, it seems that the dispositions need to be mime > specific. For > example, I may be able to have a session with SDP but I doubt > that just > because a UA support render means I can render SDP. > > Do we have any MIME types where the UA could support that > MIME type and more > than one disposition would be useful for that MIME type? > > > Cullen > > > On 1/12/05 4:36 AM, "Gonzalo Camarillo" > > wrote: > > > Folks, > > > > I have submitted a draft that defines the Accept-Disposition header > > field. The usage of this header field would be similar to > the usage of > > Accept, Accept-Encoding, or Accept-Language, but it would indicate > > support for disposition types. > > > > > http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept -disposition-00. > txt > > Your comments are welcome. > > Thanks, > > Gonzalo > > > > _______________________________________________ > 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 Wed Jan 19 15:17:55 2005 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 PAA17801 for ; Wed, 19 Jan 2005 15:17:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrMWe-0004YZ-34 for sip-web-archive@ietf.org; Wed, 19 Jan 2005 15:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrMFM-00052c-1t; Wed, 19 Jan 2005 15:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrMDv-0003ZT-3n for sip@megatron.ietf.org; Wed, 19 Jan 2005 15:14:39 -0500 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 PAA17230 for ; Wed, 19 Jan 2005 15:14:37 -0500 (EST) 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 1CrMTS-0004Ns-2c for sip@ietf.org; Wed, 19 Jan 2005 15:30:42 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2005 12:18:44 -0800 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 j0JKE4l2017655; Wed, 19 Jan 2005 12:14:05 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOL33855; Wed, 19 Jan 2005 15:14:03 -0500 (EST) Message-ID: <41EEBF8A.8000708@cisco.com> Date: Wed, 19 Jan 2005 15:14:02 -0500 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: "Shekar, Nagesh Soma (Shekar)** CTR **" Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC2C7@oh0012exch004u.cb.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , sip@ietf.org, "gonzalo.camarillo@ericsson.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: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > A formal specification of the Acceptable Disposition types is > useful. I do not necessarily agree that the proposed way is the > best way to do it. > > The Accept-Disposition needs to be associated with the corresponding > Acceped Content Types. A Accept-Disposition header by itself will not > be effective unless there is an associated Content Type specififed. > > I think that an effective way to specify the Disposition is to > Change the Accept Header to also specify a required implicit/explicit > Disposition Type. > > Example: > > Accept:application/sdp;session Seems somewhat appealing. Because parameters are already accepted, I don't think the above way of using parameters is ideal - its confusing about the role of the parameter, and runs risk of conflicting with other parameter usages, and would need to be updated every time a new disposition was invented. Instead, perhaps: Accept:application/sdp;disposition="session,early-session" Accept:multipart/mixed;disposition="*" It might also be necessary to allow: Accept:text/*;disposition="render", text/plain;disposition="alert" For backward compatibility, probably need to say that default for disposition parameter is "*". Paul >>-----Original Message----- >>From: Cullen Jennings [mailto:fluffy@cisco.com] >>Sent: Tuesday, January 18, 2005 6:24 PM >>To: gonzalo.camarillo@ericsson.com; sip@ietf.org >>Subject: Re: [Sip] Draft defining the Accept-Disposition header field >> >> >> >> >>I'm not really sure what the problem is that this solves. >> >>Ignoring that, it seems that the dispositions need to be mime >>specific. For >>example, I may be able to have a session with SDP but I doubt >>that just >>because a UA support render means I can render SDP. >> >>Do we have any MIME types where the UA could support that >>MIME type and more >>than one disposition would be useful for that MIME type? >> >> >>Cullen >> >> >>On 1/12/05 4:36 AM, "Gonzalo Camarillo" >> >>wrote: >> >> >>>Folks, >>> >>>I have submitted a draft that defines the Accept-Disposition header >>>field. The usage of this header field would be similar to >> >>the usage of >> >>>Accept, Accept-Encoding, or Accept-Language, but it would indicate >>>support for disposition types. >>> >>> >> >>http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept > > -disposition-00. > >>txt >> >>Your comments are welcome. >> >>Thanks, >> >>Gonzalo >> >> >> >>_______________________________________________ >>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 Wed Jan 19 16:24:18 2005 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 QAA26332 for ; Wed, 19 Jan 2005 16:24:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrNYu-0007W2-8M for sip-web-archive@ietf.org; Wed, 19 Jan 2005 16:40:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrNDX-0008W4-KE; Wed, 19 Jan 2005 16:18:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrNBx-0007GT-PK for sip@megatron.ietf.org; Wed, 19 Jan 2005 16:16:41 -0500 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 QAA25683 for ; Wed, 19 Jan 2005 16:16:39 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrNRV-0007Hz-2s for sip@ietf.org; Wed, 19 Jan 2005 16:32:45 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0JLGbh5006750; Wed, 19 Jan 2005 22:16:37 +0100 (MET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jan 2005 22:16:37 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jan 2005 22:16:36 +0100 Received: from ericsson.com (rvi2-94-227.sw.ericsson.se [153.88.94.227]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CD41C189CC; Wed, 19 Jan 2005 23:16:33 +0200 (EET) Message-ID: <41EECE31.109@ericsson.com> Date: Wed, 19 Jan 2005 23:16:33 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: <41EEBF8A.8000708@cisco.com> In-Reply-To: <41EEBF8A.8000708@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2005 21:16:36.0957 (UTC) FILETIME=[28EA18D0:01C4FE6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , 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: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Hi, yes, there is a trade-off here. On the one hand, we can just list the disposition types supported by the client, as defined in the draft. This has the advantage of efficiency (each disposition type is listed only once). On the other hand, we can associate each disposition type with the content type it applies to. This is not so efficient (disposition types that apply to more than one content type will be listed more than one), but it provides more accurate information. If folks feel that having better accuracy is important, we should definitively go for the second option. Regards, Gonzalo Paul Kyzivat wrote: > > Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > >>A formal specification of the Acceptable Disposition types is >>useful. I do not necessarily agree that the proposed way is the >>best way to do it. >> >>The Accept-Disposition needs to be associated with the corresponding >>Acceped Content Types. A Accept-Disposition header by itself will not >>be effective unless there is an associated Content Type specififed. >> >>I think that an effective way to specify the Disposition is to >>Change the Accept Header to also specify a required implicit/explicit >>Disposition Type. >> >>Example: >> >>Accept:application/sdp;session > > > Seems somewhat appealing. Because parameters are already accepted, I > don't think the above way of using parameters is ideal - its confusing > about the role of the parameter, and runs risk of conflicting with other > > parameter usages, and would need to be updated every time a new > disposition was invented. Instead, perhaps: > > Accept:application/sdp;disposition="session,early-session" > Accept:multipart/mixed;disposition="*" > > It might also be necessary to allow: > > Accept:text/*;disposition="render", > text/plain;disposition="alert" > > For backward compatibility, probably need to say that default for > disposition parameter is "*". > > Paul > > >>>-----Original Message----- >>>From: Cullen Jennings [mailto:fluffy@cisco.com] >>>Sent: Tuesday, January 18, 2005 6:24 PM >>>To: gonzalo.camarillo@ericsson.com; sip@ietf.org >>>Subject: Re: [Sip] Draft defining the Accept-Disposition header field >>> >>> >>> >>> >>>I'm not really sure what the problem is that this solves. >>> >>>Ignoring that, it seems that the dispositions need to be mime >>>specific. For >>>example, I may be able to have a session with SDP but I doubt >>>that just >>>because a UA support render means I can render SDP. >>> >>>Do we have any MIME types where the UA could support that >>>MIME type and more >>>than one disposition would be useful for that MIME type? >>> >>> >>>Cullen >>> >>> >>>On 1/12/05 4:36 AM, "Gonzalo Camarillo" >>> >>>wrote: >>> >>> >>> >>>>Folks, >>>> >>>>I have submitted a draft that defines the Accept-Disposition header >>>>field. The usage of this header field would be similar to >>> >>>the usage of >>> >>> >>>>Accept, Accept-Encoding, or Accept-Language, but it would indicate >>>>support for disposition types. >>>> >>>> >>> >>>http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept >> >>-disposition-00. >> >> >>>txt >>> >>>Your comments are welcome. >>> >>>Thanks, >>> >>>Gonzalo >>> >>> >>> >>>_______________________________________________ >>>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 >> -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ 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 Jan 19 17:00:57 2005 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 RAA01641 for ; Wed, 19 Jan 2005 17:00:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrO8N-0000d4-FZ for sip-web-archive@ietf.org; Wed, 19 Jan 2005 17:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrNqK-0006TL-3r; Wed, 19 Jan 2005 16:58:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrNop-00060Y-4g for sip@megatron.ietf.org; Wed, 19 Jan 2005 16:56:51 -0500 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 QAA01360 for ; Wed, 19 Jan 2005 16:56:48 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrO4M-0000W9-VD for sip@ietf.org; Wed, 19 Jan 2005 17:12:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2005 14:03:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j0JLuGl2013094; Wed, 19 Jan 2005 13:56:17 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOL43959; Wed, 19 Jan 2005 16:56:14 -0500 (EST) Message-ID: <41EED77E.2020301@cisco.com> Date: Wed, 19 Jan 2005 16:56:14 -0500 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: Gonzalo Camarillo Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: <41EEBF8A.8000708@cisco.com> <41EECE31.109@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , 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: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hi, > > yes, there is a trade-off here. On the one hand, we can just list the > disposition types supported by the client, as defined in the draft. This > has the advantage of efficiency (each disposition type is listed only > once). On the other hand, we can associate each disposition type with > the content type it applies to. This is not so efficient (disposition > types that apply to more than one content type will be listed more than > one), but it provides more accurate information. > > If folks feel that having better accuracy is important, we should > definitively go for the second option. For some purposes the less accurate approach might be sufficient to give a hint of what is possible and what isn't. But I am concerned about one of the key uses of these headers - reporting what is accepted as part of a response saying that something isn't accepted. It is not good form to reject a message and yet say that you support the content type and disposition it contained. Getting both accuracy and efficiency seems difficult. I think the key may be in defining the scope over which these declarations apply, and what is meant when something has not been specified. Then perhaps it would only be necessary to be precise in the error response to an unsupported usage. BTW, now that I think about it more, the notation problem is more complex - really need to specify the supported triples of type,disposition,message. And even that leaves out responses. Its harder to cram all of that into a parameter syntax. Part of this could be dealt with by a new error code that means the particular combination of types and dispositions in the request was not supported. However that only works for requests. It doesn't give a way to indicate what combinations can/can't be used in *responses*. Paul > Regards, > > Gonzalo > > > > Paul Kyzivat wrote: > >> >> Shekar, Nagesh Soma (Shekar)** CTR ** wrote: >> >>> A formal specification of the Acceptable Disposition types is >>> useful. I do not necessarily agree that the proposed way is the best >>> way to do it. >>> >>> The Accept-Disposition needs to be associated with the corresponding >>> Acceped Content Types. A Accept-Disposition header by itself will not >>> be effective unless there is an associated Content Type specififed. >>> I think that an effective way to specify the Disposition is to >>> Change the Accept Header to also specify a required implicit/explicit >>> Disposition Type. >>> >>> Example: >>> Accept:application/sdp;session >> >> >> >> Seems somewhat appealing. Because parameters are already accepted, I >> don't think the above way of using parameters is ideal - its confusing >> about the role of the parameter, and runs risk of conflicting with other >> >> parameter usages, and would need to be updated every time a new >> disposition was invented. Instead, perhaps: >> >> Accept:application/sdp;disposition="session,early-session" >> Accept:multipart/mixed;disposition="*" >> >> It might also be necessary to allow: >> >> Accept:text/*;disposition="render", >> text/plain;disposition="alert" >> >> For backward compatibility, probably need to say that default for >> disposition parameter is "*". >> >> Paul >> >> >>>> -----Original Message----- >>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>> Sent: Tuesday, January 18, 2005 6:24 PM >>>> To: gonzalo.camarillo@ericsson.com; sip@ietf.org >>>> Subject: Re: [Sip] Draft defining the Accept-Disposition header field >>>> >>>> >>>> >>>> >>>> I'm not really sure what the problem is that this solves. >>>> >>>> Ignoring that, it seems that the dispositions need to be mime >>>> specific. For >>>> example, I may be able to have a session with SDP but I doubt that just >>>> because a UA support render means I can render SDP. >>>> >>>> Do we have any MIME types where the UA could support that MIME type >>>> and more >>>> than one disposition would be useful for that MIME type? >>>> >>>> >>>> Cullen >>>> >>>> >>>> On 1/12/05 4:36 AM, "Gonzalo Camarillo" >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Folks, >>>>> >>>>> I have submitted a draft that defines the Accept-Disposition header >>>>> field. The usage of this header field would be similar to >>>> >>>> >>>> the usage of >>>> >>>> >>>>> Accept, Accept-Encoding, or Accept-Language, but it would indicate >>>>> support for disposition types. >>>>> >>>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept >>> >>> >>> -disposition-00. >>> >>> >>>> txt >>>> >>>> Your comments are welcome. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Wed Jan 19 22:42:07 2005 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 WAA28723 for ; Wed, 19 Jan 2005 22:42:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTSa-0000GV-H7 for sip-web-archive@ietf.org; Wed, 19 Jan 2005 22:58:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrT9x-000466-Ji; Wed, 19 Jan 2005 22:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrT6I-0003YZ-7o for sip@megatron.ietf.org; Wed, 19 Jan 2005 22:35:14 -0500 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 WAA27740 for ; Wed, 19 Jan 2005 22:35:11 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTLs-0008UP-8J for sip@ietf.org; Wed, 19 Jan 2005 22:51:21 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2005 19:33:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0K3WRRO011020; Wed, 19 Jan 2005 19:32:27 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.88.131 10.21.88.131 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 19 Jan 2005 17:32:28 -1000 Subject: Re: [Sip] Draft defining the Accept-Disposition header field From: Cullen Jennings To: Cullen Jennings , "gonzalo.camarillo@ericsson.com" , "sip@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit On 1/18/05 1:24 PM, "Cullen Jennings" wrote: > I'm not really sure what the problem is that this solves. I like how the discussion is going on *how* to do this but I'm still missing the *why* to do it. I'm failing to imagine when this problem comes up. _______________________________________________ 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 Jan 20 00:30:04 2005 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 AAA07442 for ; Thu, 20 Jan 2005 00:30:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrV94-00033s-Mj for sip-web-archive@ietf.org; Thu, 20 Jan 2005 00:46:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrUpJ-0008Ac-8i; Thu, 20 Jan 2005 00:25:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrUg6-00053b-Vw for sip@megatron.ietf.org; Thu, 20 Jan 2005 00:16:19 -0500 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 AAA06384 for ; Thu, 20 Jan 2005 00:16:16 -0500 (EST) 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 1CrUvi-0002fU-1D for sip@ietf.org; Thu, 20 Jan 2005 00:32:27 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Jan 2005 22:23:28 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0K5FhNt027816; Wed, 19 Jan 2005 21:15:44 -0800 (PST) Received: from cisco.com (rtp-vpn2-145.cisco.com [10.82.240.145]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOL67521; Thu, 20 Jan 2005 00:15:42 -0500 (EST) Message-ID: <41EF3E7E.9070302@cisco.com> Date: Thu, 20 Jan 2005 00:15:42 -0500 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: Cullen Jennings Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "gonzalo.camarillo@ericsson.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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 1/18/05 1:24 PM, "Cullen Jennings" wrote: > > >>I'm not really sure what the problem is that this solves. > > > I like how the discussion is going on *how* to do this but I'm still missing > the *why* to do it. I'm failing to imagine when this problem comes up. Well, I think most of this ultimately is just debugging info. In principle a UA could change its behavior based on what it learns from these kinds of headers. But how much of that really happens. While I think this kind of info is useful to fill in the logical holes in the protocol, I am more interested in carefully defining all the currently underdefined behaviors wrt disposition. 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 Thu Jan 20 01:47:21 2005 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 BAA12594 for ; Thu, 20 Jan 2005 01:47:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrWLq-0004po-PG for sip-web-archive@ietf.org; Thu, 20 Jan 2005 02:03:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrW3w-0003CP-HW; Thu, 20 Jan 2005 01:45:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrW2m-0002y7-4r for sip@megatron.ietf.org; Thu, 20 Jan 2005 01:43:49 -0500 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 BAA12436 for ; Thu, 20 Jan 2005 01:43:47 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrWIN-0004jV-Jj for sip@ietf.org; Thu, 20 Jan 2005 01:59:57 -0500 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 j0K6heO6029226 for ; Thu, 20 Jan 2005 07:43:40 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jan 2005 07:43:40 +0100 Received: from ericsson.com (EFO9N000L5C7100 [150.236.158.56]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAPGFRV5; Thu, 20 Jan 2005 07:43:39 +0100 Message-ID: <41EF5316.6030705@ericsson.com> Date: Thu, 20 Jan 2005 08:43:34 +0200 X-Sybari-Trust: 85d828c7 8bd604a9 2b828a67 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2005 06:43:40.0196 (UTC) FILETIME=[60585E40:01C4FEBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Paul Kyzivat 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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi, > I'm not really sure what the problem is that this solves. it lets a UA know whether the remote UA supports a particular disposition type. Right now, UAs guess this information based on the support for MIME types. For example, if the remote UA supports application/sdp, my UA assumes that the remote UA supports the 'session' disposition type... but what about 'early-session'? The same thing with uri-list bodies. A conference server may support uri-list bodies for some reason, but may not support the 'recipient-list' disposition type. The disposition type is what tells me that the conference server supports (or does not support) the feature I want to use. (So far there are two disposition types associated with uri-list bodies and may be more in the future.) Regarding debugging, the UAC can know what went wrong when it received a 415 response from a UAS that supports all the MIME types needed for the service. In this sense, the draft completes the procedures defined in RFC 3204 regarding rejection of body parts whose handling is required. The thing is that, as it has been pointed out in this thread, disposition types are usually supported in relation with a particular MIME type and even a particular method (e.g., a server is a message URI-list service but does not support the 'recipient-list' disposition type for INVITEs). The solution proposed in the draft follows the definition of the existing Allow and Accept header fields in the sense that they do not provide cross header information: Allow tells you which methods are supported and Accept which MIME types, but there is no info about which MIME type is acceptable for which method. We need to decide if this is good enough or if we want to introduce some level of cross header information in the solution. Regards, Gonzalo _______________________________________________ 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 Jan 20 02:03:26 2005 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 CAA15875 for ; Thu, 20 Jan 2005 02:03:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrWbR-0005AL-30 for sip-web-archive@ietf.org; Thu, 20 Jan 2005 02:19:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrWKm-0006J7-5f; Thu, 20 Jan 2005 02:02:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrWJl-0005wx-5F for sip@megatron.ietf.org; Thu, 20 Jan 2005 02:01:21 -0500 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 CAA14121 for ; Thu, 20 Jan 2005 02:01:18 -0500 (EST) Received: from mail.deccanetworld.com ([203.196.146.50] helo=gatekeeper.deccanetworld.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrWZJ-00058J-7w for sip@ietf.org; Thu, 20 Jan 2005 02:17:29 -0500 Received: from gatekeeper.deccanetworld.com (localhost [127.0.0.1]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id j0K6nOjd008419 for ; Thu, 20 Jan 2005 12:19:24 +0530 Received: from mail.deccanetworld.com (server.deccanetworld.com [192.168.1.32]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id j0K6nLRq008300 for ; Thu, 20 Jan 2005 12:19:21 +0530 Received: from bgcw0113 ([10.203.106.200]) by mail.deccanetworld.com (8.11.0/8.11.0) with SMTP id j0K7JtX22917 for ; Thu, 20 Jan 2005 12:49:55 +0530 From: "Vishnu Yadav" To: Date: Thu, 20 Jan 2005 12:25:09 +0530 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200501191706.j0JH6WRq020375@gatekeeper.deccanetworld.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Sip] 183 progress & 190 ringing 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi All, I have a doubt on usage & handling of 183 & 180. 1. What is difference between 180 & 183? Why 183 needed ? 2. What is the order in which we get both of these responses? I mean to say, we get 183 then we get 180 or in some other ways. 3. Is 183 progress sent by proxy or UAS? Can B2BUA send 183 to UAC? Thanks in advance. Vishnu Yadav _______________________________________________ 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 Jan 20 02:55:52 2005 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 CAA02438 for ; Thu, 20 Jan 2005 02:55:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrXQB-0006Pu-IA for sip-web-archive@ietf.org; Thu, 20 Jan 2005 03:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrX91-0003J9-2E; Thu, 20 Jan 2005 02:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrX5S-0002mk-DH for sip@megatron.ietf.org; Thu, 20 Jan 2005 02:50:38 -0500 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 CAA01993 for ; Thu, 20 Jan 2005 02:50:33 -0500 (EST) Received: from vmail.vsnl.com ([203.199.113.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrXL0-0006Fj-Qx for sip@ietf.org; Thu, 20 Jan 2005 03:06:44 -0500 Received: from rajeewsingh ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0IAL00IT2V3CM4@vmail.vsnl.com> for sip@ietf.org; Thu, 20 Jan 2005 13:20:00 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.169.100)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Thu, 20 Jan 2005 13:20:00 +0530 (IST) Date: Thu, 20 Jan 2005 13:20:30 +0530 From: Rajeew Kumar Singh Subject: RE: [Sip] 183 progress & 190 ringing In-reply-to: To: "'Vishnu Yadav'" , sip@ietf.org Message-id: <003401c4fec4$b7523640$2a46010a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Reply-To: rajeewsingh@tataelxsi.co.in 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 One use of 183 is while dealing with SIP to PSTN Interworking. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Vishnu Yadav Sent: Thursday, January 20, 2005 12:25 PM To: sip@ietf.org Subject: [Sip] 183 progress & 190 ringing Hi All, I have a doubt on usage & handling of 183 & 180. 1. What is difference between 180 & 183? Why 183 needed ? 2. What is the order in which we get both of these responses? I mean to say, we get 183 then we get 180 or in some other ways. 3. Is 183 progress sent by proxy or UAS? Can B2BUA send 183 to UAC? Thanks in advance. Vishnu Yadav _______________________________________________ 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 Jan 20 05:00:14 2005 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 FAA11699 for ; Thu, 20 Jan 2005 05:00:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrZMZ-0001Je-HK for sip-web-archive@ietf.org; Thu, 20 Jan 2005 05:16:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrZ4E-00077a-Dd; Thu, 20 Jan 2005 04:57:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrZ1e-0006dt-1W for sip@megatron.ietf.org; Thu, 20 Jan 2005 04:54:50 -0500 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 EAA11400 for ; Thu, 20 Jan 2005 04:54:47 -0500 (EST) From: innovation.interops@wipro.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrZGb-00018J-0Q for sip@ietf.org; Thu, 20 Jan 2005 05:10:18 -0500 Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CrYlL-0006ux-Re for sip@ietf.org; Thu, 20 Jan 2005 04:38:00 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 621502053F for ; Thu, 20 Jan 2005 15:00:28 +0530 (IST) Received: from blr-ec-bh1.wipro.com (unknown [10.200.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 422162053B for ; Thu, 20 Jan 2005 15:00:28 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jan 2005 15:06:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jan 2005 15:06:08 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFAD@blr-k1-msg.wipro.com> Thread-Topic: CSEQ Number in ACK to 2xx Response for INVITE??? Thread-Index: AcT+03iLTNJqmtv3TbC652Qvhid/Vg== To: X-OriginalArrivalTime: 20 Jan 2005 09:36:11.0785 (UTC) FILETIME=[7A5F7F90:01C4FED3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [Sip] CSEQ Number in ACK to 2xx Response for INVITE??? 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="===============0373433532==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 This is a multi-part message in MIME format. --===============0373433532== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FED3.7894EB58" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FED3.7894EB58 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, =20 In section 13.2.2.4 2xx Responses,it is mentioned that while generating = an ACK for a 2xx response should have same CSeq number as in INVITE but = the method as ACK. =20 But is mentioned in Definition section that ACK for a 2xx response to an = INVITE request is a separate transaction.Does it mean that CSEQ number = to be incremented? =20 Regds karthikeyan.k ------_=_NextPart_001_01C4FED3.7894EB58 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=0A=

Hello =0A= all,

=0A=

 

=0A=

In = section =0A= 13.2.2.4 2xx Responses,it is mentioned that while =0A= generating an ACK for a 2xx response should have same CSeq number = as in =0A= INVITE but the method as ACK.

=0A=

 

=0A=

But = is =0A= mentioned in Definition section that ACK for a =0A= 2xx response to an INVITE request is a separate =0A= transaction.Does it mean that CSEQ number to be = incremented?

=0A=

 

=0A=

Regds

=0A=

karthikeyan.k

------_=_NextPart_001_01C4FED3.7894EB58-- --===============0373433532== 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 --===============0373433532==-- From sip-bounces@ietf.org Thu Jan 20 05:58:25 2005 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 FAA15569 for ; Thu, 20 Jan 2005 05:58:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CraGs-0002gC-KR for sip-web-archive@ietf.org; Thu, 20 Jan 2005 06:14:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cra07-0007ea-K0; Thu, 20 Jan 2005 05:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrZqG-0006ZA-Bd for sip@megatron.ietf.org; Thu, 20 Jan 2005 05:47:08 -0500 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 FAA14937 for ; Thu, 20 Jan 2005 05:47:05 -0500 (EST) Received: from vmail.vsnl.com ([203.199.113.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cra5t-0002PF-S6 for sip@ietf.org; Thu, 20 Jan 2005 06:03:19 -0500 Received: from rajeewsingh ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0IAM0000P39LEK@vmail.vsnl.com> for sip@ietf.org; Thu, 20 Jan 2005 16:16:34 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.169.100)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Thu, 20 Jan 2005 16:16:34 +0530 (IST) Date: Thu, 20 Jan 2005 16:16:55 +0530 From: Rajeew Kumar Singh Subject: RE: [Sip] CSEQ Number in ACK to 2xx Response for INVITE??? In-reply-to: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFAD@blr-k1-msg.wipro.com> To: innovation.interops@wipro.com, sip@ietf.org Message-id: <004001c4fedd$610fa7e0$2a46010a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeewsingh@tataelxsi.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0243137181==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is a multi-part message in MIME format. --===============0243137181== Content-type: multipart/alternative; boundary="Boundary_(ID_LKLrYQxhRUkideTFUqMHmg)" This is a multi-part message in MIME format. --Boundary_(ID_LKLrYQxhRUkideTFUqMHmg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, No transaction for ACK of 2xx response for INVITE. Rajeew -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of innovation.interops@wipro.com Sent: Thursday, January 20, 2005 3:06 PM To: sip@ietf.org Subject: [Sip] CSEQ Number in ACK to 2xx Response for INVITE??? Hello all, In section 13.2.2.4 2xx Responses,it is mentioned that while generating an ACK for a 2xx response should have same CSeq number as in INVITE but the method as ACK. But is mentioned in Definition section that ACK for a 2xx response to an INVITE request is a separate transaction.Does it mean that CSEQ number to be incremented? Regds karthikeyan.k --Boundary_(ID_LKLrYQxhRUkideTFUqMHmg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
 
Hi,
   No transaction for ACK of 2xx response for INVITE.
 
Rajeew
 
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of innovation.interops@wipro.com
Sent: Thursday, January 20, 2005 3:06 PM
To: sip@ietf.org
Subject: [Sip] CSEQ Number in ACK to 2xx Response for INVITE???

Hello all,

 

In section 13.2.2.4 2xx Responses,it is mentioned that while generating an ACK for a 2xx response should have same CSeq number as in INVITE but the method as ACK.

 

But is mentioned in Definition section that ACK for a 2xx response to an INVITE request is a separate transaction.Does it mean that CSEQ number to be incremented?

 

Regds

karthikeyan.k

--Boundary_(ID_LKLrYQxhRUkideTFUqMHmg)-- --===============0243137181== 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 --===============0243137181==-- From sip-bounces@ietf.org Thu Jan 20 09:01:11 2005 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 JAA28519 for ; Thu, 20 Jan 2005 09:01:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crd7l-0007Hc-IO for sip-web-archive@ietf.org; Thu, 20 Jan 2005 09:17:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crcq6-0007BM-5u; Thu, 20 Jan 2005 08:59:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crci8-0006AV-3P for sip@megatron.ietf.org; Thu, 20 Jan 2005 08:50:56 -0500 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 IAA28007 for ; Thu, 20 Jan 2005 08:50:54 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crcxn-000735-KK for sip@ietf.org; Thu, 20 Jan 2005 09:07:08 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0KDk4u11718; Thu, 20 Jan 2005 08:46:04 -0500 (EST) Received: from [47.102.176.161] (archt0cj.us.nortel.com [47.102.176.161]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14FYQZ1; Thu, 20 Jan 2005 08:46:02 -0500 Message-ID: <41EFB616.6050100@nortelnetworks.com> Date: Thu, 20 Jan 2005 08:45:58 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishnu Yadav Subject: Re: [Sip] 183 progress & 190 ringing 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: 8abaac9e10c826e8252866cbe6766464 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit The 183 says something is happening, but is not so precise as 180. It is a response from the UAS (which may be the final destination or the originator's side of a B2BUA). The 183 is assigned specific roles in Q.1912.5 and in 3GPP call flows. Vishnu Yadav wrote: > Hi All, > > I have a doubt on usage & handling of 183 & 180. > 1. What is difference between 180 & 183? Why 183 needed ? > 2. What is the order in which we get both of these responses? I mean to say, > we get 183 then we get 180 or in some other ways. > 3. Is 183 progress sent by proxy or UAS? Can B2BUA send 183 to UAC? > > Thanks in advance. > Vishnu Yadav > > > > _______________________________________________ > 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 > > -- Tom Taylor Carrier VoIP Standards Development Nortel Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.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 Jan 20 09:39:46 2005 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 JAA01611 for ; Thu, 20 Jan 2005 09:39:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crdj6-0008Iq-Vn for sip-web-archive@ietf.org; Thu, 20 Jan 2005 09:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrdQj-0000hC-PC; Thu, 20 Jan 2005 09:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrdPH-0000Pu-UJ for sip@megatron.ietf.org; Thu, 20 Jan 2005 09:35:33 -0500 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 JAA01202 for ; Thu, 20 Jan 2005 09:35:29 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crdey-0008Cv-OI for sip@ietf.org; Thu, 20 Jan 2005 09:51:45 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0KEZTNc012691 for ; Thu, 20 Jan 2005 08:35:29 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Jan 2005 09:35:28 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC2CD@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'innovation.interops@wipro.com'" , sip@ietf.org Subject: RE: [Sip] CSEQ Number in ACK to 2xx Response for INVITE??? Date: Thu, 20 Jan 2005 09:35:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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="===============1725592459==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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. --===============1725592459== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FEFD.26C37A24" 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_01C4FEFD.26C37A24 Content-Type: text/plain; charset="iso-8859-1" It means that the ACK is different transaction. For a 6361 implementation, this means that the branch ID should be different from the branch ID that was used for the INVITE transaction, Shekar -----Original Message----- From: innovation.interops@wipro.com [mailto:innovation.interops@wipro.com] Sent: Thursday, January 20, 2005 4:36 AM To: sip@ietf.org Subject: [Sip] CSEQ Number in ACK to 2xx Response for INVITE??? Hello all, In section 13.2.2.4 2xx Responses,it is mentioned that while generating an ACK for a 2xx response should have same CSeq number as in INVITE but the method as ACK. But is mentioned in Definition section that ACK for a 2xx response to an INVITE request is a separate transaction.Does it mean that CSEQ number to be incremented? Regds karthikeyan.k ------_=_NextPart_001_01C4FEFD.26C37A24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It=20 means that the ACK is different transaction. For a 6361 implementation, = this=20 means that
the=20 branch ID should be different from the branch ID that was used for the = INVITE=20 transaction,
 
Shekar
-----Original Message-----
From:=20 innovation.interops@wipro.com=20 [mailto:innovation.interops@wipro.com]
Sent: Thursday, = January 20,=20 2005 4:36 AM
To: sip@ietf.org
Subject: [Sip] CSEQ = Number=20 in ACK to 2xx Response for INVITE???

Hello=20 all,

 

In section=20 13.2.2.4 2xx Responses,it is mentioned that while=20 generating an ACK for a 2xx response should have same CSeq = number as in=20 INVITE but the method as ACK.

 

But is=20 mentioned in Definition section that ACK for a=20 2xx response to an INVITE request is a = separate=20 transaction.Does it mean that CSEQ number to be = incremented?

 

Regds

karthikeyan.k

<= /HTML> ------_=_NextPart_001_01C4FEFD.26C37A24-- --===============1725592459== 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 --===============1725592459==-- From sip-bounces@ietf.org Thu Jan 20 10:52:02 2005 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 KAA08351 for ; Thu, 20 Jan 2005 10:52:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crer4-0001lj-9I for sip-web-archive@ietf.org; Thu, 20 Jan 2005 11:08:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CreUo-0001xw-Qw; Thu, 20 Jan 2005 10:45:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CreSn-0001KF-3D for sip@megatron.ietf.org; Thu, 20 Jan 2005 10:43:14 -0500 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 KAA07520 for ; Thu, 20 Jan 2005 10:43:09 -0500 (EST) Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CreiS-0001T1-CS for sip@ietf.org; Thu, 20 Jan 2005 10:59:25 -0500 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 4395D37F8C; Thu, 20 Jan 2005 16:42:36 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 2A9F237EC1; Thu, 20 Jan 2005 16:42:36 +0100 (CET) Received: from [10.0.1.6] (h217n2fls31o898.telia.com [217.209.140.217]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id E222137E4D; Thu, 20 Jan 2005 16:42:35 +0100 (CET) In-Reply-To: <41EF5316.6030705@ericsson.com> References: <41EF5316.6030705@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Draft defining the Accept-Disposition header field Date: Thu, 20 Jan 2005 14:39:15 +0100 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , Paul Kyzivat 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: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit This sounds like some presence event package related info or some other event package, not something that is carried in a SIP request or response. Regards, Hisham On Jan 20, 2005, at 7:43 AM, Gonzalo Camarillo wrote: > Hi, > >> I'm not really sure what the problem is that this solves. > > it lets a UA know whether the remote UA supports a particular > disposition type. Right now, UAs guess this information based on the > support for MIME types. For example, if the remote UA supports > application/sdp, my UA assumes that the remote UA supports the > 'session' disposition type... but what about 'early-session'? > > The same thing with uri-list bodies. A conference server may support > uri-list bodies for some reason, but may not support the > 'recipient-list' disposition type. The disposition type is what tells > me that the conference server supports (or does not support) the > feature I want to use. (So far there are two disposition types > associated with uri-list bodies and may be more in the future.) > > Regarding debugging, the UAC can know what went wrong when it received > a 415 response from a UAS that supports all the MIME types needed for > the service. In this sense, the draft completes the procedures defined > in RFC 3204 regarding rejection of body parts whose handling is > required. > > > The thing is that, as it has been pointed out in this thread, > disposition types are usually supported in relation with a particular > MIME type and even a particular method (e.g., a server is a message > URI-list service but does not support the 'recipient-list' disposition > type for INVITEs). > > The solution proposed in the draft follows the definition of the > existing Allow and Accept header fields in the sense that they do not > provide cross header information: Allow tells you which methods are > supported and Accept which MIME types, but there is no info about > which MIME type is acceptable for which method. We need to decide if > this is good enough or if we want to introduce some level of cross > header information in the solution. > > Regards, > > Gonzalo > > > _______________________________________________ > 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 Jan 20 11:05:11 2005 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 LAA09474 for ; Thu, 20 Jan 2005 11:05:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crf3n-0002Aa-3t for sip-web-archive@ietf.org; Thu, 20 Jan 2005 11:21:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Creks-0005X6-2e; Thu, 20 Jan 2005 11:01:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crehk-0004jX-Q2 for sip@megatron.ietf.org; Thu, 20 Jan 2005 10:58:40 -0500 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 KAA08938 for ; Thu, 20 Jan 2005 10:58:38 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrexS-0001x7-6M for sip@ietf.org; Thu, 20 Jan 2005 11:14:54 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0KFw7Op012947 for ; Thu, 20 Jan 2005 09:58:08 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Jan 2005 10:58:07 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC2D1@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'Hisham Khartabil'" , Gonzalo Camarillo Subject: RE: [Sip] Draft defining the Accept-Disposition header field Date: Thu, 20 Jan 2005 10:58:00 -0500 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: e1b0e72ff1bbd457ceef31828f216a86 Cc: Cullen Jennings , sip@ietf.org, Paul Kyzivat 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: 9a2be21919e71dc6faef12b370c4ecf5 This is very much required to accept a Content carried by a SIP request or a Response. This is a real problem, in that sense that the nodes trying to accept the Content needs to look at the Content Type and Content Disposition associated with the Content. Having incorrect or unsupported comibnations will result in call failures, which obviously is not desirable. By specifying the acceptable combinations of Content Type and Content Disposition in some form of Accept Header, we can suppose that the chance of a call succeeding would increase. Nagesh Shekar. > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Thursday, January 20, 2005 8:39 AM > To: Gonzalo Camarillo > Cc: Cullen Jennings; sip@ietf.org; Paul Kyzivat > Subject: Re: [Sip] Draft defining the Accept-Disposition header field > > > This sounds like some presence event package related info or > some other > event package, not something that is carried in a SIP request or > response. > > Regards, > Hisham > > On Jan 20, 2005, at 7:43 AM, Gonzalo Camarillo wrote: > > > Hi, > > > >> I'm not really sure what the problem is that this solves. > > > > it lets a UA know whether the remote UA supports a particular > > disposition type. Right now, UAs guess this information > based on the > > support for MIME types. For example, if the remote UA supports > > application/sdp, my UA assumes that the remote UA supports the > > 'session' disposition type... but what about 'early-session'? > > > > The same thing with uri-list bodies. A conference server > may support > > uri-list bodies for some reason, but may not support the > > 'recipient-list' disposition type. The disposition type is > what tells > > me that the conference server supports (or does not support) the > > feature I want to use. (So far there are two disposition types > > associated with uri-list bodies and may be more in the future.) > > > > Regarding debugging, the UAC can know what went wrong when > it received > > a 415 response from a UAS that supports all the MIME types > needed for > > the service. In this sense, the draft completes the > procedures defined > > in RFC 3204 regarding rejection of body parts whose handling is > > required. > > > > > > The thing is that, as it has been pointed out in this thread, > > disposition types are usually supported in relation with a > particular > > MIME type and even a particular method (e.g., a server is a message > > URI-list service but does not support the 'recipient-list' > disposition > > type for INVITEs). > > > > The solution proposed in the draft follows the definition of the > > existing Allow and Accept header fields in the sense that > they do not > > provide cross header information: Allow tells you which methods are > > supported and Accept which MIME types, but there is no info about > > which MIME type is acceptable for which method. We need to > decide if > > this is good enough or if we want to introduce some level of cross > > header information in the solution. > > > > Regards, > > > > Gonzalo > > > > > > _______________________________________________ > > 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 Thu Jan 20 17:17:03 2005 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 RAA17863 for ; Thu, 20 Jan 2005 17:17:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crkri-00062Y-Ce for sip-web-archive@ietf.org; Thu, 20 Jan 2005 17:33:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkMJ-0004tU-1A; Thu, 20 Jan 2005 17:00:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjkN-0001sW-Py for sip@megatron.ietf.org; Thu, 20 Jan 2005 16:21:43 -0500 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 QAA06822 for ; Thu, 20 Jan 2005 16:21:41 -0500 (EST) Received: from falcon.verisign.com ([216.168.239.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crk07-0002OD-99 for sip@ietf.org; Thu, 20 Jan 2005 16:38:00 -0500 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j0KLGRop017927 for ; Thu, 20 Jan 2005 16:16:27 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Jan 2005 16:21:10 -0500 Message-ID: <768BEB5E70C897468D015E23EDCC304E0AA2FC@dul1wnexmb01.vcorp.ad.vrsn.com> From: "Karnam, Swamy" To: "'sip@ietf.org'" Date: Thu, 20 Jan 2005 16:21:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Subject: [Sip] Via 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="===============1186338853==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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. --===============1186338853== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FF35.F2BC6167" 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_01C4FF35.F2BC6167 Content-Type: text/plain Hi, This is my first post here and am a little bit unfamiliar with the process. Hopefully, I am not asking something that has been answered. My comment is on RFC 3261. In a 302 Response message, there is a contact field that represents a direct route to the destination. What if I want the message to be redirected to this contact via a sequence of hops ? Basically I want the Contact field to contact a Via string. Thanks, Swamy ------_=_NextPart_001_01C4FF35.F2BC6167 Content-Type: text/html

Hi,

 

   This is my first post here and am a little bit unfamiliar with the process.

   Hopefully, I am not asking something that has been answered.

 

   My comment is on RFC 3261.

 

   In a 302 Response message, there is a contact field that represents a direct route to the destination.

 

   What if I want the message to be redirected to this contact via a sequence of hops ?  Basically I want the

   Contact field to contact a Via string.

 

   Thanks,

   Swamy

------_=_NextPart_001_01C4FF35.F2BC6167-- --===============1186338853== 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 --===============1186338853==-- From sip-bounces@ietf.org Thu Jan 20 17:38:37 2005 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 RAA20981 for ; Thu, 20 Jan 2005 17:38:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrlCb-00074b-7V for sip-web-archive@ietf.org; Thu, 20 Jan 2005 17:54:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkhB-0005em-T3; Thu, 20 Jan 2005 17:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkPW-0007EQ-TA for sip@megatron.ietf.org; Thu, 20 Jan 2005 17:04:15 -0500 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 RAA16637 for ; Thu, 20 Jan 2005 17:04:12 -0500 (EST) Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkfG-0005eH-Hf for sip@ietf.org; Thu, 20 Jan 2005 17:20:31 -0500 Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j0KM48XJ062956; Thu, 20 Jan 2005 17:04:08 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j0KM3x0U074250; Thu, 20 Jan 2005 17:04:03 -0500 (EST) Received: from [135.180.240.186] (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j0KM3xoC027430; Thu, 20 Jan 2005 17:03:59 -0500 (EST) Message-ID: <41F02ACC.4090800@bell-labs.com> Date: Thu, 20 Jan 2005 17:03:56 -0500 From: Volker Hilt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Gonzalo Camarillo Subject: [Sip] draft-hilt-sip-ext-neg-00 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Folks, we have submitted a draft, which defines a new Accept header field parameter that can be used to indicate support for MIME type extensions. In particular, this parameter can be used to indicate support for additional XML namespaces, which extend an XML-based media type. http://www.ietf.org/internet-drafts/draft-hilt-sip-ext-neg-00.txt Comments are very welcome. -- Volker _______________________________________________ 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 Jan 20 17:51:58 2005 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 RAA22035 for ; Thu, 20 Jan 2005 17:51:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrlPU-0007Vm-HM for sip-web-archive@ietf.org; Thu, 20 Jan 2005 18:08:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crl2k-0004OK-1h; Thu, 20 Jan 2005 17:44:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crkqv-0000WJ-4F for sip@megatron.ietf.org; Thu, 20 Jan 2005 17:32:33 -0500 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 RAA19976 for ; Thu, 20 Jan 2005 17:32:27 -0500 (EST) Received: from sand2.gxn.net ([195.147.249.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crl6Z-0006im-Tw for sip@ietf.org; Thu, 20 Jan 2005 17:48:47 -0500 Received: from ip02.corenetltd.adsl.gxn.net ([195.147.83.74] helo=gblons002.Streamdoor.local) by sand2.gxn.net with esmtp (Exim 4.33) id 1Crkro-0007mL-5J; Thu, 20 Jan 2005 22:33:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Sip] Via MIME-Version: 1.0 Date: Thu, 20 Jan 2005 22:31:09 -0000 Message-ID: Thread-Topic: [Sip] Via Thread-Index: AcT/PaOJ7crlKWZAS8iiKcBiDkXmkwAAhXfg From: "Ben Gatewood" To: "Karnam, Swamy" , X-Spam-Score: 0.9 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd 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="===============1614470552==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e This is a multi-part message in MIME format. --===============1614470552== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FF3F.BD926C86" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FF3F.BD926C86 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Swamy, =20 If you want the response to travel back along the same path it took, then the proxies along that path will need to insert a Record-route header into the request. Have a read through section 16 of RFC 3261. =20 HTH, =20 B =20 =20 Ben Gatewood Lead Architect - IP Telephony Streamdoor Ltd. +44 20 7422 0439 +44 7835 136 187 bgatewood@streamdoor.net INVITE. TRYING. RINGING. OK. ACK. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karnam, Swamy Sent: 20 January 2005 21:21 To: 'sip@ietf.org' Subject: [Sip] Via =20 Hi, =20 This is my first post here and am a little bit unfamiliar with the process. Hopefully, I am not asking something that has been answered. =20 My comment is on RFC 3261. =20 In a 302 Response message, there is a contact field that represents a direct route to the destination. =20 What if I want the message to be redirected to this contact via a sequence of hops ? Basically I want the Contact field to contact a Via string. =20 Thanks, Swamy ************************************************************************ ************** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com ************************************************************************ ************** *************************************************************************= ************* Disclaimer: This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this emai= l in error, please contact Streamdoor Group IT&C Helpdesk by email at it= &c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Dep= artment , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com *************************************************************************= ************* ------_=_NextPart_001_01C4FF3F.BD926C86 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Swamy,<= /p>

 

If you want the response to travel b= ack along the same path it took, then the proxies along that path will need t= o insert a Record-route header into the request. Have a read through sectio= n 16 of RFC 3261.

 

HTH,

 

B

 

 

Ben Gatewood

Lead Architect - IP Telephony=

Streamdoor Ltd.

+44 20 7422 0439

+44 7835 136 187

bgatewood@streamdoor.net

INVITE. TRYING. RINGING. OK. ACK.

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karnam, Swamy
Sent: 20 January 2005 21:2= 1
To: 'sip@ietf.org'
Subject: [Sip] Via<= /font>

 

Hi,

 

   This is my first post here and am a littl= e bit unfamiliar with the process.

   Hopefully, I am not asking something that= has been answered.

 

   My comment is on RFC 3261.<= o:p>

 

   In a 302 Response message, there is a con= tact field that represents a direct route to the destination.

 

   What if I want the message to be redirect= ed to this contact via a sequence of hops ?  Basically I want the

   Contact field to contact a Via string.

 

   Thanks,

   Swamy

*****************************************************************= *********************
Disclaimer:

This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure, copyi= ng, distribution or use of this information is strictly prohibited. If you ar= e not the intended recipient, please notify the sender and delete this message.= Views expressed in this message are those of the individual sender, and are not= necessarily the views of the Streamdoor Limited, unless otherwise stated.=

Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibili= ty for any loss or damage arising from the use of this email or attachement

Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any infrin= gements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this emai= l in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&= amp;C Department , 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com
*************************************************************************= *************

*************************************************************************= *************
Disclaimer:

This electronic message may contain p= rivileged or confidential information. If you are not the intended recipi= ent, be advised that any disclosure, copying, distribution or use of this= information is strictly prohibited. If you are not the intended recipien= t, please notify the sender and delete this message. Views expressed in t= his message are those of the individual sender, and are not necessarily t= he views of the Streamdoor Limited, unless otherwise stated.

Altho= ugh Streamdoor Limited has taken reasonable precautions to ensure no viru= ses are present in this email, the company cannot accept responsibility f= or any loss or damage arising from the use of this email or attachement
Employees of Streamdoor Limited and its affiliates are expressly re= quired not to make defamatory statements and not to infringe or authorise= any infringements of copyrights or any other legal right by email commun= ications. Any such communication is contrary to company policy and outsid= e the scope of the employment of the individual concerned.

For fur= ther assistance on email policy, or if you have received this email in er= ror, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpd= esk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department ,= 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com************************************************************************= ************** ------_=_NextPart_001_01C4FF3F.BD926C86-- --===============1614470552== 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 --===============1614470552==-- From sip-bounces@ietf.org Thu Jan 20 18:05:42 2005 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 SAA23559 for ; Thu, 20 Jan 2005 18:05:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crlcc-0007xc-BF for sip-web-archive@ietf.org; Thu, 20 Jan 2005 18:21:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrlG5-0007oW-SY; Thu, 20 Jan 2005 17:58:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crl71-0005nQ-1t for sip@megatron.ietf.org; Thu, 20 Jan 2005 17:49:11 -0500 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 RAA21860 for ; Thu, 20 Jan 2005 17:49:07 -0500 (EST) Received: from falcon.verisign.com ([216.168.239.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrlMl-0007Pg-Nu for sip@ietf.org; Thu, 20 Jan 2005 18:05:28 -0500 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j0KMhtop021776; Thu, 20 Jan 2005 17:43:55 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Jan 2005 17:48:33 -0500 Message-ID: <768BEB5E70C897468D015E23EDCC304E0AA2FD@dul1wnexmb01.vcorp.ad.vrsn.com> From: "Karnam, Swamy" To: "'Ben Gatewood'" , sip@ietf.org Subject: RE: [Sip] Via Date: Thu, 20 Jan 2005 17:48:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.9 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b 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="===============1712254785==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 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. --===============1712254785== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FF41.ECB3A0BB" 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_01C4FF41.ECB3A0BB Content-Type: text/plain Ben, I don't want the response to travel back the same path, I want it to be redirected to the contact using a least cost path I want to specify. Thanks, Swamy -----Original Message----- From: Ben Gatewood [mailto:bgatewood@streamdoor.net] Sent: Thursday, January 20, 2005 5:31 PM To: Karnam, Swamy; sip@ietf.org Subject: RE: [Sip] Via Hey Swamy, If you want the response to travel back along the same path it took, then the proxies along that path will need to insert a Record-route header into the request. Have a read through section 16 of RFC 3261. HTH, B Ben Gatewood Lead Architect - IP Telephony Streamdoor Ltd. +44 20 7422 0439 +44 7835 136 187 bgatewood@streamdoor.net INVITE. TRYING. RINGING. OK. ACK. _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karnam, Swamy Sent: 20 January 2005 21:21 To: 'sip@ietf.org' Subject: [Sip] Via Hi, This is my first post here and am a little bit unfamiliar with the process. Hopefully, I am not asking something that has been answered. My comment is on RFC 3261. In a 302 Response message, there is a contact field that represents a direct route to the destination. What if I want the message to be redirected to this contact via a sequence of hops ? Basically I want the Contact field to contact a Via string. Thanks, Swamy **************************************************************************** ********** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com **************************************************************************** ********** **************************************************************************** ********** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com **************************************************************************** ********** ------_=_NextPart_001_01C4FF41.ECB3A0BB Content-Type: text/html

Ben,

   I don’t want the response to travel back the same path,

   I want it to be redirected to the contact using a least cost path I want to specify.

 

   Thanks,

   Swamy

 

 

-----Original Message-----
From: Ben Gatewood [mailto:bgatewood@streamdoor.net]
Sent: Thursday, January 20, 2005 5:31 PM
To: Karnam, Swamy; sip@ietf.org
Subject: RE: [Sip] Via

 

Hey Swamy,

 

If you want the response to travel back along the same path it took, then the proxies along that path will need to insert a Record-route header into the request. Have a read through section 16 of RFC 3261.

 

HTH,

 

B

 

 

Ben Gatewood

Lead Architect - IP Telephony

Streamdoor Ltd.

+44 20 7422 0439

+44 7835 136 187

bgatewood@streamdoor.net

INVITE. TRYING. RINGING. OK. ACK.

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karnam, Swamy
Sent: 20 January 2005 21:21
To: 'sip@ietf.org'
Subject: [Sip] Via

 

Hi,

 

   This is my first post here and am a little bit unfamiliar with the process.

   Hopefully, I am not asking something that has been answered.

 

   My comment is on RFC 3261.

 

   In a 302 Response message, there is a contact field that represents a direct route to the destination.

 

   What if I want the message to be redirected to this contact via a sequence of hops ?  Basically I want the

   Contact field to contact a Via string.

 

   Thanks,

   Swamy

**************************************************************************************
Disclaimer:

This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated.

Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement

Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com
**************************************************************************************

**************************************************************************************
Disclaimer:

This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated.

Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement

Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com
**************************************************************************************

------_=_NextPart_001_01C4FF41.ECB3A0BB-- --===============1712254785== 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 --===============1712254785==-- From sip-bounces@ietf.org Fri Jan 21 05:10:07 2005 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 FAA24567 for ; Fri, 21 Jan 2005 05:10:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crvzs-0006S2-JD for sip-web-archive@ietf.org; Fri, 21 Jan 2005 05:26:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrvgC-0001lF-HW; Fri, 21 Jan 2005 05:06:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crvag-0000lV-2E for sip@megatron.ietf.org; Fri, 21 Jan 2005 05:00:30 -0500 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 FAA23972 for ; Fri, 21 Jan 2005 05:00:27 -0500 (EST) Received: from mailgate2.nl.thalesgroup.com ([193.67.31.101] helo=mailgate2.signaal.nl) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrvqU-0006CP-4j for sip@ietf.org; Fri, 21 Jan 2005 05:16:52 -0500 Received: from mta1.nl.thales (mta1.signaal.local [193.67.31.130]) by mailgate2.signaal.nl (4.8.1.149) with ESMTP id for ; Fri, 21 Jan 2005 10:59:41 +0100 (MET) Received: from suna900.sc.signaal.nl (suna900.sc.signaal.nl [192.7.99.164]) by mta1.nl.thales (4.9.7.3) with ESMTP id Xlc93AAM for ; Fri, 21 Jan 2005 10:59:33 +0100 (MET) Received: from scms1.sc.signaal.nl ([192.7.99.212]) by suna900.sc.signaal.nl (Netscape Messaging Server 3.6) with ESMTP id AAA6336 for ; Fri, 21 Jan 2005 10:59:30 +0100 Received: from scd01-MTA by scms1.sc.signaal.nl with Novell_GroupWise; Fri, 21 Jan 2005 10:57:34 +0100 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Fri, 21 Jan 2005 10:57:11 +0100 From: "Samuel Osorio Calvo" To: , , Subject: RE: [Sip] Via MIME-Version: 1.0 (Generated by Clearswift ES version 4.8.1.149) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.2 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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.2 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Hi, Maybe you should take a look at the Path [RFC 3327] and the Service-Route [RFC 3608] headers. Path: is added in the REGISTER message way by all those servers that want to stay in the path for further messages going to the Contact address included in the registration process. Thus, after a user has registered, when his/her AoR is checked in the Location Service, it returns not only the current contact but also a list of path headers that represents proxies to be in the path of the request. Summarising, its behaviour similar to the Record-Route in INVITES but inserted in the REGISTER requests and obtained when the Location Service is queried for the Contact. The other option, Service-Route, is a header inserted by the Registrar itself and it's meant to represent a list of proxies that must be traversed when the Contact is queried. Its behaviour is much similar to the Path header but Service-Route is inserted --via local policy-- by the registrar and not by the proxies forwarding the REGISTER. I hope I was clear and not wrong and that this is what you were looking for. Samuel. Unclassified. >>> "Karnam, Swamy" 01/20/05 11:48PM >>> Ben, I don't want the response to travel back the same path, I want it to be redirected to the contact using a least cost path I want to specify. Thanks, Swamy -----Original Message----- From: Ben Gatewood [mailto:bgatewood@streamdoor.net] Sent: Thursday, January 20, 2005 5:31 PM To: Karnam, Swamy; sip@ietf.org Subject: RE: [Sip] Via Hey Swamy, If you want the response to travel back along the same path it took, then the proxies along that path will need to insert a Record-route header into the request. Have a read through section 16 of RFC 3261. HTH, B Ben Gatewood Lead Architect - IP Telephony Streamdoor Ltd. +44 20 7422 0439 +44 7835 136 187 bgatewood@streamdoor.net INVITE. TRYING. RINGING. OK. ACK. _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karnam, Swamy Sent: 20 January 2005 21:21 To: 'sip@ietf.org' Subject: [Sip] Via Hi, This is my first post here and am a little bit unfamiliar with the process. Hopefully, I am not asking something that has been answered. My comment is on RFC 3261. In a 302 Response message, there is a contact field that represents a direct route to the destination. What if I want the message to be redirected to this contact via a sequence of hops ? Basically I want the Contact field to contact a Via string. Thanks, Swamy **************************************************************************** ********** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com **************************************************************************** ********** **************************************************************************** ********** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.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 Fri Jan 21 05:42:29 2005 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 FAA26538 for ; Fri, 21 Jan 2005 05:42:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrwVC-00079k-Pt for sip-web-archive@ietf.org; Fri, 21 Jan 2005 05:58:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrwCx-0006Ld-VL; Fri, 21 Jan 2005 05:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrwAy-00066O-EO for sip@megatron.ietf.org; Fri, 21 Jan 2005 05:38:00 -0500 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 FAA26311 for ; Fri, 21 Jan 2005 05:37:58 -0500 (EST) From: mslabrador@sztele.com Received: from [194.140.66.14] (helo=salix1.sztele.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrwQn-000744-SU for sip@ietf.org; Fri, 21 Jan 2005 05:54:24 -0500 Received: from jerez.ipt.es ([10.161.28.22]) by salix1.sztele.com (Lotus Domino Release 5.0.8) with ESMTP id 2005012111371724:104960 ; Fri, 21 Jan 2005 11:37:17 +0100 To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 21 Jan 2005 11:37:16 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on Juglans/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 21/01/2005 11:37:17, Itemize by SMTP Server on Salix1/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 21/01/2005 11:37:17, Serialize by Router on Salix1/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 21/01/2005 11:37:58, Serialize complete at 21/01/2005 11:37:58 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [Sip] CCS 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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Hi all! is anyone working with Avaya SIP Proxy (CCS), telephones (4602) and/or = SIP softphones? I would be pleased if we could share our opinions and problems... Thank you, Mar=EDa S=E1nchez= _______________________________________________ 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 Jan 21 11:10:22 2005 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 LAA23152 for ; Fri, 21 Jan 2005 11:10:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1cZ-00085t-JH for sip-web-archive@ietf.org; Fri, 21 Jan 2005 11:26:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1Dn-0000VK-ON; Fri, 21 Jan 2005 11:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs13s-0006YZ-Gh for sip@megatron.ietf.org; Fri, 21 Jan 2005 10:51:01 -0500 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 KAA21284 for ; Fri, 21 Jan 2005 10:50:58 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1Jl-0007PE-5U for sip@ietf.org; Fri, 21 Jan 2005 11:07:26 -0500 Received: from [192.168.0.104] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0LFokWA047380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 09:50:47 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <656BE56E7D48F6419054CC1C811149270239FAA9@exch01.corp.xl.com> References: <656BE56E7D48F6419054CC1C811149270239FAA9@exch01.corp.xl.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3B3330CB-6BC4-11D9-AA3E-000D93326732@nostrum.com> Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Sip] Minor anomaly in RFC 3261 Registration example? Date: Fri, 21 Jan 2005 09:50:53 -0600 To: "Jain, Rajnish" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable The bugzilla database is available at bugs.sipit.net. RjS On Jan 14, 2005, at 4:06 PM, Jain, Rajnish wrote: > Folks: > > Not sure if this minor anomaly has been reported before and is already=20= > logged in SIP bugzilla (which seems to be down right now). Apologies=20= > if this is a repetition. > > > > Section 10.3 of RFC 3261 states the following: > > =A0=A0=A0=A0=A0 8. The registrar returns a 200 (OK) response.=A0 The = response MUST > =A0=A0=A0=A0=A0=A0=A0=A0 contain Contact header field values = enumerating all current > =A0=A0=A0=A0=A0=A0=A0=A0 bindings.=A0 Each Contact value MUST feature = an "expires" > =A0=A0=A0=A0=A0=A0=A0=A0 parameter indicating its expiration interval = chosen by the > =A0=A0=A0=A0=A0=A0=A0=A0 registrar.=A0 The response SHOULD include a = Date header field. > > > > Section 24.1 of RFC 3261 gives an example of 200 OK for a REGISTER as=20= > the following: > > =A0=A0=A0=A0=A0=A0=A0 SIP/2.0 200 OK > =A0=A0=A0=A0=A0=A0=A0 Via: SIP/2.0/UDP = bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 > =A0=A0=A0=A0=A0=A0=A0=A0 ;received=3D192.0.2.4 > =A0=A0=A0=A0=A0=A0=A0 To: Bob ;tag=3D2493k59kd > =A0=A0=A0=A0=A0=A0=A0 From: Bob ;tag=3D456248 > =A0=A0=A0=A0=A0=A0=A0 Call-ID: 843817637684230@998sdasdh09 > =A0=A0=A0=A0=A0=A0=A0 CSeq: 1826 REGISTER > =A0=A0=A0=A0=A0=A0=A0 Contact: > =A0=A0=A0=A0=A0=A0=A0 Expires: 7200 > =A0=A0=A0=A0=A0=A0=A0 Content-Length: 0 > > > > The "expires" parameter in the 200 OK's Contact header is missing in=20= > this example whereas it's a MUST in the text. > > Thanks, > Rajnish > > Email=A0=A0=A0=A0 mailto:rjain@excelswitching.com > SIP=A0=A0=A0=A0=A0=A0 sip:rjain@voip.excelswitching.com > PSTN=A0=A0=A0=A0=A0 508-862-3215 > _______________________________________________ > 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 Fri Jan 21 11:30:13 2005 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 LAA24652 for ; Fri, 21 Jan 2005 11:30:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1vm-0000Fk-Dz for sip-web-archive@ietf.org; Fri, 21 Jan 2005 11:46:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1T8-0004Kt-JG; Fri, 21 Jan 2005 11:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1Nn-0002st-CH for sip@megatron.ietf.org; Fri, 21 Jan 2005 11:11:35 -0500 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 LAA23266 for ; Fri, 21 Jan 2005 11:11:33 -0500 (EST) Received: from falcon.verisign.com ([216.168.239.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1dh-00086h-Sk for sip@ietf.org; Fri, 21 Jan 2005 11:28:02 -0500 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j0LG6Jop008865; Fri, 21 Jan 2005 11:06:19 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Jan 2005 11:11:02 -0500 Message-ID: <768BEB5E70C897468D015E23EDCC304E0AA303@dul1wnexmb01.vcorp.ad.vrsn.com> From: "Karnam, Swamy" To: "'Samuel Osorio Calvo'" , sip@ietf.org, bgatewood@streamdoor.net Subject: RE: [Sip] Via Date: Fri, 21 Jan 2005 11:10:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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: 8a85b14f27c9dcbe0719e27d46abc1f8 Thanks Samuel, The 2 RFC's were quite helpful. Swamy -----Original Message----- From: Samuel Osorio Calvo [mailto:samuel.osorio@nl.thalesgroup.com] Sent: Friday, January 21, 2005 4:57 AM To: sip@ietf.org; bgatewood@streamdoor.net; Karnam, Swamy Subject: RE: [Sip] Via Hi, Maybe you should take a look at the Path [RFC 3327] and the Service-Route [RFC 3608] headers. Path: is added in the REGISTER message way by all those servers that want to stay in the path for further messages going to the Contact address included in the registration process. Thus, after a user has registered, when his/her AoR is checked in the Location Service, it returns not only the current contact but also a list of path headers that represents proxies to be in the path of the request. Summarising, its behaviour similar to the Record-Route in INVITES but inserted in the REGISTER requests and obtained when the Location Service is queried for the Contact. The other option, Service-Route, is a header inserted by the Registrar itself and it's meant to represent a list of proxies that must be traversed when the Contact is queried. Its behaviour is much similar to the Path header but Service-Route is inserted --via local policy-- by the registrar and not by the proxies forwarding the REGISTER. I hope I was clear and not wrong and that this is what you were looking for. Samuel. Unclassified. >>> "Karnam, Swamy" 01/20/05 11:48PM >>> Ben, I don't want the response to travel back the same path, I want it to be redirected to the contact using a least cost path I want to specify. Thanks, Swamy -----Original Message----- From: Ben Gatewood [mailto:bgatewood@streamdoor.net] Sent: Thursday, January 20, 2005 5:31 PM To: Karnam, Swamy; sip@ietf.org Subject: RE: [Sip] Via Hey Swamy, If you want the response to travel back along the same path it took, then the proxies along that path will need to insert a Record-route header into the request. Have a read through section 16 of RFC 3261. HTH, B Ben Gatewood Lead Architect - IP Telephony Streamdoor Ltd. +44 20 7422 0439 +44 7835 136 187 bgatewood@streamdoor.net INVITE. TRYING. RINGING. OK. ACK. _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karnam, Swamy Sent: 20 January 2005 21:21 To: 'sip@ietf.org' Subject: [Sip] Via Hi, This is my first post here and am a little bit unfamiliar with the process. Hopefully, I am not asking something that has been answered. My comment is on RFC 3261. In a 302 Response message, there is a contact field that represents a direct route to the destination. What if I want the message to be redirected to this contact via a sequence of hops ? Basically I want the Contact field to contact a Via string. Thanks, Swamy **************************************************************************** ********** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com **************************************************************************** ********** **************************************************************************** ********** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.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 Fri Jan 21 15:19:04 2005 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 PAA14671 for ; Fri, 21 Jan 2005 15:19:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5VH-0007G8-5H for sip-web-archive@ietf.org; Fri, 21 Jan 2005 15:35:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs58Y-00070b-Lx; Fri, 21 Jan 2005 15:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs56P-000455-B6; Fri, 21 Jan 2005 15:09:53 -0500 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 PAA13356; Fri, 21 Jan 2005 15:09:50 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5MH-0006zj-Cg; Fri, 21 Jan 2005 15:26:20 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j0LKA1t7006333 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 14:10:02 -0600 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3979AD82-6BE8-11D9-B947-000D93594350@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 21 Jan 2005 14:08:32 -0600 To: SIPPING WG , "'sip-ietf'" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "James M. Polk" , Gonzalo Camarillo , Allison Mankin Subject: [Sip] Move Location Conveyance to SIP? 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit The location conveyance draft: draft-ietf-sipping-location-requirements-02.txt has grown well beyond requirements and into implementation. The group consensus a while back was to keep the requirements and implementation together for this one, as it helps with the review/publication cycle slightly and seems to fit together well. We seem to have a reasonable consensus around the technical approach in the draft. We expect the next rev of the draft to register a couple of additional SIP 400 class response codes making it a SIP extension, albeit a minor one. Since the process says this level of implementation belongs in SIP, we probably need to migrate this draft over to SIP. James Polk is working on a revision of the draft. I propose that he submit this, when ready, as: draft-ietf-sip-location-conveyance-00 Anybody have major issues with this? -- Dean Willis SIP, SIPPING co-chair _______________________________________________ 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 Jan 21 15:27:33 2005 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 PAA15637 for ; Fri, 21 Jan 2005 15:27:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5dU-0007Vn-7r for sip-web-archive@ietf.org; Fri, 21 Jan 2005 15:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5JV-0005qF-2B; Fri, 21 Jan 2005 15:23:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5Cy-0001vp-MK for sip@megatron.ietf.org; Fri, 21 Jan 2005 15:16:41 -0500 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 PAA14152 for ; Fri, 21 Jan 2005 15:16:39 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5Sv-0007AU-Fq for sip@ietf.org; Fri, 21 Jan 2005 15:33:09 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j0LKI3i3006363 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 14:18:04 -0600 In-Reply-To: <768BEB5E70C897468D015E23EDCC304E0AA2FC@dul1wnexmb01.vcorp.ad.vrsn.com> References: <768BEB5E70C897468D015E23EDCC304E0AA2FC@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <588AEAD4-6BE9-11D9-B947-000D93594350@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] Via Date: Fri, 21 Jan 2005 14:16:34 -0600 To: "Karnam, Swamy" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: "'sip@ietf.org'" , sip-implementors@cs.columbia.edu 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Followups to sip-implementors please. On Jan 20, 2005, at 3:21 PM, Karnam, Swamy wrote: > =A0=A0 In a 302 Response message, there is a contact field that=20 > represents a direct route to the destination. > =A0 =A0What if I want the message to be redirected to this contact = via a=20 > sequence of hops ?=A0 Basically I want the > =A0=A0 Contact field to contact a Via string. > Not QUITE sure what your use case here. It sounds like what you want to=20= do is something like the service-route operation and return a string=20 that would be used as a default route on requests to the target=20 returned as a result of redirection. This presumes that the party issuing the redirect understands the=20 routing topology as viewed by the originating UA well enough to build a=20= route, which is not likely to be the general case. So this is pretty=20 likely to explode in some sort of useless way. But I suspect you could return a Contact URI with an attached Route=20 header-field to get something like this beahvior. -- 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 Jan 21 16:46:02 2005 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 QAA25482 for ; Fri, 21 Jan 2005 16:46:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs6rS-0002nf-JW for sip-web-archive@ietf.org; Fri, 21 Jan 2005 17:02:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6Ho-0000kn-Vo; Fri, 21 Jan 2005 16:25:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5ta-0001ZY-32 for sip@megatron.ietf.org; Fri, 21 Jan 2005 16:00:42 -0500 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 QAA18800 for ; Fri, 21 Jan 2005 16:00:40 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs69X-0000Dp-9L for sip@ietf.org; Fri, 21 Jan 2005 16:17:11 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Jan 2005 13:03:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0LL06RQ026517; Fri, 21 Jan 2005 13:00:08 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.98.3 10.21.98.3 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 11:00:08 -1000 Subject: Re: [Sip] Draft defining the Accept-Disposition header field From: Cullen Jennings To: "gonzalo.camarillo@ericsson.com" Message-ID: In-Reply-To: <41EF5316.6030705@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Paul H Kyzivat 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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit On 1/19/05 8:43 PM, "Gonzalo Camarillo" wrote: > Hi, > >> I'm not really sure what the problem is that this solves. > > it lets a UA know whether the remote UA supports a particular > disposition type. Right now, UAs guess this information based on the > support for MIME types. For example, if the remote UA supports > application/sdp, my UA assumes that the remote UA supports the 'session' > disposition type... but what about 'early-session'? > Seems like Supported header is a better way to solve this particular issue > The same thing with uri-list bodies. A conference server may support > uri-list bodies for some reason, but may not support the > 'recipient-list' disposition type. The disposition type is what tells me > that the conference server supports (or does not support) the feature I > want to use. (So far there are two disposition types associated with > uri-list bodies and may be more in the future.) > I guess I am wondering if using the MIME dispositions is really the right way to basically tell the UA what you want it to do with a given SIP command - what does recipient-list mean in the context of email or other users of MIME? > Regarding debugging, the UAC can know what went wrong when it received a > 415 response from a UAS that supports all the MIME types needed for the > service. In this sense, the draft completes the procedures defined in > RFC 3204 regarding rejection of body parts whose handling is required. > > > The thing is that, as it has been pointed out in this thread, > disposition types are usually supported in relation with a particular > MIME type and even a particular method (e.g., a server is a message > URI-list service but does not support the 'recipient-list' disposition > type for INVITEs). I agree with this observation > > The solution proposed in the draft follows the definition of the > existing Allow and Accept header fields in the sense that they do not > provide cross header information: Allow tells you which methods are > supported and Accept which MIME types, but there is no info about which > MIME type is acceptable for which method. We need to decide if this is > good enough or if we want to introduce some level of cross header > information in the solution. I think we should consider if we need this at all or if we are trying to do something with disposition that just should not be done in the MIME level but should be done in the SIP level > > Regards, > > Gonzalo > _______________________________________________ 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 Jan 24 13:24:32 2005 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 NAA08839 for ; Mon, 24 Jan 2005 13:24:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct99i-0006lw-3n for sip-web-archive@ietf.org; Mon, 24 Jan 2005 13:41:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8mD-00047T-JM; Mon, 24 Jan 2005 13:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8g4-0002lX-ST for sip@megatron.ietf.org; Mon, 24 Jan 2005 13:11:05 -0500 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 NAA07660 for ; Mon, 24 Jan 2005 13:11:01 -0500 (EST) Message-Id: <200501241811.NAA07660@ietf.org> Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ct8wb-0006FE-5X for sip@ietf.org; Mon, 24 Jan 2005 13:28:11 -0500 Received: from amy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jan 2005 18:10:38 +0000 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-0.27 From: "Piers O'Hanlon" X-url: http://www.ucl.ac.uk To: Henning Schulzrinne Subject: Re: [Sip] Queries/Comments on Resource Priority-04 In-reply-to: Your message of "Mon, 25 Oct 2004 23:12:38 EDT." <417DC0A6.4030801@cs.columbia.edu> Date: Mon, 24 Jan 2005 18:10:38 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, "Piers O'Hanlon" 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.8 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Hi Henning, I've taken a look at the 05 draft and noticed most of the changes you acknowledged below (for draft-04) don't seem to have made it into this draft. In addition I noticed that there is a hanging reference from section 3.4 to section to 4.2.2 (which is not present in draft-05). Also just to clarify - If a UAC wants to use an OPTIONS request to determine if a proxy supports Resource-priority - it would send a "Require: Resource-priority" and might expect a "Supported: Resource-priority" header and Accept-Resource-priority: namespace.value, ... (given sufficient authorisation)? Wouldn't a 420 response be obliged include a Unsupported header - or is this assumed from RFC3261 compliance? In the definition of strict mode - it doesn't seem to be quite clear whether you mean that all SIP messages in every dialogue MUST contain the RP header or every message in the domain? Is it assumed that user agents are all authorised in a 'strict' mode environment? (or just don't need to include an authorisation header or trait-based auth as with semi-strict mode) Also in the 'semi-strict' mode a similar question arises - when it is stated that "it is not required that every SIP message have a Resource-Priority header" - is this per dialogue or per domain? It's not quite clear whether the strict and semi-strict 'modes' apply to the configuration of a user agent, proxy or a whole domain? And how each entity behaves in each mode. In the previous draft it seemed strict mode was just 'activated' by the presence of the Require header. Thanks, Piers O'Hanlon -------------- Computer Science University College London > > > > General comments: - The fact that it isn't mandatory to mark all > > responses with RP headers means that one should at least make it a > > SHOULD(MUST?) to provide "resource prioritization" based on a dialog > > or session initiated with the RP header (possibly requiring Stateful > > proxy?). Otherwise it seems that being able to know if a node > > "supports Resource priority" (using OPTIONS or a Require hdr) may not > > be of use if you can't be assured the whole dialog/session will be > > assured of the "resource prioritization"? If it's not specified in > > this document then I guess it will need to be specified in some > > external policy document...(out of scope) > > There are two types of resource prioritization, as alluded to in the > document (Introduction), namely to prioritize the signaling handling > itself and, more importantly, the resources such signaling controls, > e.g., trunk circuits. > > Resources such as trunk circuits are inherently stateful, as they are at > UAs, and thus don't require the response to carry the R-P indication. > > The only time the response would need to carry the R-P header is for > prioritizing the handling of the SIP request itself. Since a response is > part of a transaction, transaction-stateful proxies (i.e., most of them) > would already know that the transaction has high priority and can handle > this without additional indication. Thus, only the rare case of a > stateless proxy is relevant. However, since that proxy can't readily > ascertain that the response is authorized (ignoring S/MIME for now), > this isn't likely to be useful. > > I'll add a sentence that summarizes this. > > > > > > > > Section 3.3 - minor comment: It might be useful to label table > > something like 'Table 1'. > > Done. > > - In the second the paragraph the 420 > > response is incorrectly defined as "(Not Supported)" - when it should > > be "(Bad Extension)". > > Fixed. > > - In the same paragraph the explanation > > following the handling of the 420 response seems at odds with the > > description in section 4.2.2 and that of RFC3261. Firstly this is > > because it indicates that a 420 is generated when it encounters a > > unknown RP value (on an RP capable node) - shouldn't that be covered > > in section 4.2.2 > > That part of the paragraph below the table is an orphaned remnant of > some earlier behavioral description. The error behavior is now described > in Section 4.2. I ditched the confusing set of sentences. > > - Shouldn't a 420 be generated only by non RP > > capable node in response to Require? Secondly it seems to reccomend > > adding an 'Accept-Resource-Priority' header when RFC3261 specifies > > adding an "Unsupported" header for a 420 response? Or maybe it was > > intended to talk about the 417 handling here? > > See above. > > > > > > Example 7.2 - In this example - according to section 4.2.2 a 417 > > response should only generated when in strict mode, in which case the > > shouldn't the INVITE contain the Require header? > > Indeed. > > > > > > > Piers O'Hanlon --------------_____________ Computer Science > > Department University College London > > _______________________________________________ > 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 Mon Jan 24 18:28:18 2005 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 SAA17173 for ; Mon, 24 Jan 2005 18:28:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDth-00053a-AO for sip-web-archive@ietf.org; Mon, 24 Jan 2005 18:45:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDWs-0005CC-PV; Mon, 24 Jan 2005 18:21:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDJD-0004E8-QM for sip@megatron.ietf.org; Mon, 24 Jan 2005 18:07:47 -0500 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 SAA14230 for ; Mon, 24 Jan 2005 18:07:44 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDZn-00047E-13 for sip@ietf.org; Mon, 24 Jan 2005 18:24:56 -0500 Received: from [172.16.16.69] ([66.236.111.254]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j0ON7el17496; Mon, 24 Jan 2005 15:07:41 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Mon, 24 Jan 2005 15:07:34 -0800 To: SIP WG X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Dean Willis Subject: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefersub-00.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.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi Folks, I'd like to begin an abbreviated WGLC for: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- norefersub-00.txt Since this document is extremely short and has been discussed extensively, WGLC will end on February 1st. 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 From sip-bounces@ietf.org Mon Jan 24 20:48:17 2005 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 UAA28835 for ; Mon, 24 Jan 2005 20:48:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtG5B-0001v0-8d for sip-web-archive@ietf.org; Mon, 24 Jan 2005 21:05:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtFlv-0004EN-B3; Mon, 24 Jan 2005 20:45:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtFgh-0003ix-Ni for sip@megatron.ietf.org; Mon, 24 Jan 2005 20:40:13 -0500 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 UAA28364 for ; Mon, 24 Jan 2005 20:40:06 -0500 (EST) Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtFxE-0001d3-TH for sip@ietf.org; Mon, 24 Jan 2005 20:57:19 -0500 Received: from asbwebshld.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with SMTP id j0P1cQhs028831 for ; Tue, 25 Jan 2005 09:38:27 +0800 Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Tue Jan 25 09:39:27 2005 +0800 Received: from asbmail1.sbell.com.cn ([172.24.208.61]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Jan 2005 09:39:27 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Tue, 25 Jan 2005 09:39:27 +0800 Message-ID: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> Thread-Topic: pri and sip mapping issue Thread-Index: AcUCfrEWw4Dauw5JRj6mH9x2coYpNQ== From: "FCG Wang JuLin" To: , X-OriginalArrivalTime: 25 Jan 2005 01:39:27.0785 (UTC) FILETIME=[B5203990:01C5027E] X-imss-version: 2.012 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Sip] pri and sip mapping issue 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="===============1078352913==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multi-part message in MIME format. --===============1078352913== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5027E.B4FE1E7A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5027E.B4FE1E7A Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =20 Hi,list, Is there any standard in pri and sip mapping for the following three = items:=20 1)user to user infomation 2)bear capacity( 64K data),UDI. 3) call transfer service indication mapping. Thank you for your response ! Best Regards=20 Wang Julin(Jerry Wang)=20 Product Management Alcatel Shanghai Bell=20 Phone:+86-21-58541240-9531 Fax:+86-21-58342941 Mobile: 13817861240 E-mail:Julin.Wang@alcatel-sbell.com.cn =20 =20 =20 ------_=_NextPart_001_01C5027E.B4FE1E7A Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 

Hi,list,

Is=20 there any standard in  pri and sip mapping for the=20 following three=20 items:

1)user to user=20 infomation

2)bear capacity( 64K=20 data),UDI.

3) call transfer service indication=20 mapping.

Thank=20 you for=20 your response  !

Best Regards
Wang Julin(Jerry Wang) =
Product Management
Alcatel Shanghai  Bell =
Phone:+86-21-58541240-9531
Fax:+86-21-58342941
Mobile:=20 13817861240
E-mail:Julin.Wang@alcatel-sbell.com.cn


 

 

 
------_=_NextPart_001_01C5027E.B4FE1E7A-- --===============1078352913== 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 --===============1078352913==-- From sip-bounces@ietf.org Tue Jan 25 02:52:42 2005 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 CAA06741 for ; Tue, 25 Jan 2005 02:52:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtLls-0005Ki-J2 for sip-web-archive@ietf.org; Tue, 25 Jan 2005 03:09:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLSs-0001TL-BP; Tue, 25 Jan 2005 02:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLQE-0000xk-9I for sip@megatron.ietf.org; Tue, 25 Jan 2005 02:47:34 -0500 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 CAA06466 for ; Tue, 25 Jan 2005 02:47:32 -0500 (EST) Received: from csmail.cs.ccu.edu.tw ([140.123.101.188] helo=mail.cs.ccu.edu.tw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtLgs-00059U-1W for sip@ietf.org; Tue, 25 Jan 2005 03:04:47 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ccu.edu.tw (Postfix) with ESMTP id 6C8045DD48 for ; Tue, 25 Jan 2005 15:47:20 +0800 (CST) Received: from mail.cs.ccu.edu.tw ([127.0.0.1]) by localhost (mail.cs.ccu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44700-11 for ; Tue, 25 Jan 2005 15:47:19 +0800 (CST) Received: from 11092010202 (csie0.cs.ccu.edu.tw [140.123.101.220]) by mail.cs.ccu.edu.tw (Postfix) with ESMTP id 6332E5DD47 for ; Tue, 25 Jan 2005 15:47:19 +0800 (CST) From: "Tai-Hsing Yu" To: Date: Tue, 25 Jan 2005 15:47:12 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 thread-index: AcUCshROK8itc5kwSlK99H7jgUIGMQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20050125074719.6332E5DD47@mail.cs.ccu.edu.tw> X-Virus-Scanned: by amavisd-new at cs.ccu.edu.tw X-Spam-Score: 0.7 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Subject: [Sip] Questions about request message larger than 1300 bytes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fhubert@ms37.hinet.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1616295453==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 This is a multi-part message in MIME format. --===============1616295453== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C502F5.23EFAC40" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C502F5.23EFAC40 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hello, I have some questions about handling SIP msgs that are larger = than 1300 bytes. RFC 3261, chapter 18 as listed, mentions that if request message is larger than 1300 bytes, it MUST be sent using TCP = because of the meesage size constraints. But I don=A1=A6t know how to handle the following scenarios, could anyone help me?=20 1. The UA1 registers to Proxy/Registrar with =A1=A7transport=3Dudp=A1=A8 = or without =A1=A7transport=A1=A8 parameter. According to RFC3261, the = proxy should try to send the request message to UA1 using default transport, = which means UDP. Now suppose that a request comes and is larger than 1500, what should the proxy do? Still try UDP first or = always use TCP to send the request to UA1? If the proxy selects the first stretagy, and, unfortunately, the message is splitted into = more than one pieces and only the first one is received by UA1. The received message is incorrect and might cause UA1 to do incorrect = response. Can the proxy select the second stretagy, i.e, using TCP, even the client only registers with =A1=A7transport=3Dudp=A1=A8? = Which stretagy is correct or better? =20 2. The UA2 sends the request to proxy using UDP with request message = size smaller than 1300 bytes. The Via header in the request is UDP. But the response backs to the proxy is larger than 1500 bytes. What = should the proxy do? Using TCP or UDP to transmit the response to UA2? =20 Any acknowledgement will be deeply appreciated. Sincerely, Fish =20 =A1=A7If a request is within 200 bytes of the path MTU, or if it is = larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, = such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via = MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, = implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, = including IP and UDP headers. The 200 byte "buffer" between the message size and the MTU accommodates = the fact that the response in SIP can be larger than the request. This happens due to the addition of Record-Route header field = values to the responses to INVITE, for example. With the extra buffer, the response can be about 170 bytes larger than the = request, and still not be fragmented on IPv4 (about 30 bytes is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is = not known, based on the assumption of a 1500 byte Ethernet MTU. If an element sends a request over TCP because of these message size = constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an = ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide = backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be = deprecated in a future revision of this specification.=A1=A8 =20 =20 =20 ------=_NextPart_000_0047_01C502F5.23EFAC40 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Hello,<= /o:p>

        I have some questions about handling SIP msgs that are larger than 1300 = bytes. RFC 3261, chapter 18 as listed, mentions that if request message is = larger than 1300 bytes, it MUST be sent using TCP because of the meesage size = constraints. But I don=A1=A6t know how to handle the following scenarios, could anyone help me? =

1. The UA1 = registers to Proxy/Registrar with =A1=A7transport=3D= udp=A1=A8 or without =A1=A7transport=A1=A8 parameter. According to RFC3261, the proxy should try to send the request message = to UA1 using default transport, which means UDP. Now suppose that a request = comes and is larger than 1500, what should the proxy do? Still try UDP first or = always use TCP to send the request to UA1? If the proxy selects the first = stretagy, and, unfortunately, the message is splitted into more than one pieces = and only the first one is received by UA1. The received message is incorrect and = might cause UA1 to do incorrect response. Can the proxy select the second = stretagy, i.e, using TCP, even the client only registers with =A1=A7transport=3D= udp=A1=A8? Which stretagy is correct or better?

 <= /o:p>

2. The UA2 = sends the request to proxy using UDP with request message size smaller than 1300 = bytes. The Via header in the request is UDP. But the response backs to the = proxy is larger than 1500 bytes. What should the proxy do? Using TCP or UDP to = transmit the response to UA2?

 <= /o:p>

Any = acknowledgement will be deeply appreciated.

Sincerely,

Fish

 <= /o:p>

=A1=A7If a request is within 200 bytes of the path MTU, or if it is larger than = 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 = [43] congestion controlled transport protocol, such as TCP. If this causes a = change in the transport protocol from the one indicated in the top Via, the = value in the top Via MUST be changed. This prevents fragmentation of messages = over UDP and provides congestion control for larger messages. However, = implementations MUST be able to handle messages up to the maximum datagram packet size. = For UDP, this size is 65,535 bytes, including IP and UDP = headers.

The 200 = byte "buffer" between the message size and the MTU accommodates the = fact that the response in SIP can be larger than the request. This happens = due to the addition of Record-Route header field values to the responses to = INVITE, for example. With the extra buffer, the response can be about 170 bytes = larger than the request, and still not be fragmented on IPv4 (about 30 bytes is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is = not known, based on the assumption of a 1500 byte Ethernet = MTU.

If an = element sends a request over TCP because of these message size constraints, and that = request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results = in a TCP reset, the element SHOULD retry the request, using UDP. This is only to = provide backwards compatibility with RFC 2543 compliant implementations that do = not support TCP. It is anticipated that this behavior will be deprecated in = a future revision of this specification.=A1=A8<= /span>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0047_01C502F5.23EFAC40-- --===============1616295453== 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 --===============1616295453==-- From sip-bounces@ietf.org Tue Jan 25 03:22:03 2005 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 DAA08474 for ; Tue, 25 Jan 2005 03:22:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtMEI-0006HR-Ag for sip-web-archive@ietf.org; Tue, 25 Jan 2005 03:39:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLsp-0006SO-TS; Tue, 25 Jan 2005 03:17:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLp6-0005oV-U6 for sip@megatron.ietf.org; Tue, 25 Jan 2005 03:13:19 -0500 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 DAA08037 for ; Tue, 25 Jan 2005 03:13:15 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtM5k-0005zg-Jk for sip@ietf.org; Tue, 25 Jan 2005 03:30:30 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0P8F2JD010407 for ; Tue, 25 Jan 2005 01:15:02 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id j0P8D23D031045 for ; Tue, 25 Jan 2005 02:13:03 -0600 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Jan 2005 13:43:00 +0530 Message-ID: <653138C25D8AD6118292000347080A37155531B0@zin05exm02.corp.mot.com> From: Avasarala Ranjit-A20990 To: FCG Wang JuLin , sip@ietf.org, sipforum-discussion@lists.su.se Subject: RE: [Sip] pri and sip mapping issue Date: Tue, 25 Jan 2005 13:42:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.3 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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="===============0003179538==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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. --===============0003179538== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C502B5.AEBE37C8" 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_01C502B5.AEBE37C8 Content-Type: text/plain Hi Check RFC 3398. It provides a mapping between ISDN and SIP signaling. Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of FCG Wang JuLin Sent: Tuesday, January 25, 2005 7:09 AM To: sip@ietf.org; sipforum-discussion@lists.su.se Subject: [Sip] pri and sip mapping issue Hi,list, Is there any standard in pri and sip mapping for the following three items: 1)user to user infomation 2)bear capacity( 64K data),UDI. 3) call transfer service indication mapping. Thank you for your response ! Best Regards Wang Julin(Jerry Wang) Product Management Alcatel Shanghai Bell Phone:+86-21-58541240-9531 Fax:+86-21-58342941 Mobile: 13817861240 E-mail:Julin.Wang@alcatel-sbell.com.cn ------_=_NextPart_001_01C502B5.AEBE37C8 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0zOTQyNjEyMDgtMjUwMTIwMDU+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPkhpPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9Mzk0MjYxMjA4LTI1MDEyMDA1PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgQ2hlY2sgUkZDIDMzOTgu IEl0IHByb3ZpZGVzIGEgbWFwcGluZyBiZXR3ZWVuIElTRE4gYW5kIA0KU0lQIHNpZ25hbGluZy4g PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW PjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9ydGYgZm9ybWF0IC0tPg0KPFA+PFNQQU4gbGFuZz1l bi11cz48ST48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQpzaXplPTI+UmVnYXJkczwv Rk9OVD48L0k+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1lbi11cz48ST48Rk9OVCBmYWNlPUFyaWFs IA0KY29sb3I9IzAwODA4MCBzaXplPTI+UmFuaml0PC9GT05UPjwvST48L1NQQU4+IDwvUD48QlI+ PEJSPg0KPERJVj48L0RJVj4NCjxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1l bi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1UYWhvbWEgDQpzaXplPTI+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IHNpcC1ib3VuY2VzQGlldGYub3Jn IA0KW21haWx0bzpzaXAtYm91bmNlc0BpZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIDwvQj5GQ0cg V2FuZyBKdUxpbjxCUj48Qj5TZW50OjwvQj4gDQpUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDA1IDc6 MDkgQU08QlI+PEI+VG86PC9CPiBzaXBAaWV0Zi5vcmc7IA0Kc2lwZm9ydW0tZGlzY3Vzc2lvbkBs aXN0cy5zdS5zZTxCUj48Qj5TdWJqZWN0OjwvQj4gW1NpcF0gcHJpIGFuZCBzaXAgbWFwcGluZyAN Cmlzc3VlPEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPkhp LDxTUEFOIA0KY2xhc3M9NDQyNDk0MjA4LTIxMDEyMDA1Pmxpc3QsPC9TUEFOPjwvRk9OVD48L0ZP TlQ+PC9QPg0KPFA+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0y PjxTUEFOIA0KY2xhc3M9NDQ4MDYyMjA3LTIxMDEyMDA1PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv UD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ0ODA2MjIwNy0yMTAx MjAwNT48Rk9OVCBmYWNlPUFyaWFsPklzIA0KdGhlcmUgYW55IHN0YW5kYXJkIGluJm5ic3A7PEZP TlQgc2l6ZT0zPiBwcmkgYW5kIHNpcCBtYXBwaW5nIGZvciB0aGUgDQpmb2xsb3dpbmcmbmJzcDs8 U1BBTiBjbGFzcz0zOTgwOTM1MDEtMjUwMTIwMDU+dGhyZWUgDQo8L1NQQU4+aXRlbXM6PC9GT05U PjwvRk9OVD48L1NQQU4+PC9GT05UPiA8L1A+DQo8UD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05U IGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDQ4MDYyMjA3LTIxMDEyMDA1 PjEpPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCnNpemU9Mj48 U1BBTiBjbGFzcz00NDgwNjIyMDctMjEwMTIwMDU+dXNlciB0byB1c2VyIA0KaW5mb21hdGlvbjwv U1BBTj48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz00NDgwNjIyMDctMjEwMTIwMDU+MiliZWFyIGNhcGFj aXR5KCA8Rk9OVCBzaXplPTM+NjRLIA0KZGF0YTwvRk9OVD4pLFVESS48L1NQQU4+PC9GT05UPjwv Rk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIHNpemU9KzA+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+PFNQQU4gDQpjbGFzcz00NDgwNjIyMDctMjEwMTIwMDU+PFNQQU4gY2xhc3M9Mzk4MDkz NTAxLTI1MDEyMDA1PjMpIGNhbGwgdHJhbnNmZXIgc2VydmljZSANCmluZGljYXRpb24gbWFwcGlu Zy48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz00NDgwNjIyMDctMjEwMTIwMDU+VGhhbmsgDQp5 b3U8Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PFNQQU4gY2xhc3M9NDQyNDk0MjA4LTIxMDEy MDA1PiBmb3IgDQp5b3VyJm5ic3A7cmVzcG9uc2UmbmJzcDs8L1NQQU4+PFNQQU4gDQpjbGFzcz00 NDI0OTQyMDgtMjEwMTIwMDU+Jm5ic3A7PC9TUEFOPjwvRk9OVD4hPC9TUEFOPjwvRk9OVD48L1A+ DQo8RElWPjxGT05UIHNpemU9Mj5CPEZPTlQgZmFjZT1BcmlhbD5lc3Q8L0ZPTlQ+PC9GT05UPiA8 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+UjwvRk9OVD48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5lZ2FyZHM8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5XYW5nIEp1bGluKEplcnJ5IFdhbmcpIDwvRk9OVD48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlByb2R1Y3QgTWFuYWdl bWVudDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QWxjYXRlbCBT aGFuZ2hhaSZuYnNwOyBCZWxsIDwvRk9OVD48L0RJVj48Rk9OVCANCmZhY2U9QXJpYWwgc2l6ZT0y Pg0KPERJVj5QaG9uZTorODYtMjEtNTg1NDEyNDAtOTUzMTxCUj5GYXg6Kzg2LTIxLTU4MzQyOTQx PEJSPk1vYmlsZTogDQoxMzgxNzg2MTI0MDwvRElWPg0KPERJVj5FLW1haWw6SnVsaW4uV2FuZ0Bh bGNhdGVsLXNiZWxsLmNvbS5jbjwvRk9OVD48QlI+PC9ESVY+DQo8UD48Rk9OVCBzaXplPTI+PC9G T05UPjxCUj4mbmJzcDs8L1A+DQo8UD48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvUD4NCjxE SVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C502B5.AEBE37C8-- --===============0003179538== 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 --===============0003179538==-- From sip-bounces@ietf.org Tue Jan 25 03:39:22 2005 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 DAA10003 for ; Tue, 25 Jan 2005 03:39:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtMV3-00073P-6K for sip-web-archive@ietf.org; Tue, 25 Jan 2005 03:56:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtMC2-0001k0-GF; Tue, 25 Jan 2005 03:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtM7V-0000xu-HC for sip@megatron.ietf.org; Tue, 25 Jan 2005 03:32:17 -0500 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 DAA09519 for ; Tue, 25 Jan 2005 03:32:15 -0500 (EST) From: mslabrador@sztele.com Received: from [194.140.66.14] (helo=salix1.sztele.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtMOA-0006nu-D6 for sip@ietf.org; Tue, 25 Jan 2005 03:49:31 -0500 Received: from jerez.ipt.es ([10.161.28.22]) by salix1.sztele.com (Lotus Domino Release 5.0.8) with ESMTP id 2005012509313499:140740 ; Tue, 25 Jan 2005 09:31:34 +0100 To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 25 Jan 2005 09:31:33 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on Juglans/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 25/01/2005 09:31:35, Itemize by SMTP Server on Salix1/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 25/01/2005 09:31:35, Serialize by Router on Salix1/Servidores/SZT(Release 5.0.8 |June 18, 2001) at 25/01/2005 09:32:15, Serialize complete at 25/01/2005 09:32:15 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Cc: merisanchez@yahoo.es Subject: [Sip] Calls emulator 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: quoted-printable Hi! Do you know any phone calls emulator software? I need it to emulate calls against the SIP proxy. Thank you all Mar=EDa= _______________________________________________ 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 Jan 25 03:58:06 2005 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 DAA11051 for ; Tue, 25 Jan 2005 03:58:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtMnC-0007rN-Ty for sip-web-archive@ietf.org; Tue, 25 Jan 2005 04:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtMUn-0005dS-Is; Tue, 25 Jan 2005 03:56:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtMTk-0005Ku-FL for sip@megatron.ietf.org; Tue, 25 Jan 2005 03:55:16 -0500 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 DAA10979 for ; Tue, 25 Jan 2005 03:55:14 -0500 (EST) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtMkP-0007iQ-BH for sip@ietf.org; Tue, 25 Jan 2005 04:12:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Calls emulator Date: Tue, 25 Jan 2005 09:54:26 +0100 Message-ID: Thread-Topic: [Sip] Calls emulator Thread-Index: AcUCua0q0Jf5CxN8TCSG/huS6M5rNgAAaPxg From: "Fevzi Konduk" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: merisanchez@yahoo.es 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Hi,=20 You could try:=20 http://sipp.sourceforge.net/ /Fevzi > -----Original Message----- > From: mslabrador@sztele.com [mailto:mslabrador@sztele.com] > Sent: den 25 januari 2005 09:32 > To: sip@ietf.org > Cc: merisanchez@yahoo.es > Subject: [Sip] Calls emulator [bcc][faked-from] >=20 > Hi! > Do you know any phone calls emulator software? > I need it to emulate calls against the SIP proxy. > Thank you all > Mar=EDa >=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 _______________________________________________ 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 Jan 25 10:29:41 2005 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 KAA12375 for ; Tue, 25 Jan 2005 10:29:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtSuB-00059b-Jm for sip-web-archive@ietf.org; Tue, 25 Jan 2005 10:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSa4-0004Pl-Pr; Tue, 25 Jan 2005 10:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSVN-0003B1-EB for sip@megatron.ietf.org; Tue, 25 Jan 2005 10:21:23 -0500 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 KAA11419 for ; Tue, 25 Jan 2005 10:21:19 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtSm5-0004qk-CS for sip@ietf.org; Tue, 25 Jan 2005 10:38:38 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0PFKOR07599; Tue, 25 Jan 2005 10:20:24 -0500 (EST) Received: from [47.130.17.214] (acart557.ca.nortel.com [47.130.17.214]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14FZFQR; Tue, 25 Jan 2005 10:20:25 -0500 Message-ID: <41F663B7.9030600@nortelnetworks.com> Date: Tue, 25 Jan 2005 10:20:23 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FCG Wang JuLin Subject: Re: [Sip] pri and sip mapping issue References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> In-Reply-To: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sipforum-discussion@lists.su.se 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: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Hi. My responses below marked with [PTT]. FCG Wang JuLin wrote: > > > Hi,list, > > Is there any standard in pri and sip mapping for the following three > items: > > 1)user to user infomation [PTT] To carry the information itself, the obvious method is to add a body of type application/octet-stream. The issue comes in how to signal the service -- especially, how to indicate what that body is for. > > 2)bear capacity( 64K data),UDI. [PTT] You can signal and use CLEARMODE (http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This has been approved by the IESG but is stuck in the RFC Editor's queue because it has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last Call. > > 3) call transfer service indication mapping. [PTT] Leaving aside 3xx redirection responses, you may want to look at the Request_History header field (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). > > Thank you for your response ! > > Best Regards > Wang Julin(Jerry Wang) > Product Management > Alcatel Shanghai Bell > Phone:+86-21-58541240-9531 > Fax:+86-21-58342941 > Mobile: 13817861240 > E-mail:Julin.Wang@alcatel-sbell.com.cn > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Tom Taylor Carrier VoIP Standards Development Nortel Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.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 Jan 25 11:04:05 2005 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 LAA15691 for ; Tue, 25 Jan 2005 11:04:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTRU-0006Qm-Ee for sip-web-archive@ietf.org; Tue, 25 Jan 2005 11:21:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtT8n-0004DD-SS; Tue, 25 Jan 2005 11:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtT2F-0002sB-7c for sip@megatron.ietf.org; Tue, 25 Jan 2005 10:55:19 -0500 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 KAA14994 for ; Tue, 25 Jan 2005 10:55:16 -0500 (EST) Received: from ltn01-mta02.peakss.com ([12.45.97.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTIx-000636-Lj for sip@ietf.org; Tue, 25 Jan 2005 11:12:37 -0500 Received: from localhost (ltn01-mta02.peakss.com [127.0.0.1]) by ltn01-mta02.peakss.com (Postfix) with ESMTP id 258763F9B; Tue, 25 Jan 2005 09:03:30 -0700 (MST) Received: from ltn01-mta02.peakss.com ([127.0.0.1]) by localhost (ltn01-mta02.peakss.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28365-10; Tue, 25 Jan 2005 09:03:29 -0700 (MST) Received: from marvin.peakss.com (marvin.peakss.com [172.28.0.108]) by ltn01-mta02.peakss.com (Postfix) with ESMTP id 85F6B3F94; Tue, 25 Jan 2005 09:03:28 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by marvin.peakss.com (Postfix) with ESMTP id 198F61663F0; Tue, 25 Jan 2005 08:54:39 -0700 (MST) Received: from [172.28.30.162] (rameshlinux.peakss.com [172.28.30.162]) by marvin.peakss.com (Postfix) with ESMTP id D154016580C; Tue, 25 Jan 2005 08:54:37 -0700 (MST) Message-ID: <41F66BA1.9000406@peakss.com> Date: Tue, 25 Jan 2005 08:54:09 -0700 From: Ramesh Ramamurthy User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor Subject: Re: [Sip] pri and sip mapping issue References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> <41F663B7.9030600@nortelnetworks.com> In-Reply-To: <41F663B7.9030600@nortelnetworks.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Virus-Scanned: by amavisd-new at peakss.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sipforum-discussion@lists.su.se, FCG Wang JuLin 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi, I have sent a request for information to the author about the ClearMode Draft and have not received any responce. Are we sure that this draft is alive? Thanks Ramesh Tom Taylor wrote: >Hi. My responses below marked with [PTT]. > >FCG Wang JuLin wrote: > > >> >> >>Hi,list, >> >>Is there any standard in pri and sip mapping for the following three >>items: >> >>1)user to user infomation >> >> > >[PTT] To carry the information itself, the obvious method is to add a body of >type application/octet-stream. The issue comes in how to signal the service -- >especially, how to indicate what that body is for. > > >>2)bear capacity( 64K data),UDI. >> >> > >[PTT] You can signal and use CLEARMODE >(http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This >has been approved by the IESG but is stuck in the RFC Editor's queue because it >has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last >Call. > > >>3) call transfer service indication mapping. >> >> > >[PTT] Leaving aside 3xx redirection responses, you may want to look at the >Request_History header field >(http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). > > >>Thank you for your response ! >> >>Best Regards >>Wang Julin(Jerry Wang) >>Product Management >>Alcatel Shanghai Bell >>Phone:+86-21-58541240-9531 >>Fax:+86-21-58342941 >>Mobile: 13817861240 >>E-mail:Julin.Wang@alcatel-sbell.com.cn >> >> >> >> >> >> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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 Jan 26 09:46:18 2005 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 JAA01208 for ; Wed, 26 Jan 2005 09:46:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctohx-00009E-CN for sip-web-archive@ietf.org; Wed, 26 Jan 2005 10:03:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtoGW-0005LN-Hc; Wed, 26 Jan 2005 09:35:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtoBL-0003ax-EI for sip@megatron.ietf.org; Wed, 26 Jan 2005 09:30:10 -0500 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 JAA28637 for ; Wed, 26 Jan 2005 09:30:05 -0500 (EST) Received: from ptb-relay01.plus.net ([212.159.14.212]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtoSC-0007sR-M3 for sip@ietf.org; Wed, 26 Jan 2005 09:47:37 -0500 Received: from [212.159.34.46] (helo=dsmsystems.co.uk) by ptb-relay01.plus.net with esmtp (Exim) id 1CtoAf-000Bbv-2S; Wed, 26 Jan 2005 14:29:25 +0000 Received: from mail pickup service by dsmsystems.co.uk with Microsoft SMTPSVC; Wed, 26 Jan 2005 13:15:30 +0000 thread-index: AcUDqRwfSChRmRUORA6m+JoWKuHsyw== Delivered-To: mi_plusn-millner-justin@dsm.uk.com X-Original-To: sipforum-discussion@lists.su.se Delivered-To: sipforum-discussion@lists.su.se From: "Ramesh Ramamurthy" Message-ID: <000001c503a9$1c1f3210$2464a8c0@dsmsystems.local> User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> <41F663B7.9030600@nortelnetworks.com> In-Reply-To: <41F663B7.9030600@nortelnetworks.com> Content-Type: text/plain; charset="GB2312" X-Mailer: Microsoft CDO for Exchange 2000 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Virus-Scanned: by amavisd-new at peakss.com X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Status: No, hits=-2.599 tagged_above=-99 required=7 tests=BAYES_00 Subject: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue X-BeenThere: sipforum-discussion@lists.su.se X-Mailman-Version: 2.0.13 Precedence: bulk List-Archive: Content-Class: urn:content-classes:message Date: Wed, 26 Jan 2005 13:15:30 -0000 Importance: normal X-LNS-SpamCheck: NOSPAM Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 26 Jan 2005 13:15:30.0640 (UTC) FILETIME=[1C23ED00:01C503A9] X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sipforum-discussion@lists.su.se, FCG Wang JuLin X-BeenThere: sip@ietf.org 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: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Hi, I have sent a request for information to the author about the ClearMode Draft and have not received any responce. Are we sure that this draft is alive? Thanks Ramesh Tom Taylor wrote: >Hi. My responses below marked with [PTT]. > >FCG Wang JuLin wrote: > > >> >> >>Hi,list, >> >>Is there any standard in pri and sip mapping for the following three >>items: >> >>1)user to user infomation >> >> > >[PTT] To carry the information itself, the obvious method is to add a body of >type application/octet-stream. The issue comes in how to signal the service -- >especially, how to indicate what that body is for. > > >>2)bear capacity( 64K data),UDI. >> >> > >[PTT] You can signal and use CLEARMODE >(http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This >has been approved by the IESG but is stuck in the RFC Editor's queue because it >has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last >Call. > > >>3) call transfer service indication mapping. >> >> > >[PTT] Leaving aside 3xx redirection responses, you may want to look at the >Request_History header field >(http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). > > >>Thank you for your response ! >> >>Best Regards >>Wang Julin(Jerry Wang) >>Product Management >>Alcatel Shanghai Bell >>Phone:+86-21-58541240-9531 >>Fax:+86-21-58342941 >>Mobile: 13817861240 >>E-mail:Julin.Wang@alcatel-sbell.com.cn >> >> >> >> >> >> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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 >> >> > > > ------ To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion Incoming mail is checked with Bitdefender and AVG anti-virus software. _______________________________________________ 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 Jan 26 09:49:14 2005 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 JAA01334 for ; Wed, 26 Jan 2005 09:49:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctokj-0000CN-UE for sip-web-archive@ietf.org; Wed, 26 Jan 2005 10:06:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtoGY-0005NB-1s; Wed, 26 Jan 2005 09:35:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtoBL-0003bL-EJ for sip@megatron.ietf.org; Wed, 26 Jan 2005 09:30:07 -0500 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 JAA28639 for ; Wed, 26 Jan 2005 09:30:05 -0500 (EST) Received: from ptb-relay01.plus.net ([212.159.14.212]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtoSC-0007sJ-LP for sip@ietf.org; Wed, 26 Jan 2005 09:47:37 -0500 Received: from [212.159.34.46] (helo=dsmsystems.co.uk) by ptb-relay01.plus.net with esmtp (Exim) id 1CtoAg-000Bbv-Vj; Wed, 26 Jan 2005 14:29:27 +0000 Received: from mail pickup service by dsmsystems.co.uk with Microsoft SMTPSVC; Wed, 26 Jan 2005 13:15:30 +0000 thread-index: AcUDqRwhFu0/TXfFTaKmseSl63nUlQ== Delivered-To: mi_plusn-millner-justin@dsm.uk.com X-Original-To: sipforum-discussion@lists.su.se Delivered-To: sipforum-discussion@lists.su.se X-Sybari-Space: 00000000 00000000 00000000 00000000 Message-ID: <000501c503a9$1c265e00$2464a8c0@dsmsystems.local> From: "Tom Taylor" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> In-Reply-To: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> Content-Type: text/plain; charset="GB2312" X-Mailer: Microsoft CDO for Exchange 2000 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Status: No, hits=-2.743 tagged_above=-99 required=7 tests=AWL, BAYES_00 Subject: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue X-BeenThere: sipforum-discussion@lists.su.se X-Mailman-Version: 2.0.13 Precedence: bulk List-Archive: Content-Class: urn:content-classes:message Importance: normal Date: Wed, 26 Jan 2005 13:15:30 -0000 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-LNS-SpamCheck: NOSPAM X-OriginalArrivalTime: 26 Jan 2005 13:15:30.0843 (UTC) FILETIME=[1C42E6B0:01C503A9] X-Spam-Score: 0.4 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sipforum-discussion@lists.su.se X-BeenThere: sip@ietf.org 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Hi. My responses below marked with [PTT]. FCG Wang JuLin wrote: > > > Hi,list, > > Is there any standard in pri and sip mapping for the following three > items: > > 1)user to user infomation [PTT] To carry the information itself, the obvious method is to add a body of type application/octet-stream. The issue comes in how to signal the service -- especially, how to indicate what that body is for. > > 2)bear capacity( 64K data),UDI. [PTT] You can signal and use CLEARMODE (http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This has been approved by the IESG but is stuck in the RFC Editor's queue because it has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last Call. > > 3) call transfer service indication mapping. [PTT] Leaving aside 3xx redirection responses, you may want to look at the Request_History header field (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). > > Thank you for your response ! > > Best Regards > Wang Julin(Jerry Wang) > Product Management > Alcatel Shanghai Bell > Phone:+86-21-58541240-9531 > Fax:+86-21-58342941 > Mobile: 13817861240 > E-mail:Julin.Wang@alcatel-sbell.com.cn > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Tom Taylor Carrier VoIP Standards Development Nortel Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com ------ To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion Incoming mail is checked with Bitdefender and AVG anti-virus software. _______________________________________________ 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 Jan 26 10:58:47 2005 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 KAA09677 for ; Wed, 26 Jan 2005 10:58:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctpq4-0002Ct-3e for sip-web-archive@ietf.org; Wed, 26 Jan 2005 11:16:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtpRw-0000a5-8X; Wed, 26 Jan 2005 10:51:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtpO3-0008Ax-5K for sip@megatron.ietf.org; Wed, 26 Jan 2005 10:47:22 -0500 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 KAA08788 for ; Wed, 26 Jan 2005 10:47:16 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctpez-0001xX-FY for sip@ietf.org; Wed, 26 Jan 2005 11:04:49 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0QFkIN04439; Wed, 26 Jan 2005 10:46:18 -0500 (EST) Received: from [47.130.24.179] (acart17y.ca.nortel.com [47.130.24.179]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14FZMGP; Wed, 26 Jan 2005 10:46:19 -0500 Message-ID: <41F7BB51.80501@nortelnetworks.com> Date: Wed, 26 Jan 2005 10:46:25 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ramesh Ramamurthy Subject: Re: [Sip] pri and sip mapping issue References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> <41F663B7.9030600@nortelnetworks.com> <41F66BA1.9000406@peakss.com> In-Reply-To: <41F66BA1.9000406@peakss.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Tom-PT Taylor , FCG Wang JuLin 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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit I have deleted the SIPForum cross-posting -- I think Justin Millner has (inadvertently, I'm sure) set up some sort of mail loop through that list. Now that the IESG has approved the document (some months ago) the availability of the author is irrelevant. Ramesh Ramamurthy wrote: > Hi, > I have sent a request for information to the author about the ClearMode > Draft and have not received any responce. Are we sure that this draft is > alive? > > Thanks > Ramesh > Tom Taylor wrote: > > >>Hi. My responses below marked with [PTT]. >> >>FCG Wang JuLin wrote: >> >> >> >>> >>>Hi,list, >>> >>>Is there any standard in pri and sip mapping for the following three >>>items: >>> >>>1)user to user infomation >>> >>> >> >>[PTT] To carry the information itself, the obvious method is to add a body of >>type application/octet-stream. The issue comes in how to signal the service -- >>especially, how to indicate what that body is for. >> >> >> >>>2)bear capacity( 64K data),UDI. >>> >>> >> >>[PTT] You can signal and use CLEARMODE >>(http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This >>has been approved by the IESG but is stuck in the RFC Editor's queue because it >>has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last >>Call. >> >> >> >>>3) call transfer service indication mapping. >>> >>> >> >>[PTT] Leaving aside 3xx redirection responses, you may want to look at the >>Request_History header field >>(http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). >> >> >> >>>Thank you for your response ! >>> >>>Best Regards >>>Wang Julin(Jerry Wang) >>>Product Management >>>Alcatel Shanghai Bell >>>Phone:+86-21-58541240-9531 >>>Fax:+86-21-58342941 >>>Mobile: 13817861240 >>>E-mail:Julin.Wang@alcatel-sbell.com.cn >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>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 >>> >>> >> >> >> > > > -- Tom Taylor Carrier VoIP Standards Development Nortel Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.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 Jan 26 17:28:23 2005 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 RAA28635 for ; Wed, 26 Jan 2005 17:28:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtvvB-0007Li-RL for sip-web-archive@ietf.org; Wed, 26 Jan 2005 17:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctva9-0003O3-P2; Wed, 26 Jan 2005 17:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtvYA-0002vK-1w for sip@megatron.ietf.org; Wed, 26 Jan 2005 17:22:10 -0500 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 RAA28280 for ; Wed, 26 Jan 2005 17:22:07 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctvp9-0007Er-RS for sip@ietf.org; Wed, 26 Jan 2005 17:39:44 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0QMM2h2007725 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 26 Jan 2005 16:22:03 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefersub-00.txt Date: Wed, 26 Jan 2005 16:22:00 -0600 To: Rohan Mahy X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: SIP WG , Orit Levin , 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.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Initial LC Comments: First paragraph of Section 3 calls out 481ing an initial NOTIFY. The -dialog-usage- draft shows that is a bad idea, especially for in-dialog REFERs. Suggest trimming the sentence to end after (Expires 0). Section 4 fourth paragraph: It would help implementers to call out explicitly that the 200 response to the REFER will not contain a Supported or Require header containing the norefersub token. Section 4 fifth paragraph: This needs more definition. How is it rejected? 603, 420, or something else? Implementors will need some guidance here on when to use which error response. I think (but am not dead certain at the moment) that 420 is almost always what you want to use. Section 4 sixth paragraph: Is Supported: in the response really the right thing? Eventlist uses Require: in the response to a SUBSCRIBE. The intent of the normative behavior in this paragraph is to let a Refer-issuer who only included Supported: know whether or not a subscription was actually created. Require: (I'm using this extension) in the response fits that better than Supported: (I could use this extension if you want to). Section 4 sixth paragraph: Suggest replacing "In this case, no dialog is created" with "In this case, no implicit subscription is created. As a consequence, no new dialog is created if this REFER was issued outside any existing dialog." Section 5: Probably worth also calling out using Max-Forwards: 0 to prevent forking for those (rare now, but hopefully not rare forever) cases where signaling can get to the refer target without going through a proxy. Section 6: Must replace "tradewind" with "example" throughout. Section 8: "threads" should be "threats", It would be good to pull any discussion that led to this conclusion together for when the IESG asks if we _really_ thought about this. Have we talked about what would happen if a SIP intermediary (or an unauthorized MitM) just injected a Require: norefersub into a REFER request? RjS On Jan 24, 2005, at 5:07 PM, Rohan Mahy wrote: > Hi Folks, > > I'd like to begin an abbreviated WGLC for: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- > norefersub-00.txt > > Since this document is extremely short and has been discussed > extensively, WGLC will end on February 1st. > > 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 Jan 26 19:04:52 2005 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 TAA05718 for ; Wed, 26 Jan 2005 19:04:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxQc-0000hs-My for sip-web-archive@ietf.org; Wed, 26 Jan 2005 19:22:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctx3P-0000As-AR; Wed, 26 Jan 2005 18:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctx2r-0008Ph-Ua for sip@megatron.ietf.org; Wed, 26 Jan 2005 18:57:58 -0500 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 SAA05038 for ; Wed, 26 Jan 2005 18:57:54 -0500 (EST) Received: from mail5.empirix.com ([12.38.203.18] helo=empwilex1.empirix.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxJr-0000YQ-CG for sip@ietf.org; Wed, 26 Jan 2005 19:15:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Jan 2005 18:57:19 -0500 Message-ID: <2A9AA9C52024F94A96634E39B9858FF1013473EE@empwilex1.empirix.com> Thread-Topic: Query on Early Media ( 183 Session in Progress ) Thread-Index: AcUEAsU2iNdVA8yqRvSHYTusflQxYw== From: "Bhattacharyya, Dipankar" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Subject: [Sip] Query on Early Media ( 183 Session in Progress ) 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="===============1611550584==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b This is a multi-part message in MIME format. --===============1611550584== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50402.C59E4F5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50402.C59E4F5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, This is query regarding Early Media ( 183 Session in Progress ) . Can an Implementation ( Gateway ) send Media before sending out the 183 Session in Progress over UDP Transport in response to a INVITE ? Is there any RFC/draft on the details of 183 Session in progress and Media handling ?=20 Thanks in advance . Best Regards, =20 =20 Dipankar Bhattacharyya=20 Systems Engineer=20 Communication Infrastructure Group p | 972.401.4112 f | 972.596.4909 m | 214.766.1479 email | dbhattacharyya@empirix.com 6100 Ohio Drive , Suite 2011 | Plano, TX | 75024 . E M P I R I X=20 www.empirix.com =20 =20 =20 ------_=_NextPart_001_01C50402.C59E4F5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

    This is query regarding Early = Media ( 183 Session in Progress ) .

Can an  Implementation ( Gateway ) send Media = before sending out the 183 Session in Progress over UDP Transport in response = to a INVITE   ? Is there any RFC/draft on the details of 183 = Session in progress and Media handling ?

Thanks in advance .

Best Regards, =   

 

Dipankar Bhattacharyya
Systems Engineer
Communication Infrastructure Group

p |  972.401.4112 f | 972.596.4909 m = | 214.766.1479
email | dbhattacharyya@empirix.com
6100 Ohio = Drive , Suite 2011 |=    Plano, TX  |  75024 = .

E M P I R I X
www.empirix.com<= /o:p>

 

 

------_=_NextPart_001_01C50402.C59E4F5F-- --===============1611550584== 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 --===============1611550584==-- From sip-bounces@ietf.org Thu Jan 27 08:53:50 2005 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 IAA05883 for ; Thu, 27 Jan 2005 08:53:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuAMw-0003HR-NC for sip-web-archive@ietf.org; Thu, 27 Jan 2005 09:11:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuA2y-00066Q-V6; Thu, 27 Jan 2005 08:50:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu9xt-0004cs-VV for sip@megatron.ietf.org; Thu, 27 Jan 2005 08:45:42 -0500 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 IAA04839 for ; Thu, 27 Jan 2005 08:45:40 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuAF2-00031p-9e for sip@ietf.org; Thu, 27 Jan 2005 09:03:24 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0RDjcuu013828 for ; Thu, 27 Jan 2005 07:45:39 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Jan 2005 13:45:38 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29030E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Tom Taylor'" , Ramesh Ramamurthy Subject: RE: [Sip] pri and sip mapping issue Date: Thu, 27 Jan 2005 13:45:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="gb2312" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: sip@ietf.org, FCG Wang JuLin 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: 87a3f533bb300b99e2a18357f3c1563d Not completely irrelevant, as you still need the author participation to get it out of the Auth48 at the end of the publication process. I believe it is currently stuck in the queue because it is waiting for draft-ietf-mmusic-sdp-new to get published - you know that document that never quite seems to get there because despite all the polishing, it never shines brightly enough!! regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On > Behalf Of Tom Taylor > Sent: 26 January 2005 15:46 > To: Ramesh Ramamurthy > Cc: sip@ietf.org; Tom-PT Taylor; FCG Wang JuLin > Subject: Re: [Sip] pri and sip mapping issue > > > I have deleted the SIPForum cross-posting -- I think Justin > Millner has > (inadvertently, I'm sure) set up some sort of mail loop > through that list. > > Now that the IESG has approved the document (some months ago) > the availability of > the author is irrelevant. > > Ramesh Ramamurthy wrote: > > Hi, > > I have sent a request for information to the author about > the ClearMode > > Draft and have not received any responce. Are we sure that > this draft is > > alive? > > > > Thanks > > Ramesh > > Tom Taylor wrote: > > > > > >>Hi. My responses below marked with [PTT]. > >> > >>FCG Wang JuLin wrote: > >> > >> > >> > >>> > >>>Hi,list, > >>> > >>>Is there any standard in pri and sip mapping for the > following three > >>>items: > >>> > >>>1)user to user infomation > >>> > >>> > >> > >>[PTT] To carry the information itself, the obvious method > is to add a body of > >>type application/octet-stream. The issue comes in how to > signal the service -- > >>especially, how to indicate what that body is for. > >> > >> > >> > >>>2)bear capacity( 64K data),UDI. > >>> > >>> > >> > >>[PTT] You can signal and use CLEARMODE > >>(http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clea > rmode-05.txt). This > >>has been approved by the IESG but is stuck in the RFC > Editor's queue because it > >>has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which > still has to pass Last > >>Call. > >> > >> > >> > >>>3) call transfer service indication mapping. > >>> > >>> > >> > >>[PTT] Leaving aside 3xx redirection responses, you may want > to look at the > >>Request_History header field > >>(http://www.ietf.org/internet-drafts/draft-ietf-sip-history- info-06.txt). >> >> >> >>>Thank you for your response ! >>> >>>Best Regards >>>Wang Julin(Jerry Wang) >>>Product Management >>>Alcatel Shanghai Bell >>>Phone:+86-21-58541240-9531 >>>Fax:+86-21-58342941 >>>Mobile: 13817861240 >>>E-mail:Julin.Wang@alcatel-sbell.com.cn >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>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 >>> >>> >> >> >> > > > -- Tom Taylor Carrier VoIP Standards Development Nortel Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.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 Thu Jan 27 09:23:14 2005 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 JAA09109 for ; Thu, 27 Jan 2005 09:23:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuApO-0004Ef-QT for sip-web-archive@ietf.org; Thu, 27 Jan 2005 09:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuATs-0005WA-1q; Thu, 27 Jan 2005 09:18:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuAQe-0003zb-Ei for sip@megatron.ietf.org; Thu, 27 Jan 2005 09:15:24 -0500 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 JAA08030 for ; Thu, 27 Jan 2005 09:15:22 -0500 (EST) 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 1CuAhl-0003uo-Sf for sip@ietf.org; Thu, 27 Jan 2005 09:33:07 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 27 Jan 2005 06:21:00 -0800 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 j0REEkM8009116; Thu, 27 Jan 2005 06:14:47 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOQ37037; Thu, 27 Jan 2005 09:14:47 -0500 (EST) Message-ID: <41F8F757.6010802@cisco.com> Date: Thu, 27 Jan 2005 09:14:47 -0500 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: "Bhattacharyya, Dipankar" Subject: Re: [Sip] Query on Early Media ( 183 Session in Progress ) References: <2A9AA9C52024F94A96634E39B9858FF1013473EE@empwilex1.empirix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit You can send media as soon as the offer/answer exchange has provided you with a place to send it. So, if the initial invite contains an offer, the UAS may begin sending media as soon as it receives that offer, even before sending any response. In this case, what the answer in the 183 does is permit the UAC to send media to the UAS, even prior to call completion. Whether you *want* to send media that early, and whether you want to render it if you receive it, is another matter. Paul Bhattacharyya, Dipankar wrote: > Hi All, > > This is query regarding Early Media ( 183 Session in Progress ) . > > Can an Implementation ( Gateway ) send Media before sending out the 183 > Session in Progress over UDP Transport in response to a INVITE ? Is > there any RFC/draft on the details of 183 Session in progress and Media > handling ? > > Thanks in advance . > > Best Regards, > > > > *Dipankar Bhattacharyya > *Systems Engineer > Communication Infrastructure Group > > *p | **972.401.4112** f |** 972.596.4909 **m |** 214.766.1479* > *email |* dbhattacharyya@empirix.com > 6100 Ohio Drive , Suite 2011 *|* Plano, TX *|* 75024 . > > *E M P I R I X > *www.empirix.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 Jan 29 11:10:52 2005 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 LAA20074 for ; Sat, 29 Jan 2005 11:10:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuvT5-0006SH-Ov for sip-web-archive@ietf.org; Sat, 29 Jan 2005 11:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuv6w-0004Nm-5k; Sat, 29 Jan 2005 11:06:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuv5Z-00043p-AE for sip@megatron.ietf.org; Sat, 29 Jan 2005 11:04:45 -0500 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 LAA19712 for ; Sat, 29 Jan 2005 11:04:43 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuvN8-0006Kl-CG for sip@ietf.org; Sat, 29 Jan 2005 11:22:54 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 29 Jan 2005 08:04:39 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0TG461U003625; Sat, 29 Jan 2005 08:04:13 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.90.116 10.21.90.116 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 28 Jan 2005 17:31:13 -0800 Subject: Re: [Sip] draft-hilt-sip-ext-neg-00 From: Cullen Jennings To: Volker Hilt , "sip@ietf.org" Message-ID: In-Reply-To: <41F02ACC.4090800@bell-labs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: "gonzalo.camarillo@ericsson.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.4 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit I don't know what to think of this. My gut reaction is that the Accept mechanism is on the verge of breaking. If we do this, pretty soon every single SIP messages is going to have 5k bytes of accept headers. Perhaps we need to rethink about *when* certain things that could go in the accept header are put in so not every messages has all of them. Adam pointed out that the number of MIME types the average PC client can accept is truly staggering and most clients just don't bother to provide most of the but still accept them. This resulted in MSRP defining * to just say, ok yah and give me whatever else you want. If someone receives a geopriv XML extension inside some PIDF, they still work because the XML allows them to skip what they don't understand. So I guess I am asking what is a use case where we need this level of detail. Cullen PS - nice draft On 1/20/05 12:03 PM, "Volker Hilt" wrote: > Folks, > > we have submitted a draft, which defines a new Accept header field > parameter that can be used to indicate support for MIME type extensions. > In particular, this parameter can be used to indicate support for > additional XML namespaces, which extend an XML-based media type. > > http://www.ietf.org/internet-drafts/draft-hilt-sip-ext-neg-00.txt > > Comments are very welcome. > > -- Volker > > > > _______________________________________________ > 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 Jan 29 11:45:39 2005 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 LAA22316 for ; Sat, 29 Jan 2005 11:45:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuw0l-0007DF-G6 for sip-web-archive@ietf.org; Sat, 29 Jan 2005 12:03:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuvgx-0003ez-8c; Sat, 29 Jan 2005 11:43:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuvgA-0003To-58 for sip@megatron.ietf.org; Sat, 29 Jan 2005 11:42:34 -0500 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 LAA22185 for ; Sat, 29 Jan 2005 11:42:31 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuvxi-00079A-Es for sip@ietf.org; Sat, 29 Jan 2005 12:00:43 -0500 Received: from razor.cs.columbia.edu (IDENT:moDM1v4qjZSQeqjHmtYzvX5+HBNvx9o1@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0TGgIir016558 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 29 Jan 2005 11:42:23 -0500 (EST) Received: from [127.0.0.1] (IDENT:lKYAnZnibVtEHQUoO3vPS8+xo0oyOgSv@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0TGgGiw012547; Sat, 29 Jan 2005 11:42:17 -0500 Message-ID: <41FBBCBD.7030103@cs.columbia.edu> Date: Sat, 29 Jan 2005 11:41:33 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] draft-hilt-sip-ext-neg-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.29.3 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Volker Hilt , "gonzalo.camarillo@ericsson.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: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit I think generally Accept-* makes sense if the receiver of that header has true choices in sending alternate content. This makes some, very limited, sense for content, where sometimes content is available in multiple formats, although this also seems to be rather rare in practice. In other cases, it doesn't really help much except to accelerate failure discovery and, maybe, avoid transmission of optional data that the receiver has to toss due to lack of understanding. It is not clear that either case really applies to the labeling of XML schema. Cullen Jennings wrote: > I don't know what to think of this. My gut reaction is that the Accept > mechanism is on the verge of breaking. If we do this, pretty soon every > single SIP messages is going to have 5k bytes of accept headers. > > Perhaps we need to rethink about *when* certain things that could go in the > accept header are put in so not every messages has all of them. > > Adam pointed out that the number of MIME types the average PC client can > accept is truly staggering and most clients just don't bother to provide > most of the but still accept them. This resulted in MSRP defining * to just > say, ok yah and give me whatever else you want. > > If someone receives a geopriv XML extension inside some PIDF, they still > work because the XML allows them to skip what they don't understand. So I > guess I am asking what is a use case where we need this level of detail. > > Cullen > > PS - nice draft > > On 1/20/05 12:03 PM, "Volker Hilt" wrote: > > >>Folks, >> >>we have submitted a draft, which defines a new Accept header field >>parameter that can be used to indicate support for MIME type extensions. >>In particular, this parameter can be used to indicate support for >>additional XML namespaces, which extend an XML-based media type. >> >>http://www.ietf.org/internet-drafts/draft-hilt-sip-ext-neg-00.txt >> >>Comments are very welcome. >> >>-- Volker >> >> >> >>_______________________________________________ >>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 Jan 29 13:33:50 2005 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 NAA01231 for ; Sat, 29 Jan 2005 13:33:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuxhT-000147-JV for sip-web-archive@ietf.org; Sat, 29 Jan 2005 13:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuxOp-0000pm-JN; Sat, 29 Jan 2005 13:32:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuxNq-0000ez-D6 for sip@megatron.ietf.org; Sat, 29 Jan 2005 13:31:47 -0500 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 NAA01140 for ; Sat, 29 Jan 2005 13:31:43 -0500 (EST) Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuxfL-00011a-Mv for sip@ietf.org; Sat, 29 Jan 2005 13:49:56 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j0TIVLXJ040671; Sat, 29 Jan 2005 13:31:21 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j0TIVB7d063707; Sat, 29 Jan 2005 13:31:11 -0500 (EST) Received: from [127.0.0.1] ([135.104.20.67]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j0TIV6oD028846; Sat, 29 Jan 2005 13:31:11 -0500 (EST) Message-ID: <41FBD669.4050801@bell-labs.com> Date: Sat, 29 Jan 2005 13:31:05 -0500 From: Volker Hilt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne , Cullen Jennings Subject: Re: [Sip] draft-hilt-sip-ext-neg-00 References: <41FBBCBD.7030103@cs.columbia.edu> In-Reply-To: <41FBBCBD.7030103@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "gonzalo.camarillo@ericsson.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: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I think generally Accept-* makes sense if the receiver of that header > has true choices in sending alternate content. This makes some, very > limited, sense for content, where sometimes content is available in > multiple formats, although this also seems to be rather rare in > practice. In other cases, it doesn't really help much except to > accelerate failure discovery and, maybe, avoid transmission of optional > data that the receiver has to toss due to lack of understanding. > I fully agree. The intension of this parameter is not that the sender of announces every single XML namespace it supports. The idea is that there are cases where it is useful for the receiver of an Accept header receiver to know which extensions the sender supports because it can provide content in different formats or wants to avoid costs for gathering and/or transmitting information that is tossed away. An example where this is useful is PIDF-LO where the sender of an Accept header can announce the location object formats it supports (e.g. civilLoc). Another example are session policies, where the sender can announce supported policy extensions. E.g. if a firewall traversal extension is supported, the policy server can open pinholes and return the external addresses (which it shouldn't do if the client uses a different firewall traversal method). A third example is a wireless client that wants to use a minimal schema to minimize the size of a received document. I agree with Cullens point that the use of this parameter needs to be limited to these (probably rare) cases where it is useful. Thanks, Volker > It is not clear that either case really applies to the labeling of XML > schema. > > Cullen Jennings wrote: >> I don't know what to think of this. My gut reaction is that the Accept >> mechanism is on the verge of breaking. If we do this, pretty soon every >> single SIP messages is going to have 5k bytes of accept headers. >> >> Perhaps we need to rethink about *when* certain things that could go >> in the >> accept header are put in so not every messages has all of them. >> >> Adam pointed out that the number of MIME types the average PC client can >> accept is truly staggering and most clients just don't bother to provide >> most of the but still accept them. This resulted in MSRP defining * to >> just >> say, ok yah and give me whatever else you want. >> >> If someone receives a geopriv XML extension inside some PIDF, they still >> work because the XML allows them to skip what they don't understand. So I >> guess I am asking what is a use case where we need this level of detail. >> >> Cullen >> >> PS - nice draft >> >> On 1/20/05 12:03 PM, "Volker Hilt" wrote: >> >> >>> Folks, >>> >>> we have submitted a draft, which defines a new Accept header field >>> parameter that can be used to indicate support for MIME type extensions. >>> In particular, this parameter can be used to indicate support for >>> additional XML namespaces, which extend an XML-based media type. >>> >>> http://www.ietf.org/internet-drafts/draft-hilt-sip-ext-neg-00.txt >>> >>> Comments are very welcome. >>> >>> -- Volker >>> >>> >>> >>> _______________________________________________ >>> 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 -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ 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 Sun Jan 30 08:06:22 2005 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 IAA28145 for ; Sun, 30 Jan 2005 08:06:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvF4F-0000lo-6x for sip-web-archive@ietf.org; Sun, 30 Jan 2005 08:24:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvEiQ-0000hK-5o; Sun, 30 Jan 2005 08:02:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvEda-00084G-8v for sip@megatron.ietf.org; Sun, 30 Jan 2005 07:57:10 -0500 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 HAA27085 for ; Sun, 30 Jan 2005 07:57:09 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvEvJ-0000Tc-7o for sip@ietf.org; Sun, 30 Jan 2005 08:15:30 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0UCv6h5020466 for ; Sun, 30 Jan 2005 13:57:06 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 30 Jan 2005 13:56:58 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Sun, 30 Jan 2005 13:59:08 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'sip@ietf.org'" Date: Sun, 30 Jan 2005 13:56:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Jan 2005 12:56:58.0057 (UTC) FILETIME=[2EA43B90:01C506CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] Provisional response to terminate early dialog 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, Today, when a request gets forked, the forking proxy will "collect" final responses received from the different dialogs. The calling UAC, however, does now know when specific early dialogs are terminated, since the forking proxy will not forward the final answer. That means that the UAC may have to keep resources etc that it reserved when the early dialog was created (by a 18x provisional response) available until the proxy forwards a final response. Would it somehow be possible to define a "dialog has been terminated" response code that the proxy could send to the UAC directly each time it receives an error response from any of the forked dialogs. A provisional response code would probably be good, because it would be backward compatible (nodes that don't support it simply keeps the early dialog alive until the final response comes from the forking proxy, as today). There may have been some work on this issue, or similar, before, but I can't remember the details. 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 Sun Jan 30 09:51:56 2005 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 JAA06523 for ; Sun, 30 Jan 2005 09:51:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvGiO-0002xJ-OL for sip-web-archive@ietf.org; Sun, 30 Jan 2005 10:10:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvGHg-0005VR-1c; Sun, 30 Jan 2005 09:42:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvGEm-00050w-7t for sip@megatron.ietf.org; Sun, 30 Jan 2005 09:39:40 -0500 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 JAA05950 for ; Sun, 30 Jan 2005 09:39:38 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvGWW-0002jI-BT for sip@ietf.org; Sun, 30 Jan 2005 09:58:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 30 Jan 2005 06:39:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0UEd5Nt027513; Sun, 30 Jan 2005 06:39:05 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-124.cisco.com [10.86.240.124]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHJ63162; Sun, 30 Jan 2005 06:39:03 -0800 (PST) Message-ID: <41FCF187.8000702@cisco.com> Date: Sun, 30 Jan 2005 09:39:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Provisional response to terminate early dialog References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Christer Holmberg (JO/LMF) wrote: > Hi, > > Today, when a request gets forked, the forking proxy will "collect" final responses received from the different dialogs. > > The calling UAC, however, does now know when specific early dialogs are > terminated, since the forking proxy will not forward the final answer. > > That means that the UAC may have to keep resources etc that it reserved when the early dialog was created (by a 18x provisional response) > available until the proxy forwards a final response. This is a relatively small amount of time - 32 seconds. > > Would it somehow be possible to define a "dialog has been terminated" response code that the proxy could > send to the UAC directly each time it receives an error response from any of the forked dialogs. A provisional response code would probably be good, because it would be backward compatible (nodes that don't support it simply keeps the early dialog alive until the final response comes from the forking proxy, as today). I don't really see what the problem is. Is this 32 seconds or so that critical? Besides shaving a few seconds off the amount of time that a UAC holds transaction state, is there any other benefit? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 Jan 31 02:24:36 2005 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 CAA26458 for ; Mon, 31 Jan 2005 02:24:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvWDD-0003iq-D9 for sip-web-archive@ietf.org; Mon, 31 Jan 2005 02:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvVtk-0001en-9i; Mon, 31 Jan 2005 02:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvVrw-0000uQ-Ms for sip@megatron.ietf.org; Mon, 31 Jan 2005 02:21:08 -0500 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 CAA25952 for ; Mon, 31 Jan 2005 02:21:07 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvW9q-0003eL-Gu for sip@ietf.org; Mon, 31 Jan 2005 02:39:39 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0V7L5h5018139 for ; Mon, 31 Jan 2005 08:21:05 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Jan 2005 08:21:18 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 08:23:10 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Jonathan Rosenberg'" Subject: RE: [Sip] Provisional response to terminate early dialog Date: Mon, 31 Jan 2005 08:20:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 31 Jan 2005 07:21:18.0307 (UTC) FILETIME=[74D40330:01C50765] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: d185fa790257f526fedfd5d01ed9c976 Hi Jonathan, It's not so much about the time, and in paralell forking scenarios I think that time could be even longer, couldn't it? I'll try to explain the problem by giving a use case: A UAC sends an INVITE. A proxy forwards the INVITE to UAS_1, which establish an early dialog and starts sending some kind of early media to the UAC (there may also be additional offer/answer transactions before the media starts). After that UAS_2 sends an error response to the proxy, which then forwards the INVITE to UAS_2. Now, UAC has established, and may have reserved media/security/etc resources, for UAS_1, so it may choose not to accept the early dialog (or, at least possible early media) from UAS_2. Eg in 3GPP it is said that an UE may choose to reject additional early dialogs if they - for whatever reason - see a need to do so. However, if the UAC would know that the early dialog with UAS_1 has been terminated it could free all resources and possibly reserve newones for UAS_2. Also, it wouldn't have to think about things like media mixing etc - issues which have been very much discussed on this list. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 30. tammikuuta 2005 16:39 > To: Christer Holmberg (JO/LMF) > Cc: 'sip@ietf.org' > Subject: Re: [Sip] Provisional response to terminate early dialog > > > > > Christer Holmberg (JO/LMF) wrote: > > > Hi, > > > > Today, when a request gets forked, the forking proxy will > "collect" final responses received from the different dialogs. > > > > The calling UAC, however, does now know when specific early > dialogs are > > terminated, since the forking proxy will not forward the > final answer. > > > > That means that the UAC may have to keep resources etc that > it reserved when the early dialog was created (by a 18x > provisional response) > > available until the proxy forwards a final response. > > This is a relatively small amount of time - 32 seconds. > > > > > Would it somehow be possible to define a "dialog has been > terminated" response code that the proxy could > > send to the UAC directly each time it receives an error > response from any of the forked dialogs. A provisional > response code would probably be good, because it would be > backward compatible (nodes that don't support it simply keeps > the early dialog alive until the final response comes from > the forking proxy, as today). > > I don't really see what the problem is. Is this 32 seconds or so that > critical? Besides shaving a few seconds off the amount of time that a > UAC holds transaction state, is there any other benefit? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 Jan 31 12:49:35 2005 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 MAA28989 for ; Mon, 31 Jan 2005 12:49:35 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvfy9-0001Z4-H3 for sip-web-archive@ietf.org; Mon, 31 Jan 2005 13:08:14 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Cvfg7-0006Zq-VJ for sip-web-archive@ietf.org; Mon, 31 Jan 2005 12:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfVj-00024H-ON; Mon, 31 Jan 2005 12:38:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfPH-000193-Ey for sip@megatron.ietf.org; Mon, 31 Jan 2005 12:32:11 -0500 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 MAA26727 for ; Mon, 31 Jan 2005 12:32:08 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfhG-000114-Jo for sip@ietf.org; Mon, 31 Jan 2005 12:50:47 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0VHUxib037526 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Jan 2005 11:30:59 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <41FCF187.8000702@cisco.com> References: <41FCF187.8000702@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Provisional response to terminate early dialog Date: Mon, 31 Jan 2005 11:30:55 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , "Christer Holmberg \(JO/LMF\)" 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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit How is this bound to 64T1? It's an INVITE transaction - it can pend potentially indefinitely (though timer C will likely kick in to muck up the works). I can see the kind of cases Christer is considering: 1) You parallel fork to several places. All initiate early media. All but one return an error code that doesn't stimulate immediate forwarding in the proxy response context (say, 401just to see the situation, as odd as that would be to mix w/ early media). One leg just stays pending. The initiating UA will hold onto the resources for early media for _all_ of those legs until the pending leg completes. 2) If you have a serial forking proxy, and each leg initiates early media, at the end of the fork, the initiating UA is holding early media resources for each previous leg - it has no way to let go before it gets a final response. Personally, I see this as just one of the consequences of the terrible thing we did when we allowed early media in the first place. I am reticent to further complicate the protocol by introducing provisionals along the lines Christer is proposing - that step takes us most, if not all, of the way to having transactions within transactions. Taken to an extreme, this could solve HERFP by tunneling all the final responses on the other side of a proxy back to the UA so it might be able to do something about it (say they were 421 Extension Required responses: A UA could deal with those immediately by initiating a new branch, parallel forking at the UA (yuck)). This could even lead to pressure to change the merging rules so that a UA can deal with 401s as part of early dialogs by reissuing the request on a new branch (double-yuck). In shorter words, I think this is a problem we should admit we have, but not try to do anything about. If we _do_ choose to do something about it, then we better carefully bound the scope. RjS On Jan 30, 2005, at 8:39 AM, Jonathan Rosenberg wrote: > > > Christer Holmberg (JO/LMF) wrote: > >> Hi, >> Today, when a request gets forked, the forking proxy will "collect" >> final responses received from the different dialogs. >> The calling UAC, however, does now know when specific early dialogs >> are >> terminated, since the forking proxy will not forward the final answer. >> That means that the UAC may have to keep resources etc that it >> reserved when the early dialog was created (by a 18x provisional >> response) >> available until the proxy forwards a final response. > > This is a relatively small amount of time - 32 seconds. > >> Would it somehow be possible to define a "dialog has been terminated" >> response code that the proxy could >> send to the UAC directly each time it receives an error response from >> any of the forked dialogs. A provisional response code would probably >> be good, because it would be backward compatible (nodes that don't >> support it simply keeps the early dialog alive until the final >> response comes from the forking proxy, as today). > > I don't really see what the problem is. Is this 32 seconds or so that > critical? Besides shaving a few seconds off the amount of time that a > UAC holds transaction state, is there any other benefit? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 Mon Jan 31 12:55:42 2005 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 MAA29842 for ; Mon, 31 Jan 2005 12:55:41 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvg40-0001mE-SF for sip-web-archive@ietf.org; Mon, 31 Jan 2005 13:14:17 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Cvfly-0006ff-SR for sip-web-archive@ietf.org; Mon, 31 Jan 2005 12:55:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfbP-0002xL-4p; Mon, 31 Jan 2005 12:44:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfRf-0001hi-Ti for sip@megatron.ietf.org; Mon, 31 Jan 2005 12:34:40 -0500 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 MAA27096 for ; Mon, 31 Jan 2005 12:34:37 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvfjf-00017A-AD for sip@ietf.org; Mon, 31 Jan 2005 12:53:15 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0VHYVXn037956 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Jan 2005 11:34:33 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B9A198E-73AE-11D9-ADC2-000D93326732@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefersub-00.txt Date: Mon, 31 Jan 2005 11:34:28 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , Orit Levin , 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.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit The LC the chairs initiated ends today. Please read this draft and comment. It's very short - please do this now. We've talked about this idea a lot - let make sure the talk is captured in the draft. RjS On Jan 26, 2005, at 4:22 PM, Robert Sparks wrote: > Initial LC Comments: > > First paragraph of Section 3 calls out 481ing an initial NOTIFY. The > -dialog-usage- > draft shows that is a bad idea, especially for in-dialog REFERs. > Suggest trimming > the sentence to end after (Expires 0). > > Section 4 fourth paragraph: It would help implementers to call out > explicitly that the > 200 response to the REFER will not contain a Supported or Require > header containing > the norefersub token. > > Section 4 fifth paragraph: This needs more definition. How is it > rejected? 603, 420, or > something else? Implementors will need some guidance here on when to > use which > error response. I think (but am not dead certain at the moment) that > 420 is almost always > what you want to use. > > Section 4 sixth paragraph: Is Supported: in the response really the > right thing? Eventlist > uses Require: in the response to a SUBSCRIBE. The intent of the > normative behavior in > this paragraph is to let a Refer-issuer who only included Supported: > know whether or > not a subscription was actually created. Require: (I'm using this > extension) in the response > fits that better than Supported: (I could use this extension if you > want to). > > Section 4 sixth paragraph: Suggest replacing "In this case, no dialog > is created" with > "In this case, no implicit subscription is created. As a consequence, > no new dialog > is created if this REFER was issued outside any existing dialog." > > Section 5: Probably worth also calling out using Max-Forwards: 0 to > prevent forking > for those (rare now, but hopefully not rare forever) cases where > signaling can get to > the refer target without going through a proxy. > > Section 6: Must replace "tradewind" with "example" throughout. > > Section 8: "threads" should be "threats", It would be good to pull any > discussion > that led to this conclusion together for when the IESG asks if we > _really_ thought > about this. Have we talked about what would happen if a SIP > intermediary (or an > unauthorized MitM) just injected a Require: norefersub into a REFER > request? > > RjS > > > On Jan 24, 2005, at 5:07 PM, Rohan Mahy wrote: > >> Hi Folks, >> >> I'd like to begin an abbreviated WGLC for: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- >> norefersub-00.txt >> >> Since this document is extremely short and has been discussed >> extensively, WGLC will end on February 1st. >> >> 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 _______________________________________________ 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 Jan 31 17:16:37 2005 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 RAA10315 for ; Mon, 31 Jan 2005 17:16:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvk8b-0003n7-5t for sip-web-archive@ietf.org; Mon, 31 Jan 2005 17:35:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjAF-0004xz-E5; Mon, 31 Jan 2005 16:32:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CviRP-0004D9-L2; Mon, 31 Jan 2005 15:46:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18987; Mon, 31 Jan 2005 15:46:34 -0500 (EST) Message-Id: <200501312046.PAA18987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 31 Jan 2005 15:46:33 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-09.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 : Management Information Base for Session Initiation Protocol (SIP) Author(s) : K. Lingle, et al. Filename : draft-ietf-sip-mib-09.txt Pages : 93 Date : 2005-1-31 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy, Redirect and Registrar servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-09.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-mib-09.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-mib-09.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: <2005-1-31155431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-31155431.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--