From sip-bounces@ietf.org Mon Jan 02 12:35:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTaf-0005z0-8m; Mon, 02 Jan 2006 12:35:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTad-0005ys-Br for sip@megatron.ietf.org; Mon, 02 Jan 2006 12:35:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24206 for ; Mon, 2 Jan 2006 12:34:09 -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.43) id 1EtTfk-0007dS-71 for sip@ietf.org; Mon, 02 Jan 2006 12:40:41 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 02 Jan 2006 09:32:07 -0800 X-IronPort-AV: i="3.99,322,1131350400"; d="scan'208"; a="386182243:sNHT104492994342" Received: from dwingwxp (sjc-vpn5-775.cisco.com [10.21.91.7]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k02HW0H0020710; Mon, 2 Jan 2006 09:32:04 -0800 (PST) Message-Id: <200601021732.k02HW0H0020710@sj-core-4.cisco.com> From: "Dan Wing" To: "'Rohan Mahy'" , "'Dean Willis'" , "'SIP WG'" Date: Mon, 2 Jan 2006 09:31:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcYNa8HBqIZbY3r5SMGcRN7KXCkkeAB3Fcsw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4b46eb3d3f079780298a239c16e963de@ekabal.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: fwmiller@cornfed.com Subject: [Sip] RE: Jabber VoIP specs 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 > Hi Dean, Everyone, > > > Dean is correct. To interoperate with SIP, the Jingle client > needs to use burst mode (which I believe is mandatory to > implement). Neither Burst nor Dribble are mandatory according to: http://www.jabber.org/jeps/jep-0166.html#protocol-negotiate-modes which says only: "An implementation SHOULD support both modes: dribble and burst." Failing to declare a mandatory-to-implement mode will cause interoperability problems with Jingle clients, not to mention with SIP. To interoperate with IETF's ICE, Jingle clients need to support Burst. I suggest that jep-0166 make Burst mode mandatory to implement. > Below is > the best information I have based on personal discussions and a > conference call about two weeks ago with the authors. > > The idea is to use dribble mode only when a Jingle client is > talking to > a single instance (a fully qualified JID) that also supports dribble > mode (presumably discovered when subscribing to presence > information). > The motivation (primarily from Google) for dribble mode is to try > candidate-pairs that give the best bang for the buck (STUN and local > addresses), before fetching relay-derived addresses that will > often go > unused. In dribble mode, additional candidate pairs (for > TURN or other > relays) can be sent without waiting for any sort of lock-state > synchronization. > > To interoperate between a Jingle client and a non-ICE SIP UA, the > most-likely candidate would get mapped to the m-line. To > interoperate > with ICE-enabled UAs, a Jingle client could either gather a larger > number of candidate pairs in the initial burst (local, STUN, > TURN relay > with UDP, TURN relay with TCP, relay using TLS, etc..), or send a > relatively short burst that is likely to work (ex: STUN, local) and > then do the equivalent of an UPDATE (allowing the offer-answer state > machine to be in an appropriate state) if a new burst of additional > pairs is needed (incrementing the ICE generation counter). There are > several ideas of what to do in interop situations, but the details > still need to be worked out. Ignoring interop for a paragraph or two .... A question I have about Jingle's dribble mechanism is how a client would know that it should get some TURN-derived addresses and Dribble them? That is, does it first send two candidate addresses (local address, STUN address), wait seconds, and then get a TURN-derived address and Dribble that address? I'm curious if that's the technique, and how the value of is obtained. Perhaps that could be useful for ICE to consider for SIP. As to sending UPDATE to interoperate between a Dribble client and a SIP client, that is interesting but I don't believe anyone has considered what it would do to an already-running ICE state machine, especially as the newly-added TURN address would be on the m= line (because TURN is most likely to work it gets stuck on the m= line) and not on an additional candidate on the a=candidate line -- at least, per ICE's intention today. Of course, today, nobody has specified how UPDATE would work in conjunction with ICE. > A few folks, including myself, have pointed out some parts of the > Jingle spec that are not quite in-line with ICE. The authors > are aware > that there is some work to do and assured me they want Jingle to > interoperate cleanly with SIP+ICE. One of the authors told > me he would > like to wait until the next rev of ICE (-07) comes out before > committing new changes to Jingle. That's fair. > The Jabber Foundation also plans to write a SIP/Jingle gateway > specification, through their JEP process. I'm sure there will be > plenty of opportunity for the SIP community to review and > contribute to this gateway spec. I am confidant that we can interop SIP and Jingle signaling. It is endpoint interop that is most important; without that, we'll be forced to use media relays to interoperate between SIP and Jingle. Media relays, bad. -d > thanks, > -rohan > > > > -------- Original Message -------- > > Subject: Re: [Sip] Jabber VoIP specs > > Date: Sat, 24 Dec 2005 21:44:10 -0600 > > From: Dean Willis > > To: Dan Wing > > CC: sip@ietf.org, fwmiller@cornfed.com > > References: <200512230210.jBN2AfQK006363@sj-core-5.cisco.com> > > > > If I'm reading this right, interworking between SIP and Jabber using > > ICE is going to require "burst" mode in the Jabber implementations > > every time. Without it, interworking failure appears to be > very likely. > > > > This is a good point. Anybody here working on the jingle stuff and > > can get a change made? Rohan? > > -- > > Dean > > > > > > On Dec 22, 2005, at 8:10 PM, Dan Wing wrote: > > > >>> -----Original Message----- > >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >>> Behalf Of fwmiller@cornfed.com > >>> Sent: Friday, December 16, 2005 1:11 PM > >>> To: sip@ietf.org > >>> Subject: [Sip] Jabber VoIP specs > >>> > >>> > >>> For those that may not have seen this, the Jabber Foundation > >>> has published their VoIP signaling and media encoding specs. > >>> These specs have been reconciled with Google Talk if I read > >>> the introductory comments correctly. I'd be interested in > >>> any discussion of the design of these protocols by the SIP > >>> gurus here... > >> > >> Thanks for mentioning the specifications. > >> > >>> http://www.jabber.org/jeps/jep-0166.html > >> > >> This specification describes a 'dribble' mode and a 'burst' > >> mode to exchange endpoint candidate addresses. Only > >> 'burst' mode is compatible with ICE (draft-ietf-mmusic-ice). > >> > >> Section 6.5.2 says that both modes are only SHOULDs. > >> > >> If we want to have compatibility with Jingle, they'll have > >> to make 'burst' mode a MUST. > >> > >> -d _______________________________________________ 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 03 00:52:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etf6M-0004rB-CD; Tue, 03 Jan 2006 00:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etf6K-0004qv-57 for sip@megatron.ietf.org; Tue, 03 Jan 2006 00:52:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03655 for ; Tue, 3 Jan 2006 00:51:36 -0500 (EST) Received: from c243-111.rim.net ([216.9.243.111] helo=MHS02YKF.rim.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtfBW-0004Xv-SZ for sip@ietf.org; Tue, 03 Jan 2006 00:58:15 -0500 Received: from ngw02ykf.rim.net ([10.102.108.31]) by MHS02YKF.rim.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 00:52:38 -0500 Importance: normal Priority: normal Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw02ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2006010300523821898 ; Tue, 03 Jan 2006 00:52:38 -0500 Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Jan 2006 00:52:38 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Expert review fordraft-allen-sipping-poc-p-answer-state-header-01 Date: Tue, 3 Jan 2006 00:52:36 -0500 Message-ID: Thread-Topic: [Sip] Expert review fordraft-allen-sipping-poc-p-answer-state-header-01 thread-index: AcYFpdaANiDzueEEQded7SC55H+0ZgKg28oA From: "Andrew Allen" To: "Jeroen van Bemmel" , "Cullen Jennings" , X-OriginalArrivalTime: 03 Jan 2006 05:52:38.0429 (UTC) FILETIME=[E724CCD0:01C61029] X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: 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 Jerome, No I didn't consider this was necessary.=20 In fact the need for a parameter at all in the P-Answer-State header is really only for completeness and to ensure that you can positively indicate a confirmed response since a value of "Confirmed" in the P-Answer-State header in a 200 OK has the same semantics of a 200 OK without the P-Answer-State header. Andrew -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: Tuesday, December 20, 2005 3:42 PM To: Cullen Jennings Cc: Andrew Allen; Dean Willis Subject: Re: [Sip] Expert review fordraft-allen-sipping-poc-p-answer-state-header-01 Andrew, Cullen, Brief question: Did you consider to allow generic parameters in the P-header=20 (even though none are defined right now?) I remember someone saying that this was commonly done for new SIP headers,=20 it wouldn't be the first time that in hindsight we'd like to add a=20 parameter... Regards, jeroen ----- Original Message -----=20 From: "Dean Willis" To: "Sip" Cc: "Andrew Allen" ; "Cullen Jennings" Sent: Tuesday, December 20, 2005 8:34 PM Subject: [Sip] Expert review=20 fordraft-allen-sipping-poc-p-answer-state-header-01 > > Andrew has submitted the new OMA PoC P-header draft draft-allen-=20 > sipping-poc-p-answer-state-header-01. > > We've been asked by OMA to complete an expert review of this draft=20 > according to the process specified in RFC 3427, the SIP Change Process. > > I've asked Cullen Jennings to take a look at the draft and see if he'll=20 > be willing to provide the expert review. > > In conjunction with that, it would be nice if we could all read the=20 > draft, and send any pertinent comments to the list and the author. > > Thanks, > > -- > 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=20 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. _______________________________________________ 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 05 18:32:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueaR-00069T-TL; Thu, 05 Jan 2006 18:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueaP-00069K-LE for sip@megatron.ietf.org; Thu, 05 Jan 2006 18:32:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10756 for ; Thu, 5 Jan 2006 18:30:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuegA-0003Sy-WD for sip@ietf.org; Thu, 05 Jan 2006 18:38:00 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2006 15:31:51 -0800 X-IronPort-AV: i="3.99,335,1131350400"; d="scan'208"; a="1764136588:sNHT35433232" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k05NVmQJ009630; Thu, 5 Jan 2006 15:31:49 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 18:31:48 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 18:31:47 -0500 Message-ID: <43BDAC63.5070505@cisco.com> Date: Thu, 05 Jan 2006 18:31:47 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Allen Subject: Re: [Sip] Expert review fordraft-allen-sipping-poc-p-answer-state-header-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2006 23:31:47.0785 (UTC) FILETIME=[32567B90:01C61250] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, 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 I side with Jerome on this. It is just good insurance for the future. Not providing for this can prove unfortunate in the future. For example, the P-Asserted-Identity header is defined to not take parameters at all. It has recently started to look like parameters on that header would be an excellent way to assert roles for the identity. But that option is not available because the existing definition is not extensible for parameters. Paul Andrew Allen wrote: > Jerome, > > No I didn't consider this was necessary. > > In fact the need for a parameter at all in the P-Answer-State header is > really only for completeness and to ensure that you can positively > indicate a confirmed response since a value of "Confirmed" in the > P-Answer-State header in a 200 OK has the same semantics of a 200 OK > without the P-Answer-State header. > > Andrew > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Tuesday, December 20, 2005 3:42 PM > To: Cullen Jennings > Cc: Andrew Allen; Dean Willis > Subject: Re: [Sip] Expert review > fordraft-allen-sipping-poc-p-answer-state-header-01 > > Andrew, Cullen, > > Brief question: Did you consider to allow generic parameters in the > P-header > (even though none are defined right now?) > I remember someone saying that this was commonly done for new SIP > headers, > it wouldn't be the first time that in hindsight we'd like to add a > parameter... > > Regards, > > jeroen > > ----- Original Message ----- > From: "Dean Willis" > To: "Sip" > Cc: "Andrew Allen" ; "Cullen Jennings" > > Sent: Tuesday, December 20, 2005 8:34 PM > Subject: [Sip] Expert review > fordraft-allen-sipping-poc-p-answer-state-header-01 > > > >>Andrew has submitted the new OMA PoC P-header draft draft-allen- >>sipping-poc-p-answer-state-header-01. >> >>We've been asked by OMA to complete an expert review of this draft >>according to the process specified in RFC 3427, the SIP Change > > Process. > >>I've asked Cullen Jennings to take a look at the draft and see if > > he'll > >>be willing to provide the expert review. >> >>In conjunction with that, it would be nice if we could all read the >>draft, and send any pertinent comments to the list and the author. >> >>Thanks, >> >>-- >>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 > > > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > _______________________________________________ > 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 05 18:44:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euemc-0002bT-F7; Thu, 05 Jan 2006 18:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euemb-0002bD-1y for sip@megatron.ietf.org; Thu, 05 Jan 2006 18:44:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11971 for ; Thu, 5 Jan 2006 18:43:21 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuesK-0003wV-Ge for sip@ietf.org; Thu, 05 Jan 2006 18:50:35 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2006 15:44:13 -0800 X-IronPort-AV: i="3.99,336,1131350400"; d="scan'208"; a="247389222:sNHT756155060" 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 k05NiDc1026630; Thu, 5 Jan 2006 15:44:13 -0800 (PST) Received: from 10.21.121.65 ([10.21.121.65]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Jan 2006 23:44:13 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 05 Jan 2006 15:44:27 -0800 From: Cullen Jennings To: , "sip@ietf.org" Message-ID: Thread-Topic: draft-ietf-sip-outbound-01: determining STUN support Thread-Index: AcYFLdmoGGTADXEhEdqFpgARJEEJ/AAQb4TgAziXyVY= 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] Re: draft-ietf-sip-outbound-01: determining STUN support 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 On 12/20/05 6:22 AM, "Markus.Isomaki@nokia.com" wrote: > Hi, > > Is it so that the only way for a UA to know if the proxy supports STUN for > keep-alive purposes is so that the UA needs to be configured to know it? Is > the only reason for the existence of sip-stun URI parameter that it is a > convenient way to represent the configuration information, i.e. it makes no > difference if the parameter is present in the actual SIP requests sent by the > UA? yes - it's just a way to provide the configuration information > > Would there be any problem for the UA to test the support by sending a STUN > request to proxy IP address and port? This was originally suggested but many people were against sending a message that would be invalid and wanted to require configuration indicating STUN was allowed before sending a stun message. > If it does not succeed, it can start > using e.g. SIP OPTIONS as a keep-alive mechanism. Perhaps this kind of thing > could be mentioned in the draft. I think people thought the SIP OPTIONS was always a worse idea than the CRLF keep alive but I follow your idea. > > Regards, > Markus _______________________________________________ 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 06 01:21:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eukyr-0001hO-SF; Fri, 06 Jan 2006 01:21:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eukyo-0001f1-TT for sip@megatron.ietf.org; Fri, 06 Jan 2006 01:21:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07822 for ; Fri, 6 Jan 2006 01:20:22 -0500 (EST) Received: from [219.141.250.5] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eul4c-0006wu-Rr for sip@ietf.org; Fri, 06 Jan 2006 01:27:40 -0500 Received: from asechenshuping (cellon-t23.cellon.com.cn [10.2.5.92]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0ISN00GKRQQMZT@mail.cecwireless.com.cn> for sip@ietf.org; Fri, 06 Jan 2006 14:16:01 +0800 (CST) Date: Fri, 06 Jan 2006 14:16:15 +0800 From: Chen Shuping Subject: [SIP] Is there any RFC define call hold supplimentary service using SIP To: sip@ietf.org Message-id: <0ISN00GKTQQPZT@mail.cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-index: AcYSiLKfneA4cp2FRoagpjH1iCOdAQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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="===============0255545787==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0255545787== Content-type: multipart/alternative; boundary="Boundary_(ID_UV2eGEBQH/RRwteKebTMYg)" This is a multi-part message in MIME format. --Boundary_(ID_UV2eGEBQH/RRwteKebTMYg) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Hi,all Is there any RFC define call hold supplimentary service using SIP,I only find a expired draft. If there is any ,plese tell me Thank you. --Boundary_(ID_UV2eGEBQH/RRwteKebTMYg) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT
Hi,all
 
   Is there any RFC define call hold supplimentary service using SIP,I only find a
 
expired draft. If there is any ,plese tell me
 
   Thank you.
--Boundary_(ID_UV2eGEBQH/RRwteKebTMYg)-- --===============0255545787== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0255545787==-- From sip-bounces@ietf.org Fri Jan 06 01:39:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EulFe-000805-Jx; Fri, 06 Jan 2006 01:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EulFc-0007zt-0S for sip@megatron.ietf.org; Fri, 06 Jan 2006 01:39:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08862 for ; Fri, 6 Jan 2006 01:37:43 -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.43) id 1EulLR-0007T8-6B for sip@ietf.org; Fri, 06 Jan 2006 01:45:02 -0500 Received: from asbmail4.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with ESMTP id k066bgS2019761; Fri, 6 Jan 2006 14:37:42 +0800 Received: from asbmail1.sbell.com.cn ([172.24.208.61]) by asbmail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Jan 2006 14:38:46 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: =?gb2312?B?tPC4tDogW1NJUF0gSXMgdGhlcmUgYW55IFJGQyBkZWZpbmUgYw==?= =?gb2312?B?YWxsIGhvbGQgc3VwcGxpbWVudGFyeSBzZXJ2aWNlIHVzaW5nU0lQ?= Date: Fri, 6 Jan 2006 14:38:46 +0800 Message-ID: <60BBB1231E9EA443BD400F30A47C0A70AF6BF7@asbmail1.sbell.com.cn> Thread-Topic: [SIP] Is there any RFC define call hold supplimentary service usingSIP Thread-Index: AcYSiLKfneA4cp2FRoagpjH1iCOdAQAAuh+A From: "FCG LIU Qiang" To: "Chen Shuping" , X-OriginalArrivalTime: 06 Jan 2006 06:38:46.0507 (UTC) FILETIME=[D8493BB0:01C6128B] X-imss-version: 2.035 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.6 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 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="===============1535126872==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1535126872== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6128B.D81379F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6128B.D81379F1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Something can be found in RFC3264. -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org]=B4=FA=B1=ED Chen Shuping =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA1=D4=C26=C8=D5 14:16 =CA=D5=BC=FE=C8=CB: sip@ietf.org =D6=F7=CC=E2: [SIP] Is there any RFC define call hold supplimentary = service usingSIP Hi,all =20 Is there any RFC define call hold supplimentary service using SIP,I = only find a=20 =20 expired draft. If there is any ,plese tell me =20 Thank you. ------_=_NextPart_001_01C6128B.D81379F1 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Something can be=20 found in RFC3264.
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB:= sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]=B4=FA=B1=ED Chen = Shuping
=B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA1=D4=C26=C8=D5=20 14:16
=CA=D5=BC=FE=C8=CB: = sip@ietf.org
=D6=F7=CC=E2: [SIP] Is there any RFC define=20 call hold supplimentary service usingSIP

Hi,all
 
   Is = there any RFC=20 define call hold supplimentary service using SIP,I only find a=20
 
expired draft. If = there is=20 any ,plese tell me
 
   = Thank=20 you.
------_=_NextPart_001_01C6128B.D81379F1-- --===============1535126872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1535126872==-- From sip-bounces@ietf.org Mon Jan 09 06:29:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvvDO-00008e-Fz; Mon, 09 Jan 2006 06:29:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvvDM-00007Z-Uc for sip@megatron.ietf.org; Mon, 09 Jan 2006 06:29:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06981 for ; Mon, 9 Jan 2006 06:28:09 -0500 (EST) Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvvJq-0001JK-7Q for sip@ietf.org; Mon, 09 Jan 2006 06:36:11 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp6.clb.oleane.net with ESMTP id k09BTDDW018617 for ; Mon, 9 Jan 2006 12:29:13 +0100 Message-Id: <200601091129.k09BTDDW018617@smtp6.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 9 Jan 2006 12:28:13 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcYVD8ckOthRTNziQjm8f0ob/PYKJg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [Sip] TVoDSL Conference/Exhibition 2006 - 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="===============0451036342==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0451036342== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05D5_01C61518.2956CA70" This is a multi-part message in MIME format. ------=_NextPart_000_05D5_01C61518.2956CA70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The third edition of the TVoDSL conference/exhibition will start next January 24. It is still time to register to the very first worldwide event in the IPTV realm. Get all details at: http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm ------=_NextPart_000_05D5_01C61518.2956CA70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The third edition = of the TVoDSL conference/exhibition will start next January 24.
It is still time to register to the very first = worldwide event in the IPTV realm.

Get all details = at:

http://w= ww.upperside.fr/tvodsl2006/tvodsl2006intro.htm

 

 

------=_NextPart_000_05D5_01C61518.2956CA70-- --===============0451036342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0451036342==-- From sip-bounces@ietf.org Mon Jan 09 10:55:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzMj-0002zC-QR; Mon, 09 Jan 2006 10:55:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzMe-0002xm-6I; Mon, 09 Jan 2006 10:55:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24494; Mon, 9 Jan 2006 10:54:01 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzTA-0000nw-U5; Mon, 09 Jan 2006 11:02:05 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EvzMc-0002nK-VG; Mon, 09 Jan 2006 10:55:18 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 09 Jan 2006 10:55:18 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)' to Proposed Standard 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 The IESG has approved the following document: - 'Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt Technical Summary The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document specifies a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. It specifies the mechanisms and procedures for using these and how they can be used with the existing SIP privacy capabilities. It is desirable for SIP user agents to be able to send requests to destinations with which they have no previous association - just as in the telephone network today, one can receive a call from someone with whom one has no previous association, and still have a reasonable assurance that their displayed Caller-ID is accurate. A cryptographic approach, like the one described in this document, can probably provide a much stronger and less-spoofable assurance of identity than the telephone network provides today. Working Group Summary This specification required a number of tries and much analysis. There was strong consensus on the solution by the time it reached the version in this draft. Protocol Quality Eric Rescorla provided early architectural review of the work. The careful reading by the GEN-ART reviewer, Lakshminath Dondeti was valuable. Allison Mankin is the Responsible Area Director. _______________________________________________ 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 09 22:49:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwAWD-00081y-VP; Mon, 09 Jan 2006 22:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwAW4-00081g-64 for sip@megatron.ietf.org; Mon, 09 Jan 2006 22:49:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28032 for ; Mon, 9 Jan 2006 22:48:29 -0500 (EST) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwAcg-0001qg-93 for sip@ietf.org; Mon, 09 Jan 2006 22:56:39 -0500 Received: (qmail 26571 invoked by uid 510); 9 Jan 2006 22:03:27 -0600 Received: from vikramb@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. perlscan: 1.25-st-qms. Clear:RC:0(59.95.0.56):SA:0(-102.5/1.7):. Processed in 3.033683 secs); 10 Jan 2006 04:03:27 -0000 X-Spam-Status: No, hits=-102.5 required=1.7 X-Antivirus-MYDOMAIN-Mail-From: vikramb@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(59.95.0.56):SA:0(-102.5/1.7):. Processed in 3.033683 secs Process 26554) Received: from unknown (HELO vikramb) (vikramb@aftek.com@59.95.0.56) by mail.aftek.com with SMTP; 9 Jan 2006 22:03:24 -0600 Message-ID: <003e01c61598$f8934090$9100000a@vikramb> From: "VikramB" To: Date: Tue, 10 Jan 2006 09:20:06 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip-implementors@cs.columbia.edu Subject: [Sip] sip transcation query 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="===============1746445093==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1746445093== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C615C7.0BEF1190" This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C615C7.0BEF1190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, In rfc 3261 section 6 Definition=20 SIP Transaction :=20 .... ..... If the request is INVITE and the = final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to = an INVITE request is a separate transaction. My query is why ACK is considered as a part of same transaction when in = case of non-2xx response.? regards VIkram ------=_NextPart_000_0039_01C615C7.0BEF1190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
          &nbs= p;        =20 In rfc 3261 section 6 Definition
 
 SIP Transaction :=20
          &nbs= p;            = ;           =20 ....
          &nbs= p;            = ;           =20 .....
         &n= bsp;           &nb= sp;            =20 If the request is INVITE and the final response is a non-2xx, the = transaction=20 also
         includes an ACK = to the=20 response.  The ACK for a 2xx response to an INVITE request is a = separate=20 transaction.
 
 My query is why ACK is considered = as a part=20 of same transaction when in case of non-2xx response.?
 
 
 
regards
 
VIkram
------=_NextPart_000_0039_01C615C7.0BEF1190-- --===============1746445093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1746445093==-- From sip-bounces@ietf.org Tue Jan 10 04:31:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwFr3-0007FU-WB; Tue, 10 Jan 2006 04:31:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwFI9-0007dO-C2 for sip@megatron.ietf.org; Tue, 10 Jan 2006 03:55:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15604 for ; Tue, 10 Jan 2006 03:54:26 -0500 (EST) Received: from bay101-f27.bay101.hotmail.com ([64.4.56.37] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwFOo-0001rV-0B for sip@ietf.org; Tue, 10 Jan 2006 04:02:39 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Jan 2006 00:55:31 -0800 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Tue, 10 Jan 2006 08:55:31 GMT X-Originating-IP: [81.19.204.7] X-Originating-Email: [vimalsrivastava@hotmail.com] X-Sender: vimalsrivastava@hotmail.com In-Reply-To: <003e01c61598$f8934090$9100000a@vikramb> From: "vimal srivastava" To: vikramb@aftek.com, sip@ietf.org Date: Tue, 10 Jan 2006 03:55:31 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 10 Jan 2006 08:55:31.0986 (UTC) FILETIME=[9CC8F720:01C615C3] X-Spam-Score: 0.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Tue, 10 Jan 2006 04:31:46 -0500 Cc: sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] sip transcation query 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 Hi Actually if we look at the intent of ACK in case of 2xx response things become similar. the ACK for 2xx resonse may carry SDP and it will un-necessarily congest the network if it is sent thru all the proxies which are handling the messaging statefully. Ack is usually exchanged directly purpose of ACK is also to tell the end UAS that the originator has received 200 message (which has SDP) so that conversation can begin. so this signfies the need of ACK. in case of non-2xx final response, intent of ACK just to ackknowledge the previous node that i have received the non-2xx response. and if ACK is not received retransmit the non-2xx final response. if ACK is not sent then there is no way to tell the pevious node that final response is received. This is not needed in case of 2xx response becos, if 2xx is lost in between, UAC will not send ACK to the UAS and UAS will re-transmit 2xx response again. ACK for 2xx is exchanged directly (normally) between UAC and UAS so it does not congest the network. now if for non-2xx we leave the responsiblity of delivery to UAC (the way it makes sure for 2xx), then even if non-2xx is lost at some intermediate node, UAS will send non-2xx again and will traverse thru all the nodes which is not neded. so by using hop-by-hop reliablity mechanism, some network traffic is saved. UAS must know if 2xx is received at UAC or not because its acknolwedegement of SDP exchanged , else processing at UAS stops (convesation would not beging) for non-2xx response UAS does not care. it does not stop any processing for UAS so in essence: for non-2xx final response (for invite) reliability is ensured hop-by-hope and for 2xx final response (for invite) reliablity is ensured end to end. cheers v. From: "VikramB" To: CC: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] sip transcation query Date: Tue, 10 Jan 2006 09:20:06 +0530 Hello All, In rfc 3261 section 6 Definition SIP Transaction : .... ..... If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. My query is why ACK is considered as a part of same transaction when in case of non-2xx response.? regards VIkram _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 10 09:58:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKxY-00016L-ME; Tue, 10 Jan 2006 09:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKxX-00016G-CQ for sip@megatron.ietf.org; Tue, 10 Jan 2006 09:58:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08392 for ; Tue, 10 Jan 2006 09:57:32 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwL4F-0003lt-F4 for sip@ietf.org; Tue, 10 Jan 2006 10:05:48 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 0BBD86C01C for ; Tue, 10 Jan 2006 09:58:45 -0500 (EST) Subject: Re: [Sip] Expert review fordraft-allen-sipping-poc-p-answer-state-header-01 From: "Dale R. Worley" To: Sip In-Reply-To: <43BDAC63.5070505@cisco.com> References: <43BDAC63.5070505@cisco.com> Content-Type: text/plain Date: Tue, 10 Jan 2006 09:58:39 -0500 Message-Id: <1136905119.22416.12.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 On Thu, 2006-01-05 at 18:31 -0500, Paul Kyzivat wrote: > I side with Jerome on this. It is just good insurance for the future. > Not providing for this can prove unfortunate in the future. If there is anything the history of the Internet has taught us it is "Allow for upward-compatible extensions." This is especially sensible in a case like this, where all we need to do is provide a minimal extension to a parser to permit (and ignore) parameters. Dale -- interop.pingtel.com -- the public SIP phone interoperability test server _______________________________________________ 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 10 10:36:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLXV-0001Yd-TH; Tue, 10 Jan 2006 10:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLXT-0001XK-Qh for sip@megatron.ietf.org; Tue, 10 Jan 2006 10:35:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10675 for ; Tue, 10 Jan 2006 10:34:40 -0500 (EST) Received: from 64-199-49-245.ip.mcleodusa.net ([64.199.49.245] helo=txhouexch02.mcld.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwLeB-0004oy-K4 for sip@ietf.org; Tue, 10 Jan 2006 10:42:56 -0500 Received: by txhouexch02.mcld.net with Internet Mail Service (5.5.2657.72) id ; Sun, 8 Jan 2006 16:47:45 -0600 Message-ID: From: "Veazey, Christopher L." To: "'sip@ietf.org'" Date: Tue, 10 Jan 2006 09:35:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Sip] Diversion Header and PRI redirecting number 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="===============1489169538==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1489169538== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C615FB.81BDC4F0" 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_01C615FB.81BDC4F0 Content-Type: text/plain; charset="iso-8859-1" Is there a standardized method for mapping SIP diversion into a PRI redirecting number information element? RFC 3398 and ITU 1912 do not seem to address the issue completely. Thanks Chris Veazey NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. ------_=_NextPart_001_01C615FB.81BDC4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is = there a=20 standardized method for mapping SIP diversion into a PRI redirecting = number=20 information element? RFC 3398 and ITU 1912 do not seem to address the = issue=20 completely.
 
Thanks
Chris = Veazey



NOTICE: This electronic mail = transmission may contain confidential information and is intended only = for the person(s) named. Any use, copying or disclosure by any other = person is strictly prohibited. If you have received this transmission = in error, please notify the sender via e-mail.




------_=_NextPart_001_01C615FB.81BDC4F0-- --===============1489169538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1489169538==-- From sip-bounces@ietf.org Tue Jan 10 12:48:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNbG-0000BA-1O; Tue, 10 Jan 2006 12:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNbE-0000B5-OW for sip@megatron.ietf.org; Tue, 10 Jan 2006 12:48:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24413 for ; Tue, 10 Jan 2006 12:46:41 -0500 (EST) Received: from web34702.mail.mud.yahoo.com ([209.191.68.151]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwNhu-0002A0-T3 for sip@ietf.org; Tue, 10 Jan 2006 12:54:59 -0500 Received: (qmail 39419 invoked by uid 60001); 10 Jan 2006 17:47:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=K/NRaMhGT8Mc9Ik5SOrgzFed6LWRgooXoCWNHXgfz+1I/Fx3Y5XSEahOowoogtAphFw+002RnKjdRAnnnBCDzsixiAAgSzFvM6QMIZK2//6+tPnk0uvWu0PVg4euLyiN9SDXO8Eqbq5QuDm7cmdoFtcZcfERtDkby7qHQ1u0scA= ; Message-ID: <20060110174746.39417.qmail@web34702.mail.mud.yahoo.com> Received: from [134.56.105.33] by web34702.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2006 09:47:46 PST Date: Tue, 10 Jan 2006 09:47:46 -0800 (PST) From: Manish Joshi Subject: Re: [Sip] Diversion Header and PRI redirecting number To: "Veazey, Christopher L." , "'sip@ietf.org'" In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 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="===============0927273695==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0927273695== Content-Type: multipart/alternative; boundary="0-1353326670-1136915266=:39036" Content-Transfer-Encoding: 8bit --0-1353326670-1136915266=:39036 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Chris, The draft http://www.softarmor.com/wgdb/docs/draft-levy-sip-diversion-08.txt which talks about SIP Diversion Header, also talks about the ISDN/ISUP mapping for Diversion Header information. See section 10.3 for ISDN specific information. Now, this draft has expired in Feb 2005 and I am not aware of any attempts of it being revived or converted to RFC etc, but I think some of vendors have this implemented based on this draft along with ISDN/ISUP standards. HTH, Manish "Veazey, Christopher L." wrote: Is there a standardized method for mapping SIP diversion into a PRI redirecting number information element? RFC 3398 and ITU 1912 do not seem to address the issue completely. Thanks Chris Veazey NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. _______________________________________________ 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 --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-1353326670-1136915266=:39036 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Chris,
 
which talks about SIP Diversion Header, also talks about the ISDN/ISUP mapping for
Diversion Header information. See section 10.3 for ISDN specific information.
 
Now, this draft has expired in Feb 2005 and I am not aware of any attempts of it being revived or converted to RFC etc, but I think some of vendors have this implemented
based on this draft along with ISDN/ISUP standards.
 
HTH,
Manish


"Veazey, Christopher L." <Christopher.Veazey@McLeodUSA.com> wrote:
Is there a standardized method for mapping SIP diversion into a PRI redirecting number information element? RFC 3398 and ITU 1912 do not seem to address the issue completely.
 
Thanks
Chris Veazey



NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.



_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
T! his list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-1353326670-1136915266=:39036-- --===============0927273695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0927273695==-- From sip-bounces@ietf.org Tue Jan 10 13:18:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwO4c-0000uU-Cd; Tue, 10 Jan 2006 13:18:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwO4a-0000uP-QV for sip@megatron.ietf.org; Tue, 10 Jan 2006 13:18:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26429 for ; Tue, 10 Jan 2006 13:17:00 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwOBJ-00032s-7m for sip@ietf.org; Tue, 10 Jan 2006 13:25:19 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0AIIBVh023109; Tue, 10 Jan 2006 12:18:12 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Jan 2006 18:18:11 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29073D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Manish Joshi'" , "Veazey, Christopher L." , "'sip@ietf.org'" Subject: RE: [Sip] Diversion Header and PRI redirecting number Date: Tue, 10 Jan 2006 18:18:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 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 The current proposed manner of dealing with this within SIP is a combination of RFC 4244 and use of the URI parameters within http://www.ietf.org/internet-drafts/draft-jennings-sip-voicemail-uri-04.txt regards Keith -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Manish Joshi Sent: 10 January 2006 17:48 To: Veazey, Christopher L.; 'sip@ietf.org' Subject: Re: [Sip] Diversion Header and PRI redirecting number Hi Chris, The draft http://www.softarmor.com/wgdb/docs/draft-levy-sip-diversion-08.txt which talks about SIP Diversion Header, also talks about the ISDN/ISUP mapping for Diversion Header information. See section 10.3 for ISDN specific information. Now, this draft has expired in Feb 2005 and I am not aware of any attempts of it being revived or converted to RFC etc, but I think some of vendors have this implemented based on this draft along with ISDN/ISUP standards. HTH, Manish "Veazey, Christopher L." wrote: Is there a standardized method for mapping SIP diversion into a PRI redirecting number information element? RFC 3398 and ITU 1912 do not seem to address the issue completely. Thanks Chris Veazey NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip T! his list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. _______________________________________________ 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 11 11:06:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiUF-00076L-Fu; Wed, 11 Jan 2006 11:06:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiUE-000763-8a for sip@megatron.ietf.org; Wed, 11 Jan 2006 11:06:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22570 for ; Wed, 11 Jan 2006 11:04:50 -0500 (EST) Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewib9-0007PQ-8q for sip@ietf.org; Wed, 11 Jan 2006 11:13:20 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp12.clb.oleane.net with ESMTP id k0BG5t9D029089 for ; Wed, 11 Jan 2006 17:05:55 +0100 Message-Id: <200601111605.k0BG5t9D029089@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 11 Jan 2006 17:04:52 +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: AcYWyMGirKVCRIJFRQ+AeMt2rQ0sMg== X-Spam-Score: 0.2 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [Sip] International SIP Conference / WiMAX Summit 2006 - 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="===============0187786523==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0187786523== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0325_01C616D1.23D8E230" This is a multi-part message in MIME format. ------=_NextPart_000_0325_01C616D1.23D8E230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The International SIP conference and the WiMAX Summit will start next February 21st in Paris. The two events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access. The early registration 10% discount will end in one week. Get all details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get all details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0325_01C616D1.23D8E230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 The = International SIP conference and the WiMAX Summit will start next February 21st in = Paris. The two = events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access.

 

The early registration 10% discount will end = in one week.

 

Get all details on International SIP = at:

http://www.upp= erside.fr/sip2006/sip2006intro.htm

 

Get all details on the WiMAX Summit = at:

http://www= .upperside.fr/wimax2006/wimax2006intro.htm

 

 

 

------=_NextPart_000_0325_01C616D1.23D8E230-- --===============0187786523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0187786523==-- From sip-bounces@ietf.org Thu Jan 12 07:46:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex1qw-0002LD-Lt; Thu, 12 Jan 2006 07:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex1qu-0002Kw-7n for sip@megatron.ietf.org; Thu, 12 Jan 2006 07:46:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14721 for ; Thu, 12 Jan 2006 07:45:31 -0500 (EST) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex1xu-0002YE-Bk for sip@ietf.org; Thu, 12 Jan 2006 07:54:13 -0500 Received: (qmail 31113 invoked by uid 510); 12 Jan 2006 07:00:24 -0600 Received: from vikramb@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. perlscan: 1.25-st-qms. Clear:RC:0(203.129.224.108):SA:0(-102.5/1.7):. Processed in 6.42077 secs); 12 Jan 2006 13:00:24 -0000 X-Spam-Status: No, hits=-102.5 required=1.7 X-Antivirus-MYDOMAIN-Mail-From: vikramb@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(203.129.224.108):SA:0(-102.5/1.7):. Processed in 6.42077 secs Process 31080) Received: from unknown (HELO vikramb) (vikramb@aftek.com@203.129.224.108) by mail.aftek.com with SMTP; 12 Jan 2006 07:00:18 -0600 Message-ID: <012401c61776$4e081490$9100000a@vikramb> From: "VikramB" To: "vimal srivastava" , References: Date: Thu, 12 Jan 2006 18:17:05 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] sip transcation query 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 Thanks for the response , But i am bit confused now ! AFIK any final resopnse should terminate the session, then how came after non-2xx response the ACK still can be part of the same transcation !! vikram ----- Original Message ----- From: "vimal srivastava" To: ; Cc: Sent: Tuesday, January 10, 2006 2:25 PM Subject: RE: [Sip-implementors] sip transcation query > Hi > Actually if we look at the intent of ACK in case of 2xx response things > become similar. > the ACK for 2xx resonse may carry SDP and it will un-necessarily congest > the network if it is sent thru all the proxies which are handling the > messaging statefully. Ack is usually exchanged directly > purpose of ACK is also to tell the end UAS that the originator has > received 200 message (which has SDP) so that conversation can begin. so > this signfies the need of ACK. > > in case of non-2xx final response, intent of ACK just to ackknowledge the > previous node that i have received the non-2xx response. and if ACK is not > received retransmit the non-2xx final response. if ACK is not sent then > there is no way to tell the pevious node that final response is received. > > This is not needed in case of 2xx response becos, if 2xx is lost in > between, UAC will not send ACK to the UAS and UAS will re-transmit 2xx > response again. > ACK for 2xx is exchanged directly (normally) between UAC and UAS so it > does not congest the network. > now if for non-2xx we leave the responsiblity of delivery to UAC (the way > it makes sure for 2xx), then even if non-2xx is lost at some intermediate > node, UAS will send non-2xx again and will traverse thru all the nodes > which is not neded. so by using hop-by-hop reliablity mechanism, some > network traffic is saved. > > UAS must know if 2xx is received at UAC or not because its > acknolwedegement of SDP exchanged , else processing at UAS stops > (convesation would not beging) > for non-2xx response UAS does not care. it does not stop any processing > for UAS > > so in essence: > for non-2xx final response (for invite) reliability is ensured hop-by-hope > and > for 2xx final response (for invite) reliablity is ensured end to end. > > > > cheers > v. > > > > From: "VikramB" > To: > CC: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] sip transcation query > Date: Tue, 10 Jan 2006 09:20:06 +0530 > > Hello All, > In rfc 3261 section 6 Definition > > SIP Transaction : > .... > ..... > If the request is INVITE and the final > response is a non-2xx, the transaction also > includes an ACK to the response. The ACK for a 2xx response to > an INVITE request is a separate transaction. > > My query is why ACK is considered as a part of same transaction when in > case of non-2xx response.? > > > > regards > > VIkram > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ 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 12 13:21:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex756-0002u4-UX; Thu, 12 Jan 2006 13:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex754-0002ss-Ii for sip@megatron.ietf.org; Thu, 12 Jan 2006 13:21:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05243 for ; Thu, 12 Jan 2006 13:20:29 -0500 (EST) Received: from mail.us.es ([193.147.175.20] helo=us.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex7CC-0003zQ-Oh for sip@ietf.org; Thu, 12 Jan 2006 13:29:14 -0500 Received: (qmail 28793 invoked from network); 12 Jan 2006 19:21:29 +0100 Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 12 Jan 2006 19:21:29 +0100 Received: (qmail 16557 invoked from network); 12 Jan 2006 18:21:21 -0000 Received: from localhost (HELO us.es) (127.0.0.1) by us.es with SMTP; 12 Jan 2006 19:21:21 +0100 Received: (qmail 29735 invoked from network); 12 Jan 2006 19:21:21 +0100 Received: from cartuja.us.es (193.147.161.37) by us.es with SMTP; 12 Jan 2006 19:21:21 +0100 Received: from [192.168.200.51] (ait04.us.es [193.147.162.165]) by cartuja.us.es (8.9.3/8.9.1) with ESMTP id TAA16039; Thu, 12 Jan 2006 19:20:39 GMT Message-ID: <43C69DFD.6040302@yahoo.es> Date: Thu, 12 Jan 2006 19:20:45 +0100 From: =?ISO-8859-1?Q?=C1lvaro_Canivell_Garc=EDa_de_Paredes?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip , sipping , sip_yahoo , sip-implementators columbia CS Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on antivirus2 X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.64 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA05243 Cc: Subject: [Sip] Solutions to NAT: STUN 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 I have the following scenario (using a "customized" SIPCOMMUNICATOR and=20 JAINSIPPRESENCEPROXY, from JAIN): * a SIP server in a public IP address * two SIP clients in a local network (accessing internet through a=20 gateway - called 'A' from now on) The requests from clients to server find their way through the server=20 (naturally). The requests from the server to the clients do not find their way to the=20 clients.(naturally, unfortunatelly ;) ) So I am testing STUN in my clients. I get the public IP address from the=20 client, which allows me to write in the contact and via headersof my=20 requests, the public IP address that gives my client access to internet. In that way, the server will send subsequent request to the client, to=20 that public address (to the gateway A). My question is: How does that request (from server to client) find its=20 way "FROM the gateway A, TO the client in the local network"? Does STUN=20 give any help in this process? Thanks =C1lvaro _______________________________________________ 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 12 13:46:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7TG-0002Cj-4T; Thu, 12 Jan 2006 13:46:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7TD-0002CW-Ts for sip@megatron.ietf.org; Thu, 12 Jan 2006 13:46:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07882 for ; Thu, 12 Jan 2006 13:45:26 -0500 (EST) Received: from web52813.mail.yahoo.com ([206.190.49.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ex7aK-000525-Jj for sip@ietf.org; Thu, 12 Jan 2006 13:54:11 -0500 Received: (qmail 24079 invoked by uid 60001); 12 Jan 2006 18:46:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jjF3su9qO+76vmwchX4xrFYwvqu5fXOlITJjv7REljvYgp+aCC9R4vhruaQ2nCZ+t44hZRAjVNWPWDWNPOZBH8+DMSPxZlldaS5llKFy02ST0oNp691CkIbrKdT7PhKxiAtrxaGgfxcENG+MsRlmf01+h2g9zglIbElOsq+k81M= ; Message-ID: <20060112184633.24077.qmail@web52813.mail.yahoo.com> Received: from [85.101.200.100] by web52813.mail.yahoo.com via HTTP; Thu, 12 Jan 2006 10:46:33 PST Date: Thu, 12 Jan 2006 10:46:33 -0800 (PST) From: Fatih "Eyüp" NAR Subject: Re: [Sip] Solutions to NAT: STUN To: "Álvaro" Canivell "García" de Paredes , sip , sipping , sip_yahoo , sip-implementators columbia CS In-Reply-To: <43C69DFD.6040302@yahoo.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA07882 Cc: 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 depends on your NAT and it's configuration but basically two things to attention ; 1-private address&port binding against public ip & port 2-keeping the binding alive by periodically. in case your NAT is symetrical and/or both clients are in same private domain you will face STUN is not enough for you , check-out ICE which Mr.Rosenberg freezed lately :-) --- =C1lvaro Canivell Garc=EDa de Paredes wrote: > I have the following scenario (using a "customized" > SIPCOMMUNICATOR and=20 > JAINSIPPRESENCEPROXY, from JAIN): >=20 > * a SIP server in a public IP address > * two SIP clients in a local network (accessing > internet through a=20 > gateway - called 'A' from now on) >=20 > The requests from clients to server find their way > through the server=20 > (naturally). > The requests from the server to the clients do not > find their way to the=20 > clients.(naturally, unfortunatelly ;) ) >=20 > So I am testing STUN in my clients. I get the public > IP address from the=20 > client, which allows me to write in the contact and > via headersof my=20 > requests, the public IP address that gives my > client access to internet. > In that way, the server will send subsequent request > to the client, to=20 > that public address (to the gateway A). > My question is: How does that request (from server > to client) find its=20 > way "FROM the gateway A, TO the client in the local > network"? Does STUN=20 > give any help in this process? >=20 > Thanks >=20 > =C1lvaro >=20 > _______________________________________________ > Sip mailing list=20 > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip >=20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=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 Fri Jan 13 08:52:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPLa-0002wu-VE; Fri, 13 Jan 2006 08:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPLX-0002tq-Vb for sip@megatron.ietf.org; Fri, 13 Jan 2006 08:52:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06503 for ; Fri, 13 Jan 2006 08:50:42 -0500 (EST) Received: from mail.us.es ([193.147.175.20] helo=us.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExPSo-0003tK-OR for sip@ietf.org; Fri, 13 Jan 2006 08:59:38 -0500 Received: (qmail 18569 invoked from network); 13 Jan 2006 14:51:46 +0100 Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 13 Jan 2006 14:51:46 +0100 Received: (qmail 18792 invoked from network); 13 Jan 2006 13:51:36 -0000 Received: from localhost (HELO us.es) (127.0.0.1) by us.es with SMTP; 13 Jan 2006 14:51:36 +0100 Received: (qmail 17079 invoked from network); 13 Jan 2006 14:51:12 +0100 Received: from cartuja.us.es (193.147.161.37) by us.es with SMTP; 13 Jan 2006 14:51:12 +0100 Received: from [192.168.200.51] (ait04.us.es [193.147.162.165]) by cartuja.us.es (8.9.3/8.9.1) with ESMTP id OAA23851; Fri, 13 Jan 2006 14:50:28 GMT Message-ID: <43C7B02C.3080603@yahoo.es> Date: Fri, 13 Jan 2006 14:50:36 +0100 From: =?ISO-8859-1?Q?=C1lvaro_Canivell_Garc=EDa_de_Paredes?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Fatih_=5C=22Ey=FCp=5C=22_NAR=22?= , sip@ietf.org, sipping@ietf.org, sip_protocol@yahoogroups.com, sip-implementors@cs.columbia.edu Subject: Re: [Sip] Solutions to NAT: STUN References: <20060112184633.24077.qmail@web52813.mail.yahoo.com> In-Reply-To: <20060112184633.24077.qmail@web52813.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on antivirus2 X-Spam-Level: ** X-Spam-Status: No, hits=2.6 required=7.5 tests=SUSPICIOUS_RECIPS autolearn=no version=2.64 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA06503 Cc: 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 Hi there! >1-private address&port binding against public ip & >port > =20 > My clients have private addresses, and the server, a public address.=20 (besides, no dynamic IP) >2-keeping the binding alive by periodically. >in case your NAT is symetrical and/or both clients >are in same private domain you will face STUN is not >enough for you , check-out ICE which Mr.Rosenberg >freezed lately :-) > =20 > In my scenario, both clients are either in the same private LAN=20 sometimes, or one in a private LAN and another having a public address. I am not sure about the NAT type that I have (clients in the LAN access=20 the public IP through 2 routers, a SMC router, and a coyote linux=20 Software router). I 'll simply give STUN a try and analyze what happens. Thanks. =C1lvaro _______________________________________________ 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 13 10:53:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExREk-0003XM-Oj; Fri, 13 Jan 2006 10:53:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExREi-0003X9-W7 for sip@megatron.ietf.org; Fri, 13 Jan 2006 10:53:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15895 for ; Fri, 13 Jan 2006 10:51:45 -0500 (EST) Received: from server100.appriver.com ([207.97.227.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExRLt-0000SH-UV for sip@ietf.org; Fri, 13 Jan 2006 11:00:43 -0500 Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 13699360; Fri, 13 Jan 2006 10:52:45 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 13699338; Fri, 13 Jan 2006 10:52:38 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006011310441218682 ; Fri, 13 Jan 2006 10:44:12 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Jan 2006 10:50:11 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 13 Jan 2006 10:50:11 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-Spam-Score: 1.5 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [Sip] Session Timers RFC 4028 typo? 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="===============1247992333==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1247992333== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61859.09363EC6" 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_01C61859.09363EC6 Content-Type: text/plain In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. Please correct me if I am missing something. Manpreet ------_=_NextPart_001_01C61859.09363EC6 Content-Type: text/html
In Paragraph 9 for " UAS Behavior" there is a line stating:
 
If the incoming request contains a Supported header field with a
   value 'timer' but does not contain a Session-Expires header, it means
   that the UAS is indicating support for timers but is not requesting
   one.  The UAS may request a session timer in the 2XX response by
   including a Session-Expires header field.  The value MUST NOT be set
   to a duration lower than the value in the Min-SE header field in the
   request, if it is present.
Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one.
 
Please correct me if I am missing something.
 
 
Manpreet
------_=_NextPart_001_01C61859.09363EC6-- --===============1247992333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1247992333==-- From sip-bounces@ietf.org Sat Jan 14 00:53:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeML-0006Kt-JZ; Sat, 14 Jan 2006 00:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMJ-0006Kh-KG for sip@megatron.ietf.org; Sat, 14 Jan 2006 00:53:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20638 for ; Sat, 14 Jan 2006 00:52:28 -0500 (EST) Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExeTc-00084J-Nb for sip@ietf.org; Sat, 14 Jan 2006 01:01:34 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id EC629208BD for ; Sat, 14 Jan 2006 10:49:33 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id B8CDC211A6 for ; Sat, 14 Jan 2006 10:29:02 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:53:49 +0530 Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:44:31 +0530 Received: from wip-ectls-mx13.wipro.com ([203.91.193.31]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:26:28 +0530 Received: from wip-ectls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D1C06220004; Fri, 13 Jan 2006 22:26:27 +0530 (IST) Received: from animal.cs.columbia.edu (animal.cs.columbia.edu [128.59.16.237]) by wip-ectls-mx2.wipro.com (Postfix) with ESMTP id 7D93A264006; Fri, 13 Jan 2006 22:26:26 +0530 (IST) Received: from animal.cs.columbia.edu ([128.59.16.237]) by animal.cs.columbia.edu with esmtp (Exim 4.12) id 1ExREa-0005Mj-04; Fri, 13 Jan 2006 10:53:00 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by animal.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqur8020471 for ; Fri, 13 Jan 2006 10:52:56 -0500 (EST) Received: from server100.appriver.com (server100.appriver.com [207.97.227.91]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqmGt012876 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 13 Jan 2006 10:52:49 -0500 (EST) Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 13699360; Fri, 13 Jan 2006 10:52:45 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 13699338; Fri, 13 Jan 2006 10:52:38 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006011310441218682 ; Fri, 13 Jan 2006 10:44:12 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Jan 2006 10:50:11 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 13 Jan 2006 10:50:11 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-PMX-Version: 5.1.1.222179 X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Content-Filtered-By: Mailman/MimeDel 2.1.6 X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 16:56:30.0094 (UTC) FILETIME=[4CCC0AE0:01C61862] X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? 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 In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. Please correct me if I am missing something. Manpreet _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 14 00:53:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMN-0006LQ-6e; Sat, 14 Jan 2006 00:53:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMK-0006Km-59 for sip@megatron.ietf.org; Sat, 14 Jan 2006 00:53:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20637 for ; Sat, 14 Jan 2006 00:52:27 -0500 (EST) Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExeTc-00084L-Ng for sip@ietf.org; Sat, 14 Jan 2006 01:01:34 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 661DB208BE for ; Sat, 14 Jan 2006 10:49:35 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 04383211A8 for ; Sat, 14 Jan 2006 10:29:03 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:44:14 +0530 Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jan 2006 01:56:27 +0530 Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 23:04:30 +0530 Received: from wip-cdctls-mx13.wipro.com ([203.91.201.17]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:15:41 +0530 Received: from wip-cdctls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 707B82D4004; Fri, 13 Jan 2006 22:15:41 +0530 (IST) Received: from animal.cs.columbia.edu (animal.cs.columbia.edu [128.59.16.237]) by wip-cdctls-mx2.wipro.com (Postfix) with ESMTP id 1694540C002; Fri, 13 Jan 2006 22:15:40 +0530 (IST) Received: from animal.cs.columbia.edu ([128.59.16.237]) by animal.cs.columbia.edu with esmtp (Exim 4.12) id 1ExREa-0005Mj-03; Fri, 13 Jan 2006 10:53:00 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by animal.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqur8020471 for ; Fri, 13 Jan 2006 10:52:56 -0500 (EST) Received: from server100.appriver.com (server100.appriver.com [207.97.227.91]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqmGt012876 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 13 Jan 2006 10:52:49 -0500 (EST) Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 13699360; Fri, 13 Jan 2006 10:52:45 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 13699338; Fri, 13 Jan 2006 10:52:38 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006011310441218682 ; Fri, 13 Jan 2006 10:44:12 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Jan 2006 10:50:11 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 13 Jan 2006 10:50:11 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-PMX-Version: 5.1.1.222179 X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Content-Filtered-By: Mailman/MimeDel 2.1.6 X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 16:45:41.0383 (UTC) FILETIME=[CA229970:01C61860] X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? 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 In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. Please correct me if I am missing something. Manpreet _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 14 00:54:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMr-0006Vc-2a; Sat, 14 Jan 2006 00:54:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMp-0006V2-C5 for sip@megatron.ietf.org; Sat, 14 Jan 2006 00:54:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20660 for ; Sat, 14 Jan 2006 00:52:59 -0500 (EST) Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExeUF-00086B-J2 for sip@ietf.org; Sat, 14 Jan 2006 01:02:05 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 9BB1C210C7 for ; Sat, 14 Jan 2006 10:52:45 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 092622132E for ; Sat, 14 Jan 2006 10:29:49 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:23:38 +0530 Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:10:07 +0530 Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by chn-snr-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:09:44 +0530 Received: from wip-cdctls-mx13.wipro.com ([203.91.201.17]) by chn-snr-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:05:52 +0530 Received: from wip-cdctls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 355CE2D400C; Fri, 13 Jan 2006 22:05:52 +0530 (IST) Received: from animal.cs.columbia.edu (animal.cs.columbia.edu [128.59.16.237]) by wip-cdctls-mx2.wipro.com (Postfix) with ESMTP id CEFC240C006; Fri, 13 Jan 2006 22:05:51 +0530 (IST) Received: from animal.cs.columbia.edu ([128.59.16.237]) by animal.cs.columbia.edu with esmtp (Exim 4.12) id 1ExREa-0005Mj-08; Fri, 13 Jan 2006 10:53:00 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by animal.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqur8020471 for ; Fri, 13 Jan 2006 10:52:56 -0500 (EST) Received: from server100.appriver.com (server100.appriver.com [207.97.227.91]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqmGt012876 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 13 Jan 2006 10:52:49 -0500 (EST) Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 13699360; Fri, 13 Jan 2006 10:52:45 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 13699338; Fri, 13 Jan 2006 10:52:38 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006011310441218682 ; Fri, 13 Jan 2006 10:44:12 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Jan 2006 10:50:11 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 13 Jan 2006 10:50:11 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-PMX-Version: 5.1.1.222179 X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Content-Filtered-By: Mailman/MimeDel 2.1.6 X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 16:35:52.0614 (UTC) FILETIME=[6B339460:01C6185F] X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? 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 In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. Please correct me if I am missing something. Manpreet _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 14 00:54:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMt-0006Xd-GB; Sat, 14 Jan 2006 00:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMp-0006V7-Uw for sip@megatron.ietf.org; Sat, 14 Jan 2006 00:54:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20663 for ; Sat, 14 Jan 2006 00:52:59 -0500 (EST) Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExeUF-00086E-Je for sip@ietf.org; Sat, 14 Jan 2006 01:02:06 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 0459020A43 for ; Sat, 14 Jan 2006 10:52:45 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id AAF822132C for ; Sat, 14 Jan 2006 10:29:48 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:26:10 +0530 Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 23:08:02 +0530 Received: from wip-ectls-mx13.wipro.com ([203.91.193.31]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 23:08:02 +0530 Received: from wip-ectls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 491B6220004; Fri, 13 Jan 2006 23:08:02 +0530 (IST) Received: from animal.cs.columbia.edu (animal.cs.columbia.edu [128.59.16.237]) by wip-ectls-mx2.wipro.com (Postfix) with ESMTP id EC463264006; Fri, 13 Jan 2006 23:08:01 +0530 (IST) Received: from animal.cs.columbia.edu ([128.59.16.237]) by animal.cs.columbia.edu with esmtp (Exim 4.12) id 1ExREa-0005Mj-05; Fri, 13 Jan 2006 10:53:00 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by animal.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqur8020471 for ; Fri, 13 Jan 2006 10:52:56 -0500 (EST) Received: from server100.appriver.com (server100.appriver.com [207.97.227.91]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqmGt012876 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 13 Jan 2006 10:52:49 -0500 (EST) Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 13699360; Fri, 13 Jan 2006 10:52:45 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 13699338; Fri, 13 Jan 2006 10:52:38 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006011310441218682 ; Fri, 13 Jan 2006 10:44:12 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Jan 2006 10:50:11 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 13 Jan 2006 10:50:11 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-PMX-Version: 5.1.1.222179 X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Content-Filtered-By: Mailman/MimeDel 2.1.6 X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 17:38:02.0705 (UTC) FILETIME=[1A824C10:01C61868] X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? 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 In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. Please correct me if I am missing something. Manpreet _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 14 00:54:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMw-0006ZK-7c; Sat, 14 Jan 2006 00:54:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMq-0006VI-Ka for sip@megatron.ietf.org; Sat, 14 Jan 2006 00:54:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20674 for ; Sat, 14 Jan 2006 00:53:00 -0500 (EST) Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExeUF-000866-It for sip@ietf.org; Sat, 14 Jan 2006 01:02:06 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 9EBB920A3F for ; Sat, 14 Jan 2006 10:52:44 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 7BC112132B for ; Sat, 14 Jan 2006 10:29:48 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:47:42 +0530 Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:15:02 +0530 Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by chn-snr-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:15:00 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.91.201.25]) by chn-snr-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 22:14:24 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0BBAF2A8004; Fri, 13 Jan 2006 22:14:24 +0530 (IST) Received: from animal.cs.columbia.edu (animal.cs.columbia.edu [128.59.16.237]) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id A7CD93F4002; Fri, 13 Jan 2006 22:14:23 +0530 (IST) Received: from animal.cs.columbia.edu ([128.59.16.237]) by animal.cs.columbia.edu with esmtp (Exim 4.12) id 1ExREa-0005Mj-06; Fri, 13 Jan 2006 10:53:00 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by animal.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqur8020471 for ; Fri, 13 Jan 2006 10:52:56 -0500 (EST) Received: from server100.appriver.com (server100.appriver.com [207.97.227.91]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqmGt012876 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 13 Jan 2006 10:52:49 -0500 (EST) Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 13699360; Fri, 13 Jan 2006 10:52:45 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 13699338; Fri, 13 Jan 2006 10:52:38 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006011310441218682 ; Fri, 13 Jan 2006 10:44:12 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Jan 2006 10:50:11 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 13 Jan 2006 10:50:11 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-PMX-Version: 5.1.1.222179 X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Content-Filtered-By: Mailman/MimeDel 2.1.6 X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 16:44:24.0441 (UTC) FILETIME=[9C462E90:01C61860] X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? 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 In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. Please correct me if I am missing something. Manpreet _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 14 00:54:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMy-0006a5-6k; Sat, 14 Jan 2006 00:54:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeMs-0006XS-Oj for sip@megatron.ietf.org; Sat, 14 Jan 2006 00:54:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20691 for ; Sat, 14 Jan 2006 00:53:02 -0500 (EST) Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExeUF-00086H-Jy for sip@ietf.org; Sat, 14 Jan 2006 01:02:07 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 4FE6620A7B for ; Sat, 14 Jan 2006 10:52:45 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id D9D302132D for ; Sat, 14 Jan 2006 10:29:48 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:29:29 +0530 Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 23:08:49 +0530 Received: from wip-ectls-mx15.wipro.com ([203.91.193.29]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 23:08:42 +0530 Received: from wip-ectls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3EA53220012; Fri, 13 Jan 2006 23:08:27 +0530 (IST) Received: from animal.cs.columbia.edu (animal.cs.columbia.edu [128.59.16.237]) by wip-ectls-mx4.wipro.com (Postfix) with ESMTP id DFF3D2A4006; Fri, 13 Jan 2006 23:08:26 +0530 (IST) Received: from animal.cs.columbia.edu ([128.59.16.237]) by animal.cs.columbia.edu with esmtp (Exim 4.12) id 1ExREa-0005Mj-07; Fri, 13 Jan 2006 10:53:00 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by animal.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqur8020471 for ; Fri, 13 Jan 2006 10:52:56 -0500 (EST) Received: from server100.appriver.com (server100.appriver.com [207.97.227.91]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0DFqmGt012876 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 13 Jan 2006 10:52:49 -0500 (EST) Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 13699360; Fri, 13 Jan 2006 10:52:45 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 13699338; Fri, 13 Jan 2006 10:52:38 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006011310441218682 ; Fri, 13 Jan 2006 10:44:12 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Jan 2006 10:50:11 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 13 Jan 2006 10:50:11 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-PMX-Version: 5.1.1.222179 X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Content-Filtered-By: Mailman/MimeDel 2.1.6 X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 17:38:42.0346 (UTC) FILETIME=[322308A0:01C61868] X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? 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 In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. Please correct me if I am missing something. Manpreet _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 15 10:43:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9yb-0003WQ-Ix; Sun, 15 Jan 2006 10:39:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9yR-0002TM-1T for sip@megatron.ietf.org; Sun, 15 Jan 2006 10:39:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11887 for ; Sun, 15 Jan 2006 10:36:10 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey1ye-0005s5-Um for sip@ietf.org; Sun, 15 Jan 2006 02:07:03 -0500 Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0F6tVP24540; Sun, 15 Jan 2006 12:25:32 +0530 From: "Nataraju A B" To: "'Manpreet Singh'" , , Subject: RE: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? Date: Sun, 15 Jan 2006 12:28:34 +0530 Message-ID: <002301c619a1$1b9ed160$7302a8c0@Nataraju> MIME-Version: 1.0 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: <6E9C6C7D27E3714190801A551BE37610014C6ED3@server507.bur.ibasis.net> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: 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="===============0878156526==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0878156526== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C619CF.35570D60" This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C619CF.35570D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Manpreet Singh Sent: Friday, January 13, 2006 9:20 PM To: sip-implementors@cs.columbia.edu; sip@ietf.org Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo? Importance: High In Paragraph 9 for " UAS Behavior" there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. Its the incoming request to the UAS and this is discussing about the UAS behaviour to handle that request then shouldnt that be a UAC in the above paragraph instead of a UAS? So if the incoming request has supported header with timer with no session-expires header, the "UAC" is saying it supports timers but not requesting one. [ABN] looks like a typo error in RFC....you are right UAC is indicating it supports session timer but not requesting for this session.... Please correct me if I am missing something. Manpreet _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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_0024_01C619CF.35570D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] [Sip-implementors] Session Timers RFC 4028 = typo?

Comments inline...

Thanks & = Regards,

Nataraju A.B.

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Manpreet Singh
Sent: Friday, January 13, 2006 9:20 PM
To: sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: [Sip] [Sip-implementors] Session Timers RFC 4028 typo?
Importance: High

In = Paragraph 9 for " UAS Behavior" there is a line = stating:

 

If = the incoming request contains a Supported header field with = a

   value 'timer' but does not contain a = Session-Expires header, it means

   that the UAS is indicating support for timers but is not = requesting

   one.  The UAS may request a session = timer in the 2XX response by

   including a Session-Expires header = field.  The value MUST NOT be set

   to a duration lower than the value in the = Min-SE header field in the

   request, if it is = present.

Its = the incoming request to the UAS and this is discussing about the = UAS

behaviour to handle that request then shouldnt that be = a UAC in the above

paragraph instead of a UAS? So if the incoming request = has supported header

with timer with no session-expires header, the = "UAC" is saying it supports

timers but not requesting one.

[ABN] looks like a typo error in RFC....you are right UAC = is indicating it supports session timer but not = requesting for this session....

 

Please correct me if I am missing = something.

 

 

Manpreet

_______________________________________________

Sip-implementors mailing list

Sip-implementors@cs.columbia.edu

https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________

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_0024_01C619CF.35570D60-- --===============0878156526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0878156526==-- From sip-bounces@ietf.org Sun Jan 15 21:25:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyK3Y-0002z2-1b; Sun, 15 Jan 2006 21:25:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyK3U-0002yZ-FW for sip@megatron.ietf.org; Sun, 15 Jan 2006 21:25:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03264 for ; Sun, 15 Jan 2006 21:23:49 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyKBG-0005bW-H9 for sip@ietf.org; Sun, 15 Jan 2006 21:33:18 -0500 Received: by zproxy.gmail.com with SMTP id 9so1010290nzo for ; Sun, 15 Jan 2006 18:25:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=XOOH7CoW3sfq14iVQey5/jd7zcZVO9N2XnGJM/rwMsrko1hcwjTuABZYVec+cCpmVRUBAgXatYeYrinMa5BA/8WHKq9eAVe+b/jqESuAFdWAOJgj5+CDIFV0Qs/NV7m+8dG7X21LWPxbMnY1sU3nzyxyN3ruNXE05ikSnt2WBkg= Received: by 10.36.101.3 with SMTP id y3mr4524267nzb; Sun, 15 Jan 2006 18:25:06 -0800 (PST) Received: by 10.37.18.27 with HTTP; Sun, 15 Jan 2006 18:25:05 -0800 (PST) Message-ID: <8b2b8b9e0601151825n17fa1ee4sd153e56aa2df35d2@mail.gmail.com> Date: Mon, 16 Jan 2006 10:25:06 +0800 From: zuo bf To: asterisk-dev@lists.digium.com, asterisk-users@lists.digium.com, repro-devel@list.sipfoundry.org, repro-users@list.sipfoundry.org, sip@ietf.org, sipping@ietf.org, sipx-users@list.sipfoundry.org, osip2 , resiprocate-de , sipX developers Subject: [SIP] confused about how to treat NAT/FW, how do you deal with it ? MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: 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="===============0306330329==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0306330329== Content-Type: multipart/alternative; boundary="----=_Part_3870_21261862.1137378306459" ------=_Part_3870_21261862.1137378306459 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everybody, If this mail shouldn't be here then i am quite sorry for it, but i am really confused how the real implementation is. I have tested 7 network NAT types, 4 of them are symmetric NATs, 2 of the= m block UDP and some TCP traffic, 1 of them (this one is ADSL, not a corparation) is full cone, and none of them support hairpin. draft-ietf-sipping-nat-scenarios-03.txt is said to be the best current practice, but it only handles symmetric NATs, and using relay server is really inefficient, how do you deal with the bloc= k type NAT ? And there are draft-ietf-sip-connect-reuse-04.txt and draft-ietf-sip-outbound-01.txt serving for the purpose of connection reuse, but i don't see much difference, what's their real using scenario? And is there any proxy which supports these extensions? Hi guys, what's the real implementation, i can't get this information by simply searching the internet, i need your help. Any of your help will be greatly appreciated !!! Thx !!! sincerely, zbf ------=_Part_3870_21261862.1137378306459 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everybody,

   If this mail shouldn't be here then i am quite sorry for it, but i am really confused how the real implementation is.

  I have tested 7 network NAT types, 4 of them are symmetric NATs, 2 o= f them block UDP and some TCP traffic,
1 of them (this one is ADSL, not a corparation) is full cone, and none of t= hem support hairpin.
  draft-ietf-sipping-nat-scenarios-03.txt is said to be the best curre= nt practice, but it only handles symmetric NATs,
and using relay server is really inefficient, how do you deal with the bloc= k type NAT ?
  And there are draft-ietf-sip-connect-reuse-04.txt and draft-ietf-sip-outbound-01.txt serving for the purpose of connection
reuse, but i don't see much difference, what's their real using scenario? And is there any proxy which supports these extensions?
  Hi guys, what's the real implementation, i can't get this informatio= n by simply searching the internet, i need your help.

Any of your help will be greatly appreciated !!!
Thx !!!

sincerely,
zbf
------=_Part_3870_21261862.1137378306459-- --===============0306330329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0306330329==-- From sip-bounces@ietf.org Mon Jan 16 02:48:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyP5y-0002Uj-Va; Mon, 16 Jan 2006 02:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyP5w-0002Sq-Dy for sip@megatron.ietf.org; Mon, 16 Jan 2006 02:48:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20350 for ; Mon, 16 Jan 2006 02:46:39 -0500 (EST) Received: from smtp5.indiatimes.com ([203.199.93.15] helo=WS0005.indiatimes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyPDl-0006Rj-Kp for sip@ietf.org; Mon, 16 Jan 2006 02:56:13 -0500 Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id MAA25494; Mon, 16 Jan 2006 12:55:40 +0530 From: "thejeswara reddy" Message-Id: <200601160725.MAA25494@WS0005.indiatimes.com> To: "VikramB", Subject: Re: [Sip] sip transcation query Date: Mon, 16 Jan 2006 13:15:04 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thejeswara reddy List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org hai vikram , ACK is considered as part of Transaction for non-2xx final responses. because Trasacation will not be considered as closed until the recepion of ACK , ensures the reliable delivery of non-2XX final responses to client. thanks theja "VikramB" wrote:
Hello All,
                    In rfc 3261 section 6 Definition
 
 SIP Transaction :
                                   ...
                                   ....
                                   If the request is INVITE and the final response is a non-2xx, the transaction also
         includes an ACK to the response.  The ACK for a 2xx response to an INVITE request is a separate transaction.
 
 My query is why ACK is considered as a part of same transaction when in case of non-2xx response.?
 
 
 
regards
 
VIkram
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! _______________________________________________ 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 17 08:23:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyqo1-0005SJ-E5; Tue, 17 Jan 2006 08: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 1Eyqny-0005SA-IV for sip@megatron.ietf.org; Tue, 17 Jan 2006 08:23:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15431 for ; Tue, 17 Jan 2006 08:21:57 -0500 (EST) From: Udit_Goyal@3com.com Received: from plmler3.mail.eds.com ([199.228.142.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyqw3-0008JA-M5 for sip@ietf.org; Tue, 17 Jan 2006 08:31:47 -0500 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler3.mail.eds.com (8.13.4/8.12.10) with ESMTP id k0HDNE57019897; Tue, 17 Jan 2006 07:23:14 -0600 Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id k0HDMPm4022802; Tue, 17 Jan 2006 07:22:25 -0600 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id k0HDMOsf022763; Tue, 17 Jan 2006 07:22:25 -0600 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Tue, 17 Jan 2006 18:49:07 +0530 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 01/17/2006 05:22:25 AM, Serialize complete at 01/17/2006 05:22:25 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip-implementors@cs.columbia.edu Subject: [Sip] Case-sensitive: WWW-Authenticate header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0408189592==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0408189592== Content-Type: multipart/alternative; boundary="=_alternative 00493DE5652570F9_=" This is a multipart message in MIME format. --=_alternative 00493DE5652570F9_= Content-Type: text/plain; charset="US-ASCII" Hi, Just want to know if "WWW-Authenticate" header is case-sensitive while parsing the SIP message, because one of the tool that I am using is rejecting "Www-Authenticate" header encoded by Pingtel stack. -Udit --=_alternative 00493DE5652570F9_= Content-Type: text/html; charset="US-ASCII"
Hi,

Just want to know if "WWW-Authenticate" header is case-sensitive while parsing the SIP message,
because one of the tool that I am using is rejecting "Www-Authenticate" header encoded by Pingtel stack.

-Udit --=_alternative 00493DE5652570F9_=-- --===============0408189592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0408189592==-- From sip-bounces@ietf.org Tue Jan 17 09:24:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyrkm-0001yi-Qf; Tue, 17 Jan 2006 09:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyrkl-0001yS-MX for sip@megatron.ietf.org; Tue, 17 Jan 2006 09:24:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19328 for ; Tue, 17 Jan 2006 09:22:41 -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.43) id 1Eyrst-0002HU-JV for sip@ietf.org; Tue, 17 Jan 2006 09:32:32 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2006 06:23:56 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0HENlk7021333; Tue, 17 Jan 2006 06:23:55 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 09:23:52 -0500 Received: from [192.168.1.102] ([10.86.242.60]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 09:23:51 -0500 Message-ID: <43CCFDF7.4030008@cisco.com> Date: Tue, 17 Jan 2006 09:23:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Udit_Goyal@3com.com Subject: Re: [Sip] Case-sensitive: WWW-Authenticate header References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2006 14:23:51.0926 (UTC) FILETIME=[A3C18160:01C61B71] X-Spam-Score: 2.2 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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 Header field names are not case sensitive. -Jonathan R. Udit_Goyal@3com.com wrote: > > Hi, > > Just want to know if "WWW-Authenticate" header is case-sensitive while > parsing the SIP message, > because one of the tool that I am using is rejecting "Www-Authenticate" > header encoded by Pingtel stack. > > -Udit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Tue Jan 17 15:50:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxmV-0001xF-CW; Tue, 17 Jan 2006 15:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxmF-0001sb-Ir; Tue, 17 Jan 2006 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16642; Tue, 17 Jan 2006 15:48:37 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyxuQ-00065u-Kx; Tue, 17 Jan 2006 15:58:31 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EyxmD-0008DT-JX; Tue, 17 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-with-norefersub-04.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 --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 Session Initiation Protocol REFER Method Implicit Subscription Author(s) : O. Levin Filename : draft-ietf-sip-refer-with-norefersub-04.txt Pages : 10 Date : 2006-1-17 This specification defines a way to suppress an implicit subscription with the Session Initiation Protocol (SIP) REFER method. A new SIP option tag "norefersub" is defined to indicate support for this extension. A new SIP header field "Refer-Sub" is defined to request the usage of this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub-04.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-04.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-04.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: <2006-1-17114556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-with-norefersub-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-with-norefersub-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-17114556.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 17 15:50:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyxms-00023l-Kz; Tue, 17 Jan 2006 15:50:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxmG-0001tD-K1; Tue, 17 Jan 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16649; Tue, 17 Jan 2006 15:48:37 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyxuQ-00065z-O6; Tue, 17 Jan 2006 15:58:31 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EyxmD-0008Dc-KV; Tue, 17 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-feature-param-01.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 --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 : Conveying Feature Tags with Session Initiation Protocol REFER Method Author(s) : O. Levin, A. Johnston Filename : draft-ietf-sip-refer-feature-param-01.txt Pages : 7 Date : 2006-1-17 This document extends the REFER method, defined in RFC 3515, to convey feature parameters defined in RFC 3840. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param-01.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-feature-param-01.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-feature-param-01.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: <2006-1-17114843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-feature-param-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-feature-param-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-17114843.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 17 18:50:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez0ac-0000WO-Ae; Tue, 17 Jan 2006 18:50:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez0aS-0000RJ-5w; Tue, 17 Jan 2006 18:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06349; Tue, 17 Jan 2006 18:48:38 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez0if-00067F-1L; Tue, 17 Jan 2006 18:58:33 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ez0aQ-0004kT-6o; Tue, 17 Jan 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Jan 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-acr-code-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 --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 : Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-acr-code-00.txt Pages : 7 Date : 2006-1-17 The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-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-acr-code-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-acr-code-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: <2006-1-17171755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-acr-code-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-acr-code-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-17171755.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jan 18 12:44:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHLv-0000xj-LU; Wed, 18 Jan 2006 12:44:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHLu-0000wi-Eg for sip@megatron.ietf.org; Wed, 18 Jan 2006 12:44:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07798 for ; Wed, 18 Jan 2006 12:42:45 -0500 (EST) Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzHUG-00032s-G3 for sip@ietf.org; Wed, 18 Jan 2006 12:52:50 -0500 Received: from il-tlv-bridge02.comverse.com (il-tlv-bridge02.comverse.com [10.115.242.50]) by il-tlv-smtpout2.icomverse.com (8.13.4/8.13.4) with ESMTP id k0IHi7oi022304 for ; Wed, 18 Jan 2006 19:44:07 +0200 Received: from il-tlv-mail03.comverse.com ([10.115.242.227]) by il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 19:44:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 19:44:06 +0200 Message-ID: Thread-Topic: Re-Invite before ACK Thread-Index: AcYcVsesiMU4PR9DTMe818AKkoUtAQ== From: "Miloslavsky Evgeny" To: X-OriginalArrivalTime: 18 Jan 2006 17:44:07.0428 (UTC) FILETIME=[C7F75C40:01C61C56] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] Re-Invite before ACK 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="===============0353406421==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0353406421== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C56.C7E79EE7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C56.C7E79EE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello there. What is an UAS behavior in case it recieves re-invite before it recieves ACK to previously transmitted 200 OK for an initial Invite. ------_=_NextPart_001_01C61C56.C7E79EE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-Invite before ACK

Hello = there.

What is = an UAS behavior in case it recieves re-invite before it recieves ACK to = previously transmitted 200 OK for an initial Invite.

------_=_NextPart_001_01C61C56.C7E79EE7-- --===============0353406421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0353406421==-- From sip-bounces@ietf.org Wed Jan 18 13:46:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIJl-0001S9-Eh; Wed, 18 Jan 2006 13:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIJj-0001RV-EK for sip@megatron.ietf.org; Wed, 18 Jan 2006 13:45:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12194 for ; Wed, 18 Jan 2006 13:44:33 -0500 (EST) Received: from web34702.mail.mud.yahoo.com ([209.191.68.151]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzIS4-0004yc-VJ for sip@ietf.org; Wed, 18 Jan 2006 13:54:39 -0500 Received: (qmail 71111 invoked by uid 60001); 18 Jan 2006 18:45:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hBKHBAcVVJi+y0x9ETq9cjYUBCZT949rm6EfofgEGkpJFCFQyezBX7wWTTuCQAGpBcos8byr6NfN8FzQOwYlWWvgAX/n9ncHxxs1u9HqzHPrWOFdKS3cx2iEpnBE3HKBGZjqbKAkiB0QKbYxiCESAdC4wiIxHgz4l7Jeb/Z/nVU= ; Message-ID: <20060118184545.71109.qmail@web34702.mail.mud.yahoo.com> Received: from [134.56.105.33] by web34702.mail.mud.yahoo.com via HTTP; Wed, 18 Jan 2006 10:45:45 PST Date: Wed, 18 Jan 2006 10:45:45 -0800 (PST) From: Manish Joshi Subject: Re: [Sip] Re-Invite before ACK To: Miloslavsky Evgeny , sip@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 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="===============0852722013==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0852722013== Content-Type: multipart/alternative; boundary="0-466368338-1137609945=:70593" --0-466368338-1137609945=:70593 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA12194 Hi, =20 The spec seems doesnt seem to be very clear on this.=20 An ACK to first Invite is a new transaction as the Invite transaction c= ompleted as soon as UAS sends final response as 200OK. UAC is now free to= send a new re-invite along with the ACK to the first Invite. Now since t= he packet ordering is not _ensured_, a reinvite can always come to UAS be= fore ACK and hence UAS should be able to accept it. =20 BTW, this might also be an implementation option, where you chose to Ig= nore the re-invite in case the first INVITE did not have an offer and 200= OK was the one with the offer and ACK will contain the media-answer.=20 =20 My two cents. -Manish Miloslavsky Evgeny wrote: Hello there. What is an UAS behavior in case it recieves re-invite before it recieve= s ACK to previously transmitted 200 OK for an initial Invite. _______________________________________________ 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 =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-466368338-1137609945=:70593 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA12194
Hi,
 
The spec seems doesnt seem to be = very clear on this.
An ACK to first Invite is a new transact= ion as the Invite transaction completed as soon as UAS sends final respon= se as 200OK. UAC is now free to send a new re-invite along with the ACK t= o the first Invite. Now since the packet ordering is not _ensured_, a rei= nvite can always come to UAS before ACK and hence UAS should be able to a= ccept it.
 
BTW, this might also be an imple= mentation option, where you chose to Ignore the re-invite in case the fir= st INVITE did not have an offer and 200 OK was the one with the offer and= ACK will contain the media-answer.
 
My tw= o cents.
-Manish

Miloslavsky Evgeny <Evgeny.M= iloslavsky@comverse.com> wrote:
<= div dir=3Dltr>Hello there.=
What is an UAS behavior in case it recieves re-invite before = it recieves ACK to previously transmitted 200 OK for an initial Invite.
_______________________________________________
Sip = mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is f= or NEW development of the core SIP Protocol
Use sip-implementors@cs.co= lumbia.edu for questions on current sip
Use sipping@ietf.org for new d= evelopments on the application of sip

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-466368338-1137609945=:70593-- --===============0852722013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0852722013==-- From sip-bounces@ietf.org Wed Jan 18 14:15:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzImO-0001jI-Bx; Wed, 18 Jan 2006 14:15:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzImM-0001it-0S for sip@megatron.ietf.org; Wed, 18 Jan 2006 14:15:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14549 for ; Wed, 18 Jan 2006 14:14:08 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzIuj-00061y-2m for sip@ietf.org; Wed, 18 Jan 2006 14:24:14 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k0IJF1OB020136; Wed, 18 Jan 2006 14:15:10 -0500 (EST) From: "Brett Tate" To: "'Miloslavsky Evgeny'" , Subject: RE: [Sip] Re-Invite before ACK Date: Wed, 18 Jan 2006 14:15:45 -0500 Message-ID: <002601c61c63$9b62eed0$2c28a8c0@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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: 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 > What is an UAS behavior in case it receives re-invite before > it receives ACK to previously transmitted 200 OK for an > initial Invite. If the ACK is expected to contain an SDP, a 500 response with Retry-After must be returned. Otherwise I think that it is implementer specific to accept it or return the 500 response. _______________________________________________ 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 18 14:33:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJ3T-0006Fy-KR; Wed, 18 Jan 2006 14:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJ3S-0006Ft-5O for sip@megatron.ietf.org; Wed, 18 Jan 2006 14:33:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16138 for ; Wed, 18 Jan 2006 14:31:48 -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.43) id 1EzJBp-0006g7-7P for sip@ietf.org; Wed, 18 Jan 2006 14:41:54 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2006 11:33:03 -0800 X-IronPort-AV: i="3.99,381,1131350400"; d="scan'208"; a="393284390:sNHT39192736" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0IJX1Qk025583; Wed, 18 Jan 2006 11:33:02 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 11:33:01 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.144.226]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 11:32:44 -0800 Message-Id: <4.3.2.7.2.20060118125946.03457fd8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jan 2006 13:32:43 -0600 To: Manish Joshi , Miloslavsky Evgeny , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] Re-Invite before ACK In-Reply-To: <20060118184545.71109.qmail@web34702.mail.mud.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 18 Jan 2006 19:32:44.0726 (UTC) FILETIME=[F4941D60:01C61C65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: 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 At 10:45 AM 1/18/2006 -0800, Manish Joshi wrote: >Hi, > >The spec seems doesnt seem to be very clear on this. >An ACK to first Invite is a new transaction as the Invite transaction=20 >completed as soon as UAS sends final response as 200OK. UAC is now free to= =20 >send a new re-invite along with the ACK to the first Invite. I don't believe so. I believe the stated behavior of the UAC is that it=20 cannot send a new INVITE within a dialog until the ACK is sent. The UAC is= =20 free to send any new INVITE outside of an existing dialog though. Section=20 14.1 covers this I believe. >Now since the packet ordering is not _ensured_, a reinvite can always come= =20 >to UAS before ACK and hence UAS should be able to accept it. Section 14.2 faintly implies a 491 is appropriate for the reINVITE in this= =20 situation (prior to receiving the ACK to the original INVITE/200 OK= exchange) > >BTW, this might also be an implementation option, where you chose to=20 >Ignore the re-invite in case the first INVITE did not have an offer and=20 >200 OK was the one with the offer and ACK will contain the media-answer. > >My two cents. >-Manish > >Miloslavsky Evgeny wrote: >Yahoo! Photos =96 Showcase holiday pictures in hardcover >Photo=20 >Books. You design it and we=92ll bind it! >_______________________________________________ >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 18 14:42:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJCN-0000zw-4E; Wed, 18 Jan 2006 14:42:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJCL-0000zq-Gj for sip@megatron.ietf.org; Wed, 18 Jan 2006 14:42:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17156 for ; Wed, 18 Jan 2006 14:40:59 -0500 (EST) Received: from web34706.mail.mud.yahoo.com ([209.191.68.155]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzJKj-00076o-IW for sip@ietf.org; Wed, 18 Jan 2006 14:51:06 -0500 Received: (qmail 63983 invoked by uid 60001); 18 Jan 2006 19:42:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KIDrqdu+O4UEVn6sUyL+ry5mg1P0oVqwEImo9g5lBiyJQbRiQif+IODnGEVv4qwFi5cXoAw6xtQ+loLFUkq8ry2+6+M0Me6R4pxNHh1lewB7orMMxeP+9RHp8DC9HaN7XOO4Mj5JRNM0fZY8iF4MMyE9FqeP87p/cPRFmLYyAnc= ; Message-ID: <20060118194215.63981.qmail@web34706.mail.mud.yahoo.com> Received: from [134.56.105.33] by web34706.mail.mud.yahoo.com via HTTP; Wed, 18 Jan 2006 11:42:15 PST Date: Wed, 18 Jan 2006 11:42:15 -0800 (PST) From: Manish Joshi Subject: Re: [Sip] Re-Invite before ACK To: "James M. Polk" , Miloslavsky Evgeny , sip@ietf.org In-Reply-To: <4.3.2.7.2.20060118125946.03457fd8@email.cisco.com> MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 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="===============1208804894==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1208804894== Content-Type: multipart/alternative; boundary="0-2135375311-1137613335=:59817" --0-2135375311-1137613335=:59817 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA17156 Iniline.. "James M. Polk" wrote: At 10:45 AM 1/18/2006 -0800,= Manish Joshi wrote: >Hi, > >The spec seems doesnt seem to be very clear on this. >An ACK to first Invite is a new transaction as the Invite transaction=20 >completed as soon as UAS sends final response as 200OK. UAC is now free = to=20 >send a new re-invite along with the ACK to the first Invite. >>I don't believe so. I believe the stated behavior of the UAC is that it= =20 >>cannot send a new INVITE within a dialog until the ACK is sent. The UAC= >>is free to send any new INVITE outside of an existing dialog though. >= >Section 14.1 covers this I believe. Actually I think 14.1 supports more what I mentioned above: =20 Quote: " Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. 1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE." UNQUOTE =20 ACK is a new transaction and receiving a final response (200OK) actuall= y completes the INVITE transaction and hence UAC is free to Initiate a ne= w (re)Invite transaction. =20 =20 >Now since the packet ordering is not _ensured_, a reinvite can always co= me=20 >to UAS before ACK and hence UAS should be able to accept it. >>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in t= his=20 >>situation (prior to receiving the ACK to the original INVITE/200 OK exc= hange) > >BTW, this might also be an implementation option, where you chose to=20 >Ignore the re-invite in case the first INVITE did not have an offer and=20 >200 OK was the one with the offer and ACK will contain the media-answer. > >My two cents. >-Manish > >Miloslavsky Evgeny wrote: >Yahoo! Photos =96 Showcase holiday pictures in hardcover >Photo=20 >Books. You design it and we=92ll bind it! >_______________________________________________ >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 > =09 --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands= ASAP. --0-2135375311-1137613335=:59817 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA17156
Iniline..

"James M. Polk" <jmpolk@ci= sco.com> wrote:
At 10:= 45 AM 1/18/2006 -0800, Manish Joshi wrote:
>Hi,
>
>The = spec seems doesnt seem to be very clear on this.
>An ACK to first I= nvite is a new transaction as the Invite transaction
>completed as= soon as UAS sends final response as 200OK. UAC is now free to
>se= nd a new re-invite along with the ACK to the first Invite.

>>= ;I don't believe so. I believe the stated behavior of the UAC is that it =
>>cannot send a new INVITE within a dialog until the ACK is sen= t. The UAC >>is free to send any new INVITE outside of an existing = dialog though. >>Section 14.1 covers this I believe.
Actually I think 14.1 supports more what I mentio= ned above:
 
Quote:
"   Note that a UAC MUS= T NOT initiate a new INVITE transaction within a
   dialog w= hile another INVITE transaction is in progress in either
   = direction.

      1. If there is an ongoin= g INVITE client transaction, the TU MUST
     = ;    wait until the transaction reaches the completed or t= erminated
         state befor= e initiating the new INVITE."
UNQUOTE
 
= ACK is a new transaction and receiving a final resp= onse (200OK) actually completes the INVITE transaction and hence UAC is f= ree to Initiate a new (re)Invite transaction.
 

>Now since the packet ordering is not _ensured_, a reinvite can always come
>to = UAS before ACK and hence UAS should be able to accept it.

>>= Section 14.2 faintly implies a 491 is appropriate for the reINVITE in thi= s
>>situation (prior to receiving the ACK to the original INVIT= E/200 OK exchange)

>
>BTW, this might also be an implemen= tation option, where you chose to
>Ignore the re-invite in case th= e first INVITE did not have an offer and
>200 OK was the one with = the offer and ACK will contain the media-answer.
>
>My two ce= nts.
>-Manish
>
>Miloslavsky Evgeny wrote:
>Yahoo! Photos =96 Showcase holiday pictures i= n hardcover
>Photo
>Books. You design it and we= =92ll bind it!
>_______________________________________________
>Sip ma= iling 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
>

=09

Yahoo! Photos
=20 Got holiday prints? See all= the ways to get quality prints in your hands ASAP. --0-2135375311-1137613335=:59817-- --===============1208804894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1208804894==-- From sip-bounces@ietf.org Wed Jan 18 15:01:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJVH-0006qp-Ld; Wed, 18 Jan 2006 15:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJVF-0006qb-Qi for sip@megatron.ietf.org; Wed, 18 Jan 2006 15:01:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18693 for ; Wed, 18 Jan 2006 15:00:31 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJdd-0007lb-1a for sip@ietf.org; Wed, 18 Jan 2006 15:10:38 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k0IK89lg015966 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 18 Jan 2006 14:08:11 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain To: Sip From: Dean Willis Date: Wed, 18 Jan 2006 14:01:50 -0600 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: 7bit Subject: [Sip] Test, please ignore 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 _______________________________________________ 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 18 20:21:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOU9-00087s-Us; Wed, 18 Jan 2006 20:21:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOU8-00087j-L4; Wed, 18 Jan 2006 20:21:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28535; Wed, 18 Jan 2006 20:19:42 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzOcZ-0007bh-BY; Wed, 18 Jan 2006 20:29:52 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0J1Jji10797; Wed, 18 Jan 2006 17:19:45 -0800 (PST) Message-Id: <200601190119.k0J1Jji10797@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 18 Jan 2006 17:19:45 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4320 on Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction 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 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4320 Title: Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction Author(s): R. Sparks Status: Standards Track Date: January 2006 Mailbox: rjsparks@estacado.net Pages: 7 Characters: 13853 Updates: 3261 I-D Tag: draft-sparks-sip-nit-actions-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4320.txt This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060118171835.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4320 --OtherAccess Content-Type: Message/External-body; name="rfc4320.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060118171835.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jan 18 20:22:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOVQ-0008MD-NL; Wed, 18 Jan 2006 20:22:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOVO-0008Lw-Q1; Wed, 18 Jan 2006 20:22:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28631; Wed, 18 Jan 2006 20:21:00 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzOdd-0007dv-Ja; Wed, 18 Jan 2006 20:30:58 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0J1LDi11655; Wed, 18 Jan 2006 17:21:13 -0800 (PST) Message-Id: <200601190121.k0J1LDi11655@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 18 Jan 2006 17:21:13 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4321 on Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction 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 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4321 Title: Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction Author(s): R. Sparks Status: Informational Date: January 2006 Mailbox: rjsparks@estacado.net Pages: 10 Characters: 22708 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-sparks-sip-nit-problems-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4321.txt This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. This document is a product of the Session Initiation Protocol Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060118171957.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4321 --OtherAccess Content-Type: Message/External-body; name="rfc4321.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060118171957.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 19 17:13:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi2K-0006Pn-He; Thu, 19 Jan 2006 17:13:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi2H-0006O5-Qu; Thu, 19 Jan 2006 17:13:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02184; Thu, 19 Jan 2006 17:12:14 -0500 (EST) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EziAs-0007hl-2E; Thu, 19 Jan 2006 17:22:36 -0500 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 19 Jan 2006 14:13:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,202,1136188800"; d="scan'208"; a="522334555:sNHT33985844" Received: from electron.jnpr.net ([172.24.15.21]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jan 2006 14:13:27 -0800 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jan 2006 14:13:27 -0800 Message-ID: Thread-Topic: unsubscribe Thread-Index: AcYclwXTWpVAirMlR/6UQhTq98+5wAArnpgQ From: "Raj Sahu" To: , , X-OriginalArrivalTime: 19 Jan 2006 22:13:27.0812 (UTC) FILETIME=[92B80440:01C61D45] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Sip] unsubscribe 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 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Wednesday, January 18, 2006 5:21 PM To: ietf-announce@ietf.org Cc: sip@ietf.org; rfc-editor@rfc-editor.org Subject: [Sip] RFC 4321 on Problems Identified Associated with the SessionInitiation Protocol's (SIP) Non-INVITE Transaction A new Request for Comments is now available in online RFC libraries. RFC 4321 Title: Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction Author(s): R. Sparks Status: Informational Date: January 2006 Mailbox: rjsparks@estacado.net Pages: 10 Characters: 22708 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-sparks-sip-nit-problems-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4321.txt This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.=20 This document is a product of the Session Initiation Protocol Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. _______________________________________________ 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 19 20:58:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlXU-0000CD-Qh; Thu, 19 Jan 2006 20:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlXR-0000Bx-A2 for sip@megatron.ietf.org; Thu, 19 Jan 2006 20:58:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21616 for ; Thu, 19 Jan 2006 20:56:38 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezlg4-0007FY-9z for sip@ietf.org; Thu, 19 Jan 2006 21:07:01 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITD008WXCF0WF@szxga03-in.huawei.com> for sip@ietf.org; Fri, 20 Jan 2006 10:04:12 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITD0008HCC0JT@szxga03-in.huawei.com> for sip@ietf.org; Fri, 20 Jan 2006 10:04:12 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITD002R6CSJIO@szxml01-in.huawei.com>; Fri, 20 Jan 2006 10:12:20 +0800 (CST) Date: Fri, 20 Jan 2006 09:57:21 +0800 From: Xiao Wang Subject: RE: [Sip] Re-Invite before ACK In-reply-to: <20060118194215.63981.qmail@web34706.mail.mud.yahoo.com> To: "'Manish Joshi'" , "'James M. Polk'" , "'Miloslavsky Evgeny'" , sip@ietf.org Message-id: <004c01c61d64$d9d99bd0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.4 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 Cc: 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="===============1988065991==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1988065991== Content-type: multipart/alternative; boundary="Boundary_(ID_P/QppaxjnLPwwd08hcLXOw)" This is a multi-part message in MIME format. --Boundary_(ID_P/QppaxjnLPwwd08hcLXOw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT I consider that ACK to INVITE's 200 OK is a individual transaction, but it must send rapidly after receive 200 OK, otherwise it is no significance to acknowledge the INVITE transaction. Even ACK send before the re-INVITE, for the reason of network delay, UAS may receive ACK after re-INVITE. Deal with this scenario may be an implementation or client policy. Xiao -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Manish Joshi Sent: Thursday, January 19, 2006 3:42 AM To: James M. Polk; Miloslavsky Evgeny; sip@ietf.org Subject: Re: [Sip] Re-Invite before ACK Iniline.. "James M. Polk" wrote: At 10:45 AM 1/18/2006 -0800, Manish Joshi wrote: >Hi, > >The spec seems doesnt seem to be very clear on this. >An ACK to first Invite is a new transaction as the Invite transaction >completed as soon as UAS sends final response as 200OK. UAC is now free to >send a new re-invite along with the ACK to the first Invite. >>I don't believe so. I believe the stated behavior of the UAC is that it >>cannot send a new INVITE within a dialog until the ACK is sent. The UAC >>is free to send any new INVITE outside of an existing dialog though. >>Section 14.1 covers this I believe. Actually I think 14.1 supports more what I mentioned above: Quote: " Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. 1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE." UNQUOTE ACK is a new transaction and receiving a final response (200OK) actually completes the INVITE transaction and hence UAC is free to Initiate a new (re)Invite transaction. >Now since the packet ordering is not _ensured_, a reinvite can always come >to UAS before ACK and hence UAS should be able to accept it. >>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in this >>situation (prior to receiving the ACK to the original INVITE/200 OK exchange) > >BTW, this might also be an implementation option, where you chose to >Ignore the re-invite in case the first INVITE did not have an offer and >200 OK was the one with the offer and ACK will contain the media-answer. > >My two cents. >-Manish > >Miloslavsky Evgeny wrote: >Yahoo! Photos - Showcase holiday pictures in hardcover >Photo >Books. You design it and we'll bind it! >_______________________________________________ >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 > _____ Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. --Boundary_(ID_P/QppaxjnLPwwd08hcLXOw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

I  consider that ACK to INVITE’s 200 OK is a individual transaction, but it must send rapidly after receive

200 OK, otherwise it is no significance to acknowledge the INVITE transaction. Even ACK send before the

re-INVITE, for the reason of network delay, UAS may receive ACK after re-INVITE.

 

 Deal with this scenario may be an implementation or client policy.

 

Xiao

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Manish Joshi
Sent: Thursday, January 19, 2006 3:42 AM
To: James M. Polk; Miloslavsky Evgeny; sip@ietf.org
Subject: Re: [Sip] Re-Invite before ACK

 

Iniline..

"James M. Polk" <jmpolk@cisco.com> wrote:

At 10:45 AM 1/18/2006 -0800, Manish Joshi wrote:
>Hi,
>
>The spec seems doesnt seem to be very clear on this.
>An ACK to first Invite is a new transaction as the Invite transaction
>completed as soon as UAS sends final response as 200OK. UAC is now free to
>send a new re-invite along with the ACK to the first Invite.

>>I don't believe so. I believe the stated behavior of the UAC is that it
>>cannot send a new INVITE within a dialog until the ACK is sent. The UAC >>is free to send any new INVITE outside of an existing dialog though. >>Section 14.1 covers this I believe.

Actually I think 14.1 supports more what I mentioned above:

 

Quote:

"   Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction.

      1. If there is an ongoing INVITE client transaction, the TU MUST
         wait until the transaction reaches the completed or terminated
         state before initiating the new INVITE."

UNQUOTE

 

ACK is a new transaction and receiving a final response (200OK) actually completes the INVITE transaction and hence UAC is free to Initiate a new (re)Invite transaction.

 


>Now since the packet ordering is not _ensured_, a reinvite can always come
>to UAS before ACK and hence UAS should be able to accept it.

>>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in this
>>situation (prior to receiving the ACK to the original INVITE/200 OK exchange)

>
>BTW, this might also be an implementation option, where you chose to
>Ignore the re-invite in case the first INVITE did not have an offer and
>200 OK was the one with the offer and ACK will contain the media-answer.
>
>My two cents.
>-Manish
>
>Miloslavsky Evgeny wrote:
>Yahoo! Photos – Showcase holiday pictures in hardcover
>Photo
>Books. You design it and we’ll bind it!
>_______________________________________________
>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
>

 

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.

--Boundary_(ID_P/QppaxjnLPwwd08hcLXOw)-- --===============1988065991== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1988065991==-- From sip-bounces@ietf.org Fri Jan 20 06:56:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezusb-0007dk-Uf; Fri, 20 Jan 2006 06:56:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzusZ-0007dK-Tb for sip@megatron.ietf.org; Fri, 20 Jan 2006 06:56:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05074 for ; Fri, 20 Jan 2006 06:55:03 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezv1I-0000yo-FJ for sip@ietf.org; Fri, 20 Jan 2006 07:05:33 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp8.clb.oleane.net with ESMTP id k0KBuA62005136 for ; Fri, 20 Jan 2006 12:56:11 +0100 Message-Id: <200601201156.k0KBuA62005136@smtp8.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 20 Jan 2006 12:55:01 +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: AcYduFfxOtVgHOrWTliPeVHbDeHwUw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [Sip] WiMAX Summit - International SIP 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="===============0871940527==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0871940527== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C61DC0.B9F67160" This is a multi-part message in MIME format. ------=_NextPart_000_0109_01C61DC0.B9F67160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WiMAX Summit and the International SIP conference will jointly open their doors in one month, on February 21st, in Paris. Everything you must know about broadband wireless access, VoIP and convergence will be delivered by operators and key technical players. An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their solutions. Get details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0109_01C61DC0.B9F67160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WiMAX Summit and the International SIP = conference will jointly open their doors in one month, on February 21st, in = Paris.

Everything you must know about broadband = wireless access, VoIP and convergence will be delivered by operators and key = technical players.

An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their = solutions.

 

Get details on International SIP = at:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

Get details on the WiMAX Summit = at:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

 

------=_NextPart_000_0109_01C61DC0.B9F67160-- --===============0871940527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0871940527==-- From sip-bounces@ietf.org Fri Jan 20 12:19:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzup-0001Bf-7y; Fri, 20 Jan 2006 12:19:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzum-0001B7-BH for sip@megatron.ietf.org; Fri, 20 Jan 2006 12:19:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01882 for ; Fri, 20 Jan 2006 12:17:40 -0500 (EST) Received: from web34215.mail.mud.yahoo.com ([66.163.178.130]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F003V-0003sw-BH for sip@ietf.org; Fri, 20 Jan 2006 12:28:12 -0500 Received: (qmail 33544 invoked by uid 60001); 20 Jan 2006 17:18:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OJI3NeSjYadtwhmv7VJWXeYhe0ZL5cMiva626KlAubc5TQig4YczXPn88nA8HG6Eq58MmKUM34NZgqvP4dXchrxCbCcAYZfaWDYZVoqLrSv8cf49Yk2hdJdlgmnIk5sPZIWME1k3/ia7bhwJaK/InbGo+qI9G7EtRjhg1STSv4w= ; Message-ID: <20060120171845.33539.qmail@web34215.mail.mud.yahoo.com> Received: from [59.144.33.104] by web34215.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 09:18:45 PST Date: Fri, 20 Jan 2006 09:18:45 -0800 (PST) From: srinidhi n To: sip@ietf.org, srinidhi104@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 8bit Cc: brett@broadsoft.com Subject: [Sip] Re: Re-Invite before ACK 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 Do Correct me if I am wrong. 1. I think unless an ACK is receved by the UAS, its transaction will not be complete and the UAS will continue to re-transmit the original 200 OK. 2. As per sec.13 of RFC 3261, If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section15. In this case, it is really difficult from the UAS perspective to predict if it will receive a "ACK" after the "Re-Invite" although its more likely to receive it. Hence, the UAS may chose to send 491 response. -Srinidhi __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 20 16:49:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F048Y-0005jq-LO; Fri, 20 Jan 2006 16:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F048V-0005dv-VW for sip@megatron.ietf.org; Fri, 20 Jan 2006 16:49:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04107 for ; Fri, 20 Jan 2006 16:48:07 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04HJ-00005p-Cx for sip@ietf.org; Fri, 20 Jan 2006 16:58:42 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0KLmr5m009734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Jan 2006 13:48:54 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0KLmqgt004302; Fri, 20 Jan 2006 13:48:52 -0800 (PST) Received: from NAEX07.na.qualcomm.com ([129.46.133.195]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 13:48:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Re-Invite before ACK Date: Fri, 20 Jan 2006 13:48:50 -0800 Message-ID: <4A599554B0051B4897DFDD6DF1EAED7901C65EF0@NAEX07.na.qualcomm.com> Thread-Topic: [Sip] Re-Invite before ACK Thread-Index: AcYdZbAv5gmyOeCrQgeytyzEbmzRogApAI1w From: "Jin, Haipeng" To: "Xiao Wang" , "Manish Joshi" , "James M. Polk" , "Miloslavsky Evgeny" , X-OriginalArrivalTime: 20 Jan 2006 21:48:51.0854 (UTC) FILETIME=[4D6472E0:01C61E0B] X-Spam-Score: 0.5 (/) X-Scan-Signature: 47dfdcb76bc7cdf600c30037ff1750ed Cc: 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="===============1968442198==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1968442198== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61E0B.4D177E65" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61E0B.4D177E65 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable If you look at the following sections from the RFC: =20 13.2.2.4 " The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. " =20 13.3.1.4 " The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response. =20 Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. =20 If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. " =20 One the UAC side, the INVITE transaction is considered completed only after 64*T1 of the first 2xx. On the UAS side, the server is expecting ACK within 64*T1 after the 2xx is sent, otherwise the session will be terminated. This, in essence, means that INVITE transaction will not complete until the ACK is sent and received. As a result I don't think the "reinvite before ack" makes practical sense. =20 Thanks, Haipeng =20 =20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Xiao Wang Sent: Thursday, January 19, 2006 5:57 PM To: 'Manish Joshi'; 'James M. Polk'; 'Miloslavsky Evgeny'; sip@ietf.org Subject: RE: [Sip] Re-Invite before ACK =20 I consider that ACK to INVITE's 200 OK is a individual transaction, but it must send rapidly after receive 200 OK, otherwise it is no significance to acknowledge the INVITE transaction. Even ACK send before the=20 re-INVITE, for the reason of network delay, UAS may receive ACK after re-INVITE. =20 Deal with this scenario may be an implementation or client policy. =20 Xiao -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Manish Joshi Sent: Thursday, January 19, 2006 3:42 AM To: James M. Polk; Miloslavsky Evgeny; sip@ietf.org Subject: Re: [Sip] Re-Invite before ACK =20 Iniline.. "James M. Polk" wrote:=20 At 10:45 AM 1/18/2006 -0800, Manish Joshi wrote: >Hi, > >The spec seems doesnt seem to be very clear on this. >An ACK to first Invite is a new transaction as the Invite transaction=20 >completed as soon as UAS sends final response as 200OK. UAC is now free to=20 >send a new re-invite along with the ACK to the first Invite. >>I don't believe so. I believe the stated behavior of the UAC is that it=20 >>cannot send a new INVITE within a dialog until the ACK is sent. The UAC >>is free to send any new INVITE outside of an existing dialog though. >>Section 14.1 covers this I believe. Actually I think 14.1 supports more what I mentioned above: =20 Quote: " Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. 1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE." UNQUOTE =20 ACK is a new transaction and receiving a final response (200OK) actually completes the INVITE transaction and hence UAC is free to Initiate a new (re)Invite transaction. =20 >Now since the packet ordering is not _ensured_, a reinvite can always come=20 >to UAS before ACK and hence UAS should be able to accept it. >>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in this=20 >>situation (prior to receiving the ACK to the original INVITE/200 OK exchange) > >BTW, this might also be an implementation option, where you chose to=20 >Ignore the re-invite in case the first INVITE did not have an offer and >200 OK was the one with the offer and ACK will contain the media-answer. > >My two cents. >-Manish > >Miloslavsky Evgeny wrote: >Yahoo! Photos - Showcase holiday pictures in hardcover >Photo=20 >Books. You design it and we'll bind it! >_______________________________________________ >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 ________________________________ Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. ------_=_NextPart_001_01C61E0B.4D177E65 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 
If you look at the following sections from =
the RFC:
 
13.2.2.4
“ =
The UAC core considers the INVITE transaction completed 64*T1 =
seconds
   after the reception of the first =
2xx response. “

 

13.3.1.4

“ The 2xx response is passed to the =
transport with an
   interval that starts at T1 =
seconds and doubles for each
   retransmission until it reaches =
T2 seconds (T1 and T2 are defined in
   Section 17).  Response =
retransmissions cease when an ACK request =
for
   the response is received.  =
This is independent of whatever transport
   protocols are used to send the =
response.
 
      Since 2xx is =
retransmitted end-to-end, there may be hops =
between
      UAS and UAC =
that are UDP.  To ensure reliable delivery =
across
      these hops, =
the response is retransmitted periodically even if =
the
      transport at =
the UAS is reliable.
 
   If the server retransmits the =
2xx response for 64*T1 seconds without
   receiving an ACK, the dialog is =
confirmed, but the session SHOULD be
   terminated.  This is =
accomplished with a BYE, as described in =
Section
   15.

“

 

One the UAC side, the INVITE = transaction is considered completed only after 64*T1 of the first 2xx. On the UAS side, = the server is expecting ACK within 64*T1 after the 2xx is sent, otherwise = the session will be terminated. This, in essence, means that INVITE = transaction will not complete until the ACK is sent and received. As a result I = don’t think the “reinvite before ack” makes practical = sense.

 

Thanks,

Haipeng

 

 

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Xiao Wang
Sent: Thursday, January = 19, 2006 5:57 PM
To: 'Manish Joshi'; = 'James M. Polk'; 'Miloslavsky Evgeny'; sip@ietf.org
Subject: RE: [Sip] = Re-Invite before ACK

 

I =  consider that ACK to INVITE’s 200 OK is a individual transaction, but it must send = rapidly after receive

200 OK, = otherwise it is no significance to acknowledge the INVITE transaction. Even ACK send = before the

re-INVITE, for = the reason of network delay, UAS may receive ACK after re-INVITE.

 

 Deal = with this scenario may be an implementation or client policy.

 

Xiao

-----Original = Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Manish Joshi
Sent: Thursday, January = 19, 2006 3:42 AM
To: James M. Polk; = Miloslavsky Evgeny; sip@ietf.org
Subject: Re: [Sip] = Re-Invite before ACK

 

Iniline..

"James M. Polk" <jmpolk@cisco.com> wrote: =

At 10:45 AM 1/18/2006 -0800, Manish Joshi = wrote:
>Hi,
>
>The spec seems doesnt seem to be very clear on this.
>An ACK to first Invite is a new transaction as the Invite = transaction
>completed as soon as UAS sends final response as 200OK. UAC is now = free to
>send a new re-invite along with the ACK to the first Invite.

>>I don't believe so. I believe the stated behavior of the UAC is = that it
>>cannot send a new INVITE within a dialog until the ACK is sent. = The UAC >>is free to send any new INVITE outside of an existing dialog = though. >>Section 14.1 covers this I believe.

Actually I think 14.1 supports more what I mentioned above:

 

Quote:

"   Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in = either
   direction.

      1. If there is an ongoing INVITE client transaction, the TU MUST
         wait until the = transaction reaches the completed or terminated
         state before initiating = the new INVITE."

UNQUOTE

 

ACK is a new transaction and receiving a final response (200OK) actually = completes the INVITE transaction and hence UAC is free to Initiate a new (re)Invite transaction.

 


>Now since the packet ordering is not _ensured_, a reinvite can = always come
>to UAS before ACK and hence UAS should be able to accept it.

>>Section 14.2 faintly implies a 491 is appropriate for the = reINVITE in this
>>situation (prior to receiving the ACK to the original INVITE/200 = OK exchange)

>
>BTW, this might also be an implementation option, where you chose to =
>Ignore the re-invite in case the first INVITE did not have an offer = and
>200 OK was the one with the offer and ACK will contain the = media-answer.
>
>My two cents.
>-Manish
>
>Miloslavsky Evgeny wrote:
>Yahoo! Photos – Showcase holiday pictures in hardcover
>Photo
>Books. You design it and we’ll bind it!
>_______________________________________________
>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
>

 

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands = ASAP.

------_=_NextPart_001_01C61E0B.4D177E65-- --===============1968442198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1968442198==-- From sip-bounces@ietf.org Fri Jan 20 18:46:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F05xV-0001Od-C6; Fri, 20 Jan 2006 18:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F05xT-0001OS-H4 for sip@megatron.ietf.org; Fri, 20 Jan 2006 18:46:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12795 for ; Fri, 20 Jan 2006 18:44:48 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F066E-0003wo-V0 for sip@ietf.org; Fri, 20 Jan 2006 18:55:24 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Jan 2006 15:46:04 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 15:46:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jan 2006 15:46:02 -0800 Message-ID: Thread-Topic: REFER extensions Thread-Index: AcYeG6w/SryugvqLQtCvLHWINrJelg== From: "Orit Levin" To: X-OriginalArrivalTime: 20 Jan 2006 23:46:04.0569 (UTC) FILETIME=[AD379890:01C61E1B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [Sip] REFER extensions 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="===============0273248256==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0273248256== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61E1B.AD0F80A7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61E1B.AD0F80A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, I have updated the two drafts below according to the WG latest agreements: =20 http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub -04.txt - as suggested on the list, corrected the text explaining the usage of the Required header with the new tag =20 http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param-0 1.txt - included the agreed text from the last IETF meeting recommending when the extension SHOULD be used =20 I believe that both drafts are ready for the last call. Please, review them ASAP. =20 Thanks a lot, Orit. ------_=_NextPart_001_01C61E1B.AD0F80A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Guys,

I have updated the two drafts below according to the = WG latest agreements:

 

http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-= with-norefersub-04.txt

- as suggested on = the list, corrected the text explaining the usage of the Required header with the new = tag

 

http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-fe= ature-param-01.txt

- included the = agreed text from the last IETF meeting recommending when the extension SHOULD be = used

 

I believe that both drafts are ready for the last = call. Please, review them ASAP.

 

Thanks a lot,

Orit.

------_=_NextPart_001_01C61E1B.AD0F80A7-- --===============0273248256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0273248256==-- From sip-bounces@ietf.org Fri Jan 20 21:59:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F08yf-0006Vq-RQ; Fri, 20 Jan 2006 21:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F08yd-0006RD-1K for sip@megatron.ietf.org; Fri, 20 Jan 2006 21:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24244 for ; Fri, 20 Jan 2006 21:58:15 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F097T-0000WF-68 for sip@ietf.org; Fri, 20 Jan 2006 22:08:52 -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 <0ITF009S1A6AUI@szxga02-in.huawei.com> for sip@ietf.org; Sat, 21 Jan 2006 11:10:58 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITF00IYQA6A4F@szxga02-in.huawei.com> for sip@ietf.org; Sat, 21 Jan 2006 11:10:58 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITF00CQIA64IB@szxml02-in.huawei.com>; Sat, 21 Jan 2006 11:10:52 +0800 (CST) Date: Sat, 21 Jan 2006 10:59:22 +0800 From: Xiao Wang Subject: RE: [Sip] Re: Re-Invite before ACK In-reply-to: <20060120171845.33539.qmail@web34215.mail.mud.yahoo.com> To: "'srinidhi n'" , "'Jin, Haipeng'" , "'Manish Joshi'" , "'James M. Polk'" , "'Miloslavsky Evgeny'" , sip@ietf.org Message-id: <011901c61e36$adfa09f0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7BIT Cc: 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 inline Xiao > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > srinidhi n > Sent: Saturday, January 21, 2006 1:19 AM > To: sip@ietf.org; srinidhi104@yahoo.com > Cc: brett@broadsoft.com > Subject: [Sip] Re: Re-Invite before ACK > > Do Correct me if I am wrong. > > 1. I think unless an ACK is receved by the UAS, its > transaction will not be complete and the UAS will > continue to re-transmit the original 200 OK. good > 2. As per sec.13 of RFC 3261, > If the server retransmits the 2xx response for 64*T1 > seconds without receiving an ACK, the dialog is > confirmed, but the session SHOULD be terminated. This > is accomplished with a BYE, as described in Section15. Note " but the session SHOULD be terminated ",there use " SHOULD" not "MUST". That is the protocol allow other cases to the session isn't terminated. I think if ACK is used to acknowledge that UAC received 200 OK and not taking SDP, the session may not be terminated if the timer fired and UAS received re-INVITE. Why may UAC send re-INVITE after send ACK? Because the protocol doesn't forbid. If the protocol explicit set a rule that UAC MUST wait 64*T1 after received the first 200 OK before send re-INVITE, this will not be flexible. In many cases, UAC need rapidly to send re-INVITE to UAS for exchange new SDP after old INVITE transaction complete. Another cases, the value of T1 set in UAC may not equal to UAS's, therefore, UAC don't know wait how long. Alternatively, if UAS receive re-INVITE before ACK that means to UAC already received 200 OK of old INVITE, and UAS must deal with the re-INVITE and not simple to return 491 or else failure response. > In this case, it is really difficult from the UAS > perspective to predict if it will receive a "ACK" > after the "Re-Invite" although its more likely to > receive it. > > Hence, the UAS may chose to send 491 response. > > -Srinidhi > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 20 22:50:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09lZ-0008VZ-HM; Fri, 20 Jan 2006 22:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09lX-0008UE-OR for sip@megatron.ietf.org; Fri, 20 Jan 2006 22:50:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26972 for ; Fri, 20 Jan 2006 22:48:47 -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.43) id 1F09uO-0001ia-8H for sip@ietf.org; Fri, 20 Jan 2006 22:59:25 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2006 14:40:00 -0800 X-IronPort-AV: i="unknown"; a="394518418:sNHT0" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KMe3WH011591; Fri, 20 Jan 2006 14:40:03 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 14:40:03 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.89.236]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 14:40:02 -0800 Message-Id: <4.3.2.7.2.20060120163548.0292f4e0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jan 2006 16:40:00 -0600 To: "Jin, Haipeng" , "Xiao Wang" , "Manish Joshi" , "Miloslavsky Evgeny" , From: "James M. Polk" Subject: RE: [Sip] Re-Invite before ACK In-Reply-To: <4A599554B0051B4897DFDD6DF1EAED7901C65EF0@NAEX07.na.qualcom m.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jan 2006 22:40:02.0364 (UTC) FILETIME=[738F17C0:01C61E12] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: 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 It seems to me that a well behaving UAC will send an UPDATE before sending a reINVITE if it has not sent the ACK yet. Can the UAS assume (or is this stated somewhere explicitly?) the UAC has sent the ACK if it receives a reINVITE? This seems to mean the reINVITE should not be processed until the ACK arrives, or the timer triggers, which causes the UAS to BYE the original INVITE, and reject the reINVITE. At 01:48 PM 1/20/2006 -0800, Jin, Haipeng wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C61E0B.4D177E65" > > >If you look at the following sections from the RFC: > >13.2.2.4 > The UAC core considers the INVITE transaction completed 64*T1 seconds > after the reception of the first 2xx response. > > >13.3.1.4 > > The 2xx response is passed to the transport with an > interval that starts at T1 seconds and doubles for each > retransmission until it reaches T2 seconds (T1 and T2 are defined in > Section 17). Response retransmissions cease when an ACK request for > the response is received. This is independent of whatever transport > protocols are used to send the response. > > Since 2xx is retransmitted end-to-end, there may be hops between > UAS and UAC that are UDP. To ensure reliable delivery across > these hops, the response is retransmitted periodically even if the > transport at the UAS is reliable. > > If the server retransmits the 2xx response for 64*T1 seconds without > receiving an ACK, the dialog is confirmed, but the session SHOULD be > terminated. This is accomplished with a BYE, as described in Section > 15. > > >One the UAC side, the INVITE transaction is considered completed only >after 64*T1 of the first 2xx. On the UAS side, the server is expecting ACK >within 64*T1 after the 2xx is sent, otherwise the session will be >terminated. This, in essence, means that INVITE transaction will not >complete until the ACK is sent and received. As a result I don t think the >reinvite before ack makes practical sense. > > > >Thanks, > >Haipeng > > > > > > > >---------- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Xiao >Wang >Sent: Thursday, January 19, 2006 5:57 PM >To: 'Manish Joshi'; 'James M. Polk'; 'Miloslavsky Evgeny'; sip@ietf.org >Subject: RE: [Sip] Re-Invite before ACK > > > >I consider that ACK to INVITE s 200 OK is a individual transaction, but >it must send rapidly after receive > >200 OK, otherwise it is no significance to acknowledge the INVITE >transaction. Even ACK send before the > >re-INVITE, for the reason of network delay, UAS may receive ACK after >re-INVITE. > > > > Deal with this scenario may be an implementation or client policy. > > > >Xiao > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >Manish Joshi >Sent: Thursday, January 19, 2006 3:42 AM >To: James M. Polk; Miloslavsky Evgeny; sip@ietf.org >Subject: Re: [Sip] Re-Invite before ACK > > > >Iniline.. > >"James M. Polk" wrote: > >At 10:45 AM 1/18/2006 -0800, Manish Joshi wrote: > >Hi, > > > >The spec seems doesnt seem to be very clear on this. > >An ACK to first Invite is a new transaction as the Invite transaction > >completed as soon as UAS sends final response as 200OK. UAC is now free to > >send a new re-invite along with the ACK to the first Invite. > > >>I don't believe so. I believe the stated behavior of the UAC is that it > >>cannot send a new INVITE within a dialog until the ACK is sent. The > UAC >>is free to send any new INVITE outside of an existing dialog > though. >>Section 14.1 covers this I believe. > >Actually I think 14.1 supports more what I mentioned above: > > > >Quote: > >" Note that a UAC MUST NOT initiate a new INVITE transaction within a > dialog while another INVITE transaction is in progress in either > direction. > > 1. If there is an ongoing INVITE client transaction, the TU MUST > wait until the transaction reaches the completed or terminated > state before initiating the new INVITE." > >UNQUOTE > > > >ACK is a new transaction and receiving a final response (200OK) actually >completes the INVITE transaction and hence UAC is free to Initiate a new >(re)Invite transaction. > > > > > >Now since the packet ordering is not _ensured_, a reinvite can always come > >to UAS before ACK and hence UAS should be able to accept it. > > >>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in this > >>situation (prior to receiving the ACK to the original INVITE/200 OK > exchange) > > > > >BTW, this might also be an implementation option, where you chose to > >Ignore the re-invite in case the first INVITE did not have an offer and > >200 OK was the one with the offer and ACK will contain the media-answer. > > > >My two cents. > >-Manish > > > >Miloslavsky Evgeny wrote: > >Yahoo! Photos Showcase holiday pictures in hardcover > >Photo > >Books. You design it and we ll bind it! > >_______________________________________________ > >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 > > > > > >Yahoo! Photos >Got holiday prints? >See >all the ways to get quality prints in your hands ASAP. >_______________________________________________ >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 20 23:45:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Acd-0003mL-Ms; Fri, 20 Jan 2006 23:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0AcZ-0003ko-Kw for sip@megatron.ietf.org; Fri, 20 Jan 2006 23:45:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00086 for ; Fri, 20 Jan 2006 23:43:34 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0AlP-00037b-1a for sip@ietf.org; Fri, 20 Jan 2006 23:54:13 -0500 Received: from [192.168.0.34] (rrcs-67-79-28-63.sw.biz.rr.com [67.79.28.63]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k0L4p7Qt027844 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 20 Jan 2006 22:51:07 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0BED8832-7875-4176-9E1E-BF4D25467304@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] REFER extensions Date: Fri, 20 Jan 2006 22:44:50 -0600 To: Sip X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Orit Levin 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 And when Orit sways "last call", I think that means IETF last call. The changes that she made were in response to feedback from the WGLC. So this is close to being your last chance . . . going . . . going . . . . -- Dean On Jan 20, 2006, at 5:46 PM, Orit Levin wrote: > Guys, > > I have updated the two drafts below according to the WG latest > agreements: > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- > norefersub-04.txt > > - as suggested on the list, corrected the text explaining the usage > of the Required header with the new tag > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature- > param-01.txt > > - included the agreed text from the last IETF meeting recommending > when the extension SHOULD be used > > > I believe that both drafts are ready for the last call. Please, > review them ASAP. > > > Thanks a lot, > > Orit. > > _______________________________________________ > 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 21 12:08:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ME7-00037h-7C; Sat, 21 Jan 2006 12:08:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ME5-00037a-N2 for sip@megatron.ietf.org; Sat, 21 Jan 2006 12:08:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13414 for ; Sat, 21 Jan 2006 12:07:05 -0500 (EST) Received: from web8606.mail.in.yahoo.com ([202.43.219.81]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0MN2-0006T6-N1 for sip@ietf.org; Sat, 21 Jan 2006 12:17:50 -0500 Received: (qmail 27366 invoked by uid 60001); 21 Jan 2006 17:08:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tFlm7QJQX9nqpehrZuk2ZTwDkRobgu1R8xjRTp+RALggx567wevuZqZvKxfNcUbXA5Wgo0aw5XUZX8QWkYDaMomoLFmNFulNJ69xo7iHKmXMmlYJv/U+LCKGmVOLpJJGzP2OA5k7T7FpheTZ2stDJzDEnIdbU48bOKdNmQ6lqFw= ; Message-ID: <20060121170818.27364.qmail@web8606.mail.in.yahoo.com> Received: from [210.214.40.171] by web8606.mail.in.yahoo.com via HTTP; Sat, 21 Jan 2006 17:08:18 GMT Date: Sat, 21 Jan 2006 17:08:18 +0000 (GMT) From: theja reddy To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] PAT Draft 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="===============1154449589==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1154449589== Content-Type: multipart/alternative; boundary="0-1856158582-1137863298=:25092" Content-Transfer-Encoding: 8bit --0-1856158582-1137863298=:25092 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hai , I have one basic question . Is there any draft to support PAT(Port Address Transalator) & firewall support in SIP regards theja Send instant messages to your online friends http://in.messenger.yahoo.com --0-1856158582-1137863298=:25092 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
 Hai ,

  I have one basic question . Is there any draft to support PAT(Port Address Transalator) & firewall support  in SIP

regards
theja

Send instant messages to your online friends http://in.messenger.yahoo.com --0-1856158582-1137863298=:25092-- --===============1154449589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1154449589==-- From sip-bounces@ietf.org Sun Jan 22 07:47:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0edN-0006pT-U7; Sun, 22 Jan 2006 07:47:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0edM-0006pI-6J for sip@megatron.ietf.org; Sun, 22 Jan 2006 07:47:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15818 for ; Sun, 22 Jan 2006 07:46:22 -0500 (EST) Received: from zimbra.mailvision.net ([212.143.248.123] helo=mvimap.mailvision.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0emT-0006PK-F7 for sip@ietf.org; Sun, 22 Jan 2006 07:57:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 209EF870639 for ; Sun, 22 Jan 2006 14:47:21 +0200 (IST) Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31184-03 for ; Sun, 22 Jan 2006 14:47:20 +0200 (IST) Received: from [192.168.10.100] (diegob.bb.netvision.net.il [212.143.127.193]) by mvimap.mailvision.net (Postfix) with ESMTP id B7E6E870630 for ; Sun, 22 Jan 2006 14:47:19 +0200 (IST) Message-ID: <43D37F0A.3010203@mailvision.com> Date: Sun, 22 Jan 2006 14:48:10 +0200 From: Diego B User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.139 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=0.260, BAYES_00=-2.599] X-Spam-Score: -4.139 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Sip] Status of draft-ietf-sip-privacy 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="===============1857605545==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1857605545== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060806080101050206030504" This is a cryptographically signed message in MIME format. --------------ms060806080101050206030504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi; What is the status of draft-ietf-sip-privacy ? I Can not see any other draft / RFC talking about Remote-Party-ID but this extension is widely deployed. And also is refered in 3GPP / IMS Docuemnts or drafts. Thanks -- ------------------------------------------------------------------------ Regards, Diego B (:-:) MailVision Ltd. *tel*:+97248508000;ext=102 *mailto*:diegob@mailvision.com *sip*:diegob@mailvision.net *http*://www.mailvision.com MailVision End to End SIP Solutions See us at 3GSM Barcelona --------------ms060806080101050206030504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFpzCC AmAwggHJoAMCAQICEG3TF9j428smmpt/imLDz9gwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDEyMTE3MDAxMVoX DTA3MDEyMTE3MDAxMVowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG CSqGSIb3DQEJARYVZGllZ29iQG1haWx2aXNpb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC9aNhu3NL4upmyL/kwYGKbvkqqb/JtlaQy5O8uMm+YyQ36/ogh5U6V3gJOWmiF IuNgxxUe8fgwUdjY7G7j8MX4WsCYXKcEiilCtZBJFNc104w7oCHLgnd5qci4ki5OCHwgUOjl pq0Tpsxl+ugW+Erao/8hxFEpIr3EYuPx4U1xlQIDAQABozIwMDAgBgNVHREEGTAXgRVkaWVn b2JAbWFpbHZpc2lvbi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBIRqB5 0MkdHekEgdQnRFUQd7gld2NOIwPg37RZLzniUyVFREVjIt1l8g6mF0s0sviwPNiE18L2fChS vpDQaKBiyusfPbVY5l6Hxq2lil8AKzKaxoQKizcEoyf6VkjiDQwuvPOcR3EL7AVeCM0jQKOm Rm4aPZL/Hq3pcJGpTKgmtzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggHQMIIBzAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbdMX2Pjb yyaam3+KYsPP2DAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDEyMjEyNDgxMFowIwYJKoZIhvcNAQkEMRYEFGfHWrawmpqXE6t7 KtTEnN47MEoeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIGAbCz9S0zB0eDKJe2lZuNvWeCefT1vdB5ZrOiDEGcWqr2k71Sdm2+OX+9eCV1/5AXOy1HL pFxYFU+U033gMixhVmei0z/FkGTrLZ56rd3/7cdCHLBNEET60k6rC/GwQkEqDzgI7Ep5oi5r e5Thl0ZNu+lp1F/m4e7JUY7jkl2svMcAAAAAAAA= --------------ms060806080101050206030504-- --===============1857605545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1857605545==-- From sip-bounces@ietf.org Sun Jan 22 10:53:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0hXT-0002KG-OA; Sun, 22 Jan 2006 10:53:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0hXR-0002K4-Gp for sip@megatron.ietf.org; Sun, 22 Jan 2006 10:53:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27548 for ; Sun, 22 Jan 2006 10:52:28 -0500 (EST) Received: from natblindhugh.rzone.de ([81.169.145.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0hgM-0003Ql-I8 for sip@ietf.org; Sun, 22 Jan 2006 11:03:26 -0500 Received: from snom.de ([195.2.174.186]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k0MFrP4F003474; Sun, 22 Jan 2006 16:53:25 +0100 (MET) Content-class: urn:content-classes:message Subject: RE: [Sip] Status of draft-ietf-sip-privacy MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jan 2006 16:53:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: [Sip] Status of draft-ietf-sip-privacy thread-index: AcYfU+upWEpwSw3rS2mweldcDd4LzAAF6lGA From: "Christian Stredicke" To: "Diego B" X-Spam-Score: 2.9 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Diego, take a look at RFC3323-3325. Seems like most manufacturers follow these standards in new implementations and Remote-Party-ID is becoming obsolete. CS > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Diego B > Sent: Sunday, January 22, 2006 8:01 AM > To: sip@ietf.org > Subject: [Sip] Status of draft-ietf-sip-privacy >=20 > Hi; > What is the status of draft-ietf-sip-privacy ?=20 > > I Can not see any other draft / RFC talking about=20 > Remote-Party-ID but this extension is widely deployed. And=20 > also is refered in 3GPP / IMS Docuemnts or drafts. >=20 > Thanks > -- > -------------------------------------------------------------- > ---------- > Regards, >=20 > Diego B (:-:) > MailVision Ltd. >=20 > *tel*:+97248508000;ext=3D102 =20 > *mailto*:diegob@mailvision.com =20 > *sip*:diegob@mailvision.net =20 > *http*://www.mailvision.com > MailVision End to End SIP Solutions=20 > See us=20 > at 3GSM Barcelona > >=20 >=20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 22 12:08:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ihY-0005dM-9R; Sun, 22 Jan 2006 12:08:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ihM-0005aE-69 for sip@megatron.ietf.org; Sun, 22 Jan 2006 12:08:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02158 for ; Sun, 22 Jan 2006 12:06:47 -0500 (EST) Received: from web34205.mail.mud.yahoo.com ([66.163.178.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0iqW-0005Ub-AG for sip@ietf.org; Sun, 22 Jan 2006 12:17:45 -0500 Received: (qmail 22032 invoked by uid 60001); 22 Jan 2006 17:08:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v3f6vB+L3sLoL4Z3o1MdLfm6wqkYgL7kNSmqWo9+EqV+7xhm+l6J/2YMNi5Nupp/T9QPrH2QZZu+HVNC+FrGcgFWKddkc4i/G3HkOtlvbdLLG3hgyg7n22dyMDNAnEdOOtiFZ2BnpKTFjTSudFjOPAIEA3lITbDiwCC9pAT48cs= ; Message-ID: <20060122170803.22030.qmail@web34205.mail.mud.yahoo.com> Received: from [59.144.34.121] by web34205.mail.mud.yahoo.com via HTTP; Sun, 22 Jan 2006 09:08:03 PST Date: Sun, 22 Jan 2006 09:08:03 -0800 (PST) From: srinidhi n Subject: RE: [Sip] Re: Re-Invite before ACK To: Xiao Wang , "'Jin, Haipeng'" , "'Manish Joshi'" , "'James M. Polk'" , "'Miloslavsky Evgeny'" , sip@ietf.org In-Reply-To: <011901c61e36$adfa09f0$b2b04c0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 8bit Cc: 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 1. In case an SDP ofer was not made in the original Invite, there is no way we can honour this Reinvite before an ACK and the session must be terminated. On the other side, if a offer was made in the Invite, the reinvite either could be accepted/rejected(as being discussed). Thus, the UAS needs to exhibit a different behavior in cases where an offer was made in Invite and when it wasn't. This apart from cancelling the re-transmission of 200 OK on recepton of ACK and also reinvites. 2. 64*T1 is the worst case time period before which a ACK is to reach the UAS. For every T1 and doubling thereafter till T2, the UAS retransmits a 200 OK. Hence, the UAC can safely transmit the next message from ACK after 2*T1, provided a 200 Ok is not retransmitted, without worrying about any kind of UAS problems. 3.Another problem from UAC side would be how it would handle a retransmitted 200 OK(assuming the ACK is lost) after initating a Re-Invite. Considering UAS behavior differences it would be easier to not to handle the reinvite at the UAS. -Srinidhi --- Xiao Wang wrote: > inline > > Xiao > > > -----Original Message----- > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of > > srinidhi n > > Sent: Saturday, January 21, 2006 1:19 AM > > To: sip@ietf.org; srinidhi104@yahoo.com > > Cc: brett@broadsoft.com > > Subject: [Sip] Re: Re-Invite before ACK > > > > Do Correct me if I am wrong. > > > > 1. I think unless an ACK is receved by the UAS, > its > > transaction will not be complete and the UAS will > > continue to re-transmit the original 200 OK. > good > > 2. As per sec.13 of RFC 3261, > > If the server retransmits the 2xx response for > 64*T1 > > seconds without receiving an ACK, the dialog is > > confirmed, but the session SHOULD be terminated. > This > > is accomplished with a BYE, as described in > Section15. > Note " but the session SHOULD be terminated ",there > use " SHOULD" not > "MUST". > That is the protocol allow other cases to the > session isn't terminated. > I think if ACK is used to acknowledge that UAC > received 200 OK and not > taking SDP, the session may not be terminated if the > timer fired and UAS > received re-INVITE. > Why may UAC send re-INVITE after send ACK? > Because the protocol doesn't forbid. If the protocol > explicit set a rule > that UAC MUST wait 64*T1 after received the first > 200 OK before send > re-INVITE, this will not be flexible. > In many cases, UAC need rapidly to send re-INVITE to > UAS for exchange new > SDP after old INVITE transaction complete. > Another cases, the value of T1 set in UAC may not > equal to UAS's, therefore, > UAC don't know wait how long. > Alternatively, if UAS receive re-INVITE before ACK > that means to UAC already > received 200 OK of old INVITE, and UAS must deal > with the re-INVITE and not > simple to return 491 or else failure response. > > > In this case, it is really difficult from the UAS > > perspective to predict if it will receive a "ACK" > > after the "Re-Invite" although its more likely to > > receive it. > > > > Hence, the UAS may chose to send 491 response. > > > > -Srinidhi > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 22 15:38:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0lzG-00081k-5W; Sun, 22 Jan 2006 15:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0lzE-00081d-1w for sip@megatron.ietf.org; Sun, 22 Jan 2006 15:38:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15308 for ; Sun, 22 Jan 2006 15:37:27 -0500 (EST) From: Shimshon.Lapushner@ecitele.com Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0m8N-0002sA-Va for sip@ietf.org; Sun, 22 Jan 2006 15:48:27 -0500 To: sip@ietf.org Message-ID: Date: Sun, 22 Jan 2006 22:38:28 +0200 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 01/22/2006 22:45:56 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Sip] Shimshon Lapushner/ECI Telecom 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: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I will be out of the office starting 22/01/2006 and will not return until 24/01/2006. I could be reached by Mobile: +972 54 578-8113 _______________________________________________ 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 22 15:46:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0m6v-0002NP-Qd; Sun, 22 Jan 2006 15:46:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0m6t-0002NG-Gt for sip@megatron.ietf.org; Sun, 22 Jan 2006 15:46:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15776 for ; Sun, 22 Jan 2006 15:45:23 -0500 (EST) Received: from zimbra.mailvision.net ([212.143.248.123] helo=mvimap.mailvision.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0mG4-00034v-Cu for sip@ietf.org; Sun, 22 Jan 2006 15:56:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 2882F87068E; Sun, 22 Jan 2006 22:46:27 +0200 (IST) Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15227-10; Sun, 22 Jan 2006 22:46:26 +0200 (IST) Received: from [192.168.10.100] (diegob.bb.netvision.net.il [212.143.127.193]) by mvimap.mailvision.net (Postfix) with ESMTP id 7077C870630; Sun, 22 Jan 2006 22:46:25 +0200 (IST) Message-ID: <43D3EF59.2010208@mailvision.com> Date: Sun, 22 Jan 2006 22:47:21 +0200 From: Diego B User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke Subject: Re: [Sip] Status of draft-ietf-sip-privacy References: In-Reply-To: X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.17 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=0.229, BAYES_00=-2.599] X-Spam-Score: -4.17 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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: , Content-Type: multipart/mixed; boundary="===============1113724639==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1113724639== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020808070303090109000206" This is a cryptographically signed message in MIME format. --------------ms020808070303090109000206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi; Yes I'm aware of those RFC, but I know some Gateway vendors that use the Remote-Party-ID , also for Caller ID, screening and billing. Thanks Christian Stredicke wrote: >Diego, take a look at RFC3323-3325. Seems like most manufacturers follow >these standards in new implementations and Remote-Party-ID is becoming >obsolete. > >CS > > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Diego B >>Sent: Sunday, January 22, 2006 8:01 AM >>To: sip@ietf.org >>Subject: [Sip] Status of draft-ietf-sip-privacy >> >>Hi; >>What is the status of draft-ietf-sip-privacy ? >> >>I Can not see any other draft / RFC talking about >>Remote-Party-ID but this extension is widely deployed. And >>also is refered in 3GPP / IMS Docuemnts or drafts. >> >>Thanks >>-- >>-------------------------------------------------------------- >>---------- >>Regards, >> >>Diego B (:-:) >>MailVision Ltd. >> >>*tel*:+97248508000;ext=102 >>*mailto*:diegob@mailvision.com >>*sip*:diegob@mailvision.net >>*http*://www.mailvision.com >>MailVision End to End SIP Solutions >> See us >>at 3GSM Barcelona >> >> >> >> >> >> >> >> -- ------------------------------------------------------------------------ Regards, Diego B (:-:) MailVision Ltd. *tel*:+97248508000;ext=102 *mailto*:diegob@mailvision.com *sip*:diegob@mailvision.net *http*://www.mailvision.com MailVision End to End SIP Solutions See us at 3GSM Barcelona --------------ms020808070303090109000206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFpzCC AmAwggHJoAMCAQICEG3TF9j428smmpt/imLDz9gwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDEyMTE3MDAxMVoX DTA3MDEyMTE3MDAxMVowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG CSqGSIb3DQEJARYVZGllZ29iQG1haWx2aXNpb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC9aNhu3NL4upmyL/kwYGKbvkqqb/JtlaQy5O8uMm+YyQ36/ogh5U6V3gJOWmiF IuNgxxUe8fgwUdjY7G7j8MX4WsCYXKcEiilCtZBJFNc104w7oCHLgnd5qci4ki5OCHwgUOjl pq0Tpsxl+ugW+Erao/8hxFEpIr3EYuPx4U1xlQIDAQABozIwMDAgBgNVHREEGTAXgRVkaWVn b2JAbWFpbHZpc2lvbi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBIRqB5 0MkdHekEgdQnRFUQd7gld2NOIwPg37RZLzniUyVFREVjIt1l8g6mF0s0sviwPNiE18L2fChS vpDQaKBiyusfPbVY5l6Hxq2lil8AKzKaxoQKizcEoyf6VkjiDQwuvPOcR3EL7AVeCM0jQKOm Rm4aPZL/Hq3pcJGpTKgmtzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggHQMIIBzAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbdMX2Pjb yyaam3+KYsPP2DAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDEyMjIwNDcyMVowIwYJKoZIhvcNAQkEMRYEFGcpOOUHdEcAe+RX fsjRRtd02sVrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIGAUYJI3TpgxUFpC8QOdPYsTxom3YN/Y9eBKbBg0/pTdyT2ssyYYDaqXb1cMwl2z7EwXDsd 6XtOWB/2RngbfcOTWoHYaZvIw+st6m0BtkMbYrBsE6rEDvYniKGtFLNrI1NnON7jlquhKspt p1Ajip4iuI1JfR+DWiS8ghaBpZJGElkAAAAAAAA= --------------ms020808070303090109000206-- --===============1113724639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1113724639==-- From sip-bounces@ietf.org Mon Jan 23 01:33:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0vGy-0004a0-RU; Mon, 23 Jan 2006 01:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0vGw-0004Zs-NL for sip@megatron.ietf.org; Mon, 23 Jan 2006 01:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21213 for ; Mon, 23 Jan 2006 01:32:20 -0500 (EST) Received: from uproxy.gmail.com ([66.249.92.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0vQE-0002FM-1H for sip@ietf.org; Mon, 23 Jan 2006 01:43:27 -0500 Received: by uproxy.gmail.com with SMTP id o2so741597uge for ; Sun, 22 Jan 2006 22:33:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=dOMSFad5Tt7QSeoBjC1Mat/9dFJQQZBB3MAOMUpGhNEeueotR5wyaenEWi80yycMmtBK++2/ksbxzNsOlixL7kmmJZB5rllCsxLgcxSFfVG0/IQHxLmZkEDQAJEYxvHHpoWBOG2vN3uyzWb6rI7uZGxCdaLIUZMGiqO0PhTIG+U= Received: by 10.49.40.4 with SMTP id s4mr222760nfj; Sun, 22 Jan 2006 22:33:43 -0800 (PST) Received: by 10.48.215.16 with HTTP; Sun, 22 Jan 2006 22:33:43 -0800 (PST) Message-ID: <52db68bc0601222233n51a61f25s6de07917f173a9de@mail.gmail.com> Date: Mon, 23 Jan 2006 12:03:43 +0530 From: Sudhir Kumar Reddy To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] multipart SIP Mesaages 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="===============0828873806==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0828873806== Content-Type: multipart/alternative; boundary="----=_Part_19240_13726004.1137998023543" ------=_Part_19240_13726004.1137998023543 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I would like to know that is there any draft or RFC for handling SIP mutlipart messages with examples, other than RFC 2046. Thanks in advance. regards Sudhir ------=_Part_19240_13726004.1137998023543 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi All,
 
I would like to know that is there any draft or RFC for handling SIP m= utlipart messages with examples, other than RFC 2046.
 
Thanks in advance.
 
 
regards
Sudhir
------=_Part_19240_13726004.1137998023543-- --===============0828873806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0828873806==-- From sip-bounces@ietf.org Mon Jan 23 06:47:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F10Ai-0002oc-7I; Mon, 23 Jan 2006 06:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F10Af-0002oX-Ul for sip@megatron.ietf.org; Mon, 23 Jan 2006 06:47:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10263 for ; Mon, 23 Jan 2006 06:46:12 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F10Jv-0002R6-7D for sip@ietf.org; Mon, 23 Jan 2006 06:57:21 -0500 Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0NBi1P00715 for ; Mon, 23 Jan 2006 17:14:01 +0530 From: "Nataraju A B" To: Date: Mon, 23 Jan 2006 17:17:04 +0530 Message-ID: <000c01c62012$baef1a50$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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Subject: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 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 Hi All, I am posting the same query here in sipping since I did not get any convincing answers in sip-Implementors list...... Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Nataraju A B Sent: Friday, January 20, 2006 11:57 AM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] doubt/bug with RFC-3455 Hi All, I have a doubt in the rfc 3455 with respect to P-Associated-URI syntax, Excerpt from RFC-3455 <<< 4.1.2 Usage of the P-Associated-URI header The registrar inserts the P-Associated-URI header field into the 200 OK response to a REGISTER request. The header field value is populated with a list containing zero or more URIs that are associated to the address-of-record. If the registrar supports the P-Associated-URI header extension, then the registrar MUST always insert the P-Associated-URI header field in all the 200 OK responses to a REGISTER request, regardless of whether the REGISTER was an initial registration, re-registration, or de-registration and regardless of whether there are zero or more associated URIs. >>> it says if the registrar supports P-Associated-URI, then it has to insert the P-Asserted-URI in 200 OK response for REGISTER while defining the ABNF for the same its been mentioned as P-Associated-URI = "P-Associated-URI" HCOLON (p-aso-uri-spec) *(COMMA p-aso-uri-spec) p-aso-uri-spec = name-addr *(SEMI ai-param) ai-param = generic-param This ABNF syntax says as one or more, not zero or more number of p-aso-uri-spec, Now my question is? 1) Why do we need to insert the P-Associated-URI header if there are no entry to fill in ? 2) How do we specify the zero or more P-Associated-URI header values ? Best Regards, Nataraju A.B. Kodiak Networks Ind Pvt Ltd "Change your thoughts, and you change your world." _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 23 08:56:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12BJ-0002re-Sb; Mon, 23 Jan 2006 08:56:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12BI-0002r4-9Y for sip@megatron.ietf.org; Mon, 23 Jan 2006 08:56:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19569 for ; Mon, 23 Jan 2006 08:54:57 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12Kb-0006V1-QR for sip@ietf.org; Mon, 23 Jan 2006 09:06:08 -0500 Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0NDnCP13111; Mon, 23 Jan 2006 19:19:13 +0530 From: "Nataraju A B" To: "'srinidhi n'" , "'Xiao Wang'" , "'Jin, Haipeng'" , "'Manish Joshi'" , "'James M. Polk'" , "'Miloslavsky Evgeny'" , Subject: RE: [Sip] Re: Re-Invite before ACK Date: Mon, 23 Jan 2006 19:22:15 +0530 Message-ID: <002201c62024$39ac6a30$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: <20060122170803.22030.qmail@web34205.mail.mud.yahoo.com> X-Spam-Score: 4.0 (++++) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: 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 RFC does not forbid sending re-INVITE soon after sent the ACK for the 200OK. I guess it would be reasonable to drop that particular retransmitted INVITE when UAS was in expectation of ACK for the initial INVITE. If so, the ACK Might reaches the UAS and the actual intention of the re-INVITE would be taken care by the subsequent retransmitted re-INVITE. Here we are assuming, if re-INVITE can reach UAS, for sure ACK might also reach UAS, Assume if all the re-INVITEs were dropped because ACK was not received for the earlier INVITE transaction, that lead to call termination (BYE & 200) that is very much inline RFC. Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of srinidhi n Sent: Sunday, January 22, 2006 10:38 PM To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M. Polk'; 'Miloslavsky Evgeny'; sip@ietf.org Subject: RE: [Sip] Re: Re-Invite before ACK 1. In case an SDP ofer was not made in the original Invite, there is no way we can honour this Reinvite before an ACK and the session must be terminated. On the other side, if a offer was made in the Invite, the reinvite either could be accepted/rejected(as being discussed). Thus, the UAS needs to exhibit a different behavior in cases where an offer was made in Invite and when it wasn't. This apart from cancelling the re-transmission of 200 OK on recepton of ACK and also reinvites. 2. 64*T1 is the worst case time period before which a ACK is to reach the UAS. For every T1 and doubling thereafter till T2, the UAS retransmits a 200 OK. Hence, the UAC can safely transmit the next message from ACK after 2*T1, provided a 200 Ok is not retransmitted, without worrying about any kind of UAS problems. 3.Another problem from UAC side would be how it would handle a retransmitted 200 OK(assuming the ACK is lost) after initating a Re-Invite. Considering UAS behavior differences it would be easier to not to handle the reinvite at the UAS. -Srinidhi --- Xiao Wang wrote: > inline > > Xiao > > > -----Original Message----- > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of > > srinidhi n > > Sent: Saturday, January 21, 2006 1:19 AM > > To: sip@ietf.org; srinidhi104@yahoo.com > > Cc: brett@broadsoft.com > > Subject: [Sip] Re: Re-Invite before ACK > > > > Do Correct me if I am wrong. > > > > 1. I think unless an ACK is receved by the UAS, > its > > transaction will not be complete and the UAS will > > continue to re-transmit the original 200 OK. > good > > 2. As per sec.13 of RFC 3261, > > If the server retransmits the 2xx response for > 64*T1 > > seconds without receiving an ACK, the dialog is > > confirmed, but the session SHOULD be terminated. > This > > is accomplished with a BYE, as described in > Section15. > Note " but the session SHOULD be terminated ",there > use " SHOULD" not > "MUST". > That is the protocol allow other cases to the > session isn't terminated. > I think if ACK is used to acknowledge that UAC > received 200 OK and not > taking SDP, the session may not be terminated if the > timer fired and UAS > received re-INVITE. > Why may UAC send re-INVITE after send ACK? > Because the protocol doesn't forbid. If the protocol > explicit set a rule > that UAC MUST wait 64*T1 after received the first > 200 OK before send > re-INVITE, this will not be flexible. > In many cases, UAC need rapidly to send re-INVITE to > UAS for exchange new > SDP after old INVITE transaction complete. > Another cases, the value of T1 set in UAC may not > equal to UAS's, therefore, > UAC don't know wait how long. > Alternatively, if UAS receive re-INVITE before ACK > that means to UAC already > received 200 OK of old INVITE, and UAS must deal > with the re-INVITE and not > simple to return 491 or else failure response. > > > In this case, it is really difficult from the UAS > > perspective to predict if it will receive a "ACK" > > after the "Re-Invite" although its more likely to > > receive it. > > > > Hence, the UAS may chose to send 491 response. > > > > -Srinidhi > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 23 10:08:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13JS-0006N9-6n; Mon, 23 Jan 2006 10:08:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13JP-0006MA-Vw for sip@megatron.ietf.org; Mon, 23 Jan 2006 10:08:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25889 for ; Mon, 23 Jan 2006 10:07:27 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13Sl-0001FB-IH for sip@ietf.org; Mon, 23 Jan 2006 10:18:37 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 23 Jan 2006 07:08:46 -0800 X-IronPort-AV: i="4.01,212,1136188800"; d="scan'208"; a="1769146321:sNHT36160500" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0NF8gQL028173; Mon, 23 Jan 2006 07:08:44 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 10:08:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Re-Invite before ACK Date: Mon, 23 Jan 2006 10:08:41 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301030CE7@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: Re-Invite before ACK Thread-Index: AcYgJYKbo1YjckZCRZS7NoSGVGiLWwABrlBA From: "Michael Hammer \(mhammer\)" To: "Nataraju A B" , "srinidhi n" , "Xiao Wang" , "Jin, Haipeng" , "Manish Joshi" , "James Polk \(jmpolk\)" , "Miloslavsky Evgeny" , X-OriginalArrivalTime: 23 Jan 2006 15:08:42.0862 (UTC) FILETIME=[E62840E0:01C6202E] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable Cc: 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 So, let us see if I understood the two cases correctly based on this thread: 1. Offer-Answer complete (no SDP needed in ACK) case: UAC: Upon receipt of 200 OK and transmission of ACK, can send re-INVITE with new Offer. UAS: After sending 200 OK (with Answer), can treat receipt of re-INVITE as an implied ACK to the 200 OK, because otherwise the UAC would have never sent the INVITE. =20 Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer before sending re-INVITE to confirm Answer received. 2. Offer-Answer not complete (SDP needed in ACK) case: UAC: Send Answer in ACK, then wait to see if 200 OK is retransmitted, meaning the ACK was not received. Thus, wait 2*T1 (expected bound for Timer G?) after receipt of previous 200 OK. If no 200 OK, then can assume that ACK was received, and proceed to send the re-INVITE. UAS: Reject any re-INVITE before ACK received with 491 Request Pending, since Answer to Offer in 200 OK was not received. Accept re-INVITE with new offer only after ACK received. Where UAS wants to re-INVITE, wait for ACK with Answer to complete Offer in 200 OK before sending re-INVITE. My only question is that Timer G starts with T1 not 2*T1, so is this for margin of safety? Also, doesn't this assume that both UAC and UAS use same T1 value? Mike > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Nataraju A B > Sent: Monday, January 23, 2006 8:52 AM > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish=20 > Joshi'; James Polk (jmpolk); 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 > RFC does not forbid sending re-INVITE soon after sent the ACK=20 > for the 200OK.=20 >=20 > I guess it would be reasonable to drop that particular=20 > retransmitted INVITE when UAS was in expectation of ACK for=20 > the initial INVITE. If so, the ACK Might reaches the UAS and=20 > the actual intention of the re-INVITE would be taken care by=20 > the subsequent retransmitted re-INVITE.=20 >=20 > Here we are assuming, if re-INVITE can reach UAS, for sure=20 > ACK might also reach UAS,=20 >=20 > Assume if all the re-INVITEs were dropped because ACK was not=20 > received for the earlier INVITE transaction, that lead to=20 > call termination (BYE & > 200) that is very much inline RFC. >=20 > Thanks & Regards, > Nataraju A.B. >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of srinidhi n > Sent: Sunday, January 22, 2006 10:38 PM > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M.=20 > Polk'; 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 > 1. In case an SDP ofer was not made in the original Invite,=20 > there is no way we can honour this Reinvite before an ACK and=20 > the session must be terminated. On the other side, if a offer=20 > was made in the Invite, the reinvite either could be=20 > accepted/rejected(as being discussed). >=20 > Thus, the UAS needs to exhibit a different behavior in cases=20 > where an offer was made in Invite and when it wasn't. This=20 > apart from cancelling the re-transmission of 200 OK on=20 > recepton of ACK and also reinvites. >=20 > 2. 64*T1 is the worst case time period before which a ACK is=20 > to reach the UAS. For every T1 and doubling thereafter till=20 > T2, the UAS retransmits a 200 OK. > Hence, the UAC can safely transmit the next message from ACK=20 > after 2*T1, provided a 200 Ok is not retransmitted, without=20 > worrying about any kind of UAS problems. >=20 > 3.Another problem from UAC side would be how it would handle=20 > a retransmitted 200 OK(assuming the ACK is > lost) after initating a Re-Invite. >=20 > Considering UAS behavior differences it would be easier to=20 > not to handle the reinvite at the UAS. >=20 > -Srinidhi > --- Xiao Wang wrote: >=20 > > inline > >=20 > > Xiao > >=20 > > > -----Original Message----- > > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > srinidhi n > > > Sent: Saturday, January 21, 2006 1:19 AM > > > To: sip@ietf.org; srinidhi104@yahoo.com > > > Cc: brett@broadsoft.com > > > Subject: [Sip] Re: Re-Invite before ACK > > >=20 > > > Do Correct me if I am wrong. > > >=20 > > > 1. I think unless an ACK is receved by the UAS, > > its > > > transaction will not be complete and the UAS will continue to=20 > > > re-transmit the original 200 OK. > > good > > > 2. As per sec.13 of RFC 3261, > > > If the server retransmits the 2xx response for > > 64*T1 > > > seconds without receiving an ACK, the dialog is=20 > confirmed, but the=20 > > > session SHOULD be terminated. > > This > > > is accomplished with a BYE, as described in > > Section15. > > Note " but the session SHOULD be terminated ",there use "=20 > SHOULD" not=20 > > "MUST". > > That is the protocol allow other cases to the session isn't=20 > > terminated. > > I think if ACK is used to acknowledge that UAC received 200=20 > OK and not=20 > > taking SDP, the session may not be terminated if the timer=20 > fired and=20 > > UAS received re-INVITE. > > Why may UAC send re-INVITE after send ACK? > > Because the protocol doesn't forbid. If the protocol explicit set a=20 > > rule that UAC MUST wait 64*T1 after received the first 200=20 > OK before=20 > > send re-INVITE, this will not be flexible. > > In many cases, UAC need rapidly to send re-INVITE to UAS=20 > for exchange=20 > > new SDP after old INVITE transaction complete. > > Another cases, the value of T1 set in UAC may not equal to UAS's,=20 > > therefore, UAC don't know wait how long. > > Alternatively, if UAS receive re-INVITE before ACK that=20 > means to UAC=20 > > already received 200 OK of old INVITE, and UAS must deal with the=20 > > re-INVITE and not simple to return 491 or else failure response. > >=20 > > > In this case, it is really difficult from the UAS perspective to=20 > > > predict if it will receive a "ACK" > > > after the "Re-Invite" although its more likely to receive it. > > >=20 > > > Hence, the UAS may chose to send 491 response. > > >=20 > > > -Srinidhi > > >=20 > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam > > protection around > > > http://mail.yahoo.com > > >=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 > >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 Mon Jan 23 11:25:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14VT-00018Q-Qz; Mon, 23 Jan 2006 11:25:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14VR-00018B-Ll for sip@megatron.ietf.org; Mon, 23 Jan 2006 11:25:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00567 for ; Mon, 23 Jan 2006 11:23:56 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14ep-0003kB-3U for sip@ietf.org; Mon, 23 Jan 2006 11:35:07 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0NGPDIf003206; Mon, 23 Jan 2006 10:25:14 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 23 Jan 2006 16:25:13 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290769@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Nataraju A B'" , "'sip@ietf.org'" Subject: RE: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 Date: Mon, 23 Jan 2006 16:25:11 -0000 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: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 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 I cannot answer the question, but I can indicate that as far as I understand the issue, 3GPP never needs to send only zero URIs, as this is included in a successful registration only, and therefore at least one address must be registered. The associated list is the list of all registered URIs, both implicit and explicit: Extract from 3GPP TS 24.229 subclause 5.4.1.2.2: "...create a 200 (OK) response for the REGISTER request, including: ... b) a P-Associated-URI header containing the list of the registered public user identity and its associated set of implicitly registered public user identities. The first URI in the list of public user identities supplied by the HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user identity indicated as the default public user identity must be a registered public user identity. The S-CSCF shall place the default public user identity as the first entry in the list of URIs present in the P-Associated-URI header. The default public user identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity header, as described in subclause 5.2.6.3. The S-CSCF shall not add a barred public user identity to the list of URIs in the P-Associated-URI header;" I will add this to a number of issues I am in the process of addressing in RFC 3455. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Nataraju A B > Sent: 23 January 2006 11:47 > To: sip@ietf.org > Subject: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 > > > Hi All, > > I am posting the same query here in sipping since I did not get any > convincing answers in sip-Implementors list...... > > Thanks & Regards, > Nataraju A.B. > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf > Of Nataraju > A B > Sent: Friday, January 20, 2006 11:57 AM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] doubt/bug with RFC-3455 > > Hi All, > > I have a doubt in the rfc 3455 with respect to > P-Associated-URI syntax, > > Excerpt from RFC-3455 > <<< > 4.1.2 Usage of the P-Associated-URI header > > The registrar inserts the P-Associated-URI header field > into the 200 > OK response to a REGISTER request. The header field value is > populated with a list containing zero or more URIs that are > associated to the address-of-record. > If the registrar supports the P-Associated-URI header > extension, then > the registrar MUST always insert the P-Associated-URI > header field in > all the 200 OK responses to a REGISTER request, regardless > of whether > the REGISTER was an initial registration, re-registration, or > de-registration and regardless of whether there are zero or more > associated URIs. > >>> > > it says if the registrar supports P-Associated-URI, then it has to > insert the P-Asserted-URI in 200 OK response for REGISTER > while defining the ABNF for the same its been mentioned as > > P-Associated-URI = "P-Associated-URI" HCOLON > (p-aso-uri-spec) > *(COMMA p-aso-uri-spec) > p-aso-uri-spec = name-addr *(SEMI ai-param) > ai-param = generic-param > > This ABNF syntax says as one or more, not zero or more number of > p-aso-uri-spec, > > Now my question is? > 1) Why do we need to insert the P-Associated-URI header if > there are no > entry to fill in ? > 2) How do we specify the zero or more P-Associated-URI header > values ? > > Best Regards, > Nataraju A.B. > Kodiak Networks Ind Pvt Ltd > "Change your thoughts, and you change your world." > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ > 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 23 19:36:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1CAp-0001hT-Jd; Mon, 23 Jan 2006 19:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1CAn-0001eQ-Dy for sip@megatron.ietf.org; Mon, 23 Jan 2006 19:36:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17611 for ; Mon, 23 Jan 2006 19:35:07 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1CKF-0008Ts-3q for sip@ietf.org; Mon, 23 Jan 2006 19:46:23 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2006 19:36:28 -0500 X-IronPort-AV: i="4.01,213,1136178000"; d="scan'208"; a="80824620:sNHT34923036" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0O0aPPM016831; Mon, 23 Jan 2006 19:36:26 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 19:36:25 -0500 Received: from [10.86.242.66] ([10.86.242.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 19:36:25 -0500 Message-ID: <43D57688.2070908@cisco.com> Date: Mon, 23 Jan 2006 19:36:24 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 References: <475FF955A05DD411980D00508B6D5FB00C290769@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290769@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 00:36:25.0120 (UTC) FILETIME=[34D85A00:01C6207E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 Keith, It is a little unclear to me from reading 24.229 whether the P-Associated-URI header should contain the URI being registered or not. The text doesn't seem very explicit about that. While not definitive, I think the examples in Gonzalo's book do *not* include the URI being registered. OTOH, since the default URI must be first, if the URI being registered is to be the default then it would need to be in the list. A case when an empty P-Associated-URI might be needed is if the URI being registered is barred and there is no unbarred URI. Of course in that case the UE isn't going to be able to do anything, but there needs to be some way for it to discover that. Paul Drage, Keith (Keith) wrote: > I cannot answer the question, but I can indicate that as far as I understand the issue, 3GPP never needs to send only zero URIs, as this is included in a successful registration only, and therefore at least one address must be registered. The associated list is the list of all registered URIs, both implicit and explicit: > > Extract from 3GPP TS 24.229 subclause 5.4.1.2.2: > > "...create a 200 (OK) response for the REGISTER request, including: > > ... > > b) a P-Associated-URI header containing the list of the registered public user identity and its associated set of implicitly registered public user identities. The first URI in the list of public user identities supplied by the HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user identity indicated as the default public user identity must be a registered public user identity. The S-CSCF shall place the default public user identity as the first entry in the list of URIs present in the P-Associated-URI header. The default public user identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity header, as described in subclause 5.2.6.3. The S-CSCF shall not add a barred public user identity to the list of URIs in the P-Associated-URI header;" > > I will add this to a number of issues I am in the process of addressing in RFC 3455. > > regards > > Keith > > > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>Nataraju A B >>Sent: 23 January 2006 11:47 >>To: sip@ietf.org >>Subject: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 >> >> >>Hi All, >> >>I am posting the same query here in sipping since I did not get any >>convincing answers in sip-Implementors list...... >> >>Thanks & Regards, >>Nataraju A.B. >> >>-----Original Message----- >>From: sip-implementors-bounces@cs.columbia.edu >>[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf >>Of Nataraju >>A B >>Sent: Friday, January 20, 2006 11:57 AM >>To: sip-implementors@cs.columbia.edu >>Subject: [Sip-implementors] doubt/bug with RFC-3455 >> >>Hi All, >> >>I have a doubt in the rfc 3455 with respect to >>P-Associated-URI syntax, >> >>Excerpt from RFC-3455 >><<< >>4.1.2 Usage of the P-Associated-URI header >> >> The registrar inserts the P-Associated-URI header field >>into the 200 >> OK response to a REGISTER request. The header field value is >> populated with a list containing zero or more URIs that are >> associated to the address-of-record. >> If the registrar supports the P-Associated-URI header >>extension, then >> the registrar MUST always insert the P-Associated-URI >>header field in >> all the 200 OK responses to a REGISTER request, regardless >>of whether >> the REGISTER was an initial registration, re-registration, or >> de-registration and regardless of whether there are zero or more >> associated URIs. >> >>it says if the registrar supports P-Associated-URI, then it has to >>insert the P-Asserted-URI in 200 OK response for REGISTER >>while defining the ABNF for the same its been mentioned as >> >> P-Associated-URI = "P-Associated-URI" HCOLON >> (p-aso-uri-spec) >> *(COMMA p-aso-uri-spec) >> p-aso-uri-spec = name-addr *(SEMI ai-param) >> ai-param = generic-param >> >>This ABNF syntax says as one or more, not zero or more number of >>p-aso-uri-spec, >> >>Now my question is? >>1) Why do we need to insert the P-Associated-URI header if >>there are no >>entry to fill in ? >>2) How do we specify the zero or more P-Associated-URI header >>values ? >> >>Best Regards, >>Nataraju A.B. >>Kodiak Networks Ind Pvt Ltd >>"Change your thoughts, and you change your world." >> >>_______________________________________________ >>Sip-implementors mailing list >>Sip-implementors@cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> >>_______________________________________________ >>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 23 23:28:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1FnL-000289-QS; Mon, 23 Jan 2006 23:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1FnJ-00026K-Jb for sip@megatron.ietf.org; Mon, 23 Jan 2006 23:28:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03527 for ; Mon, 23 Jan 2006 23:27:08 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Fwl-00082P-Rz for sip@ietf.org; Mon, 23 Jan 2006 23:38:25 -0500 Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0O4OtP14995; Tue, 24 Jan 2006 09:54:56 +0530 From: "Nataraju A B" To: "'Drage, Keith \(Keith\)'" , Subject: RE: [Sip] doubt/bug with RFC-3455 Date: Tue, 24 Jan 2006 09:57:59 +0530 Message-ID: <002701c6209e$8ee2aee0$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: <475FF955A05DD411980D00508B6D5FB00C290769@en0033exch001u.uk.lucent.com> X-Spam-Score: 2.9 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: 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 Thanks & Regards, Nataraju A.B. -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Monday, January 23, 2006 9:55 PM To: 'Nataraju A B'; 'sip@ietf.org' Subject: RE: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 I cannot answer the question, but I can indicate that as far as I understand the issue, 3GPP never needs to send only zero URIs, as this is included in a successful registration only, and therefore at least one address must be registered. The associated list is the list of all registered URIs, both implicit and explicit: Extract from 3GPP TS 24.229 subclause 5.4.1.2.2: "...create a 200 (OK) response for the REGISTER request, including: ... b) a P-Associated-URI header containing the list of the registered public user identity and its associated set of implicitly registered public user identities. The first URI in the list of public user identities supplied by the HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user identity indicated as the default public user identity must be a registered public user identity. The S-CSCF shall place the default public user identity as the first entry in the list of URIs present in the P-Associated-URI header. The default public user identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity header, as described in subclause 5.2.6.3. The S-CSCF shall not add a barred public user identity to the list of URIs in the P-Associated-URI header;" I will add this to a number of issues I am in the process of addressing in RFC 3455. [ABN] If the P-Associated-URI carries at least the registered publicURI, then the definition of P-Associated-URI should be changed to carry atleast one URI (registered publicURI) not zero or more URIs ??? Does this make sense... ???? regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Nataraju A B > Sent: 23 January 2006 11:47 > To: sip@ietf.org > Subject: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 > > > Hi All, > > I am posting the same query here in sipping since I did not get any > convincing answers in sip-Implementors list...... > > Thanks & Regards, > Nataraju A.B. > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf > Of Nataraju > A B > Sent: Friday, January 20, 2006 11:57 AM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] doubt/bug with RFC-3455 > > Hi All, > > I have a doubt in the rfc 3455 with respect to > P-Associated-URI syntax, > > Excerpt from RFC-3455 > <<< > 4.1.2 Usage of the P-Associated-URI header > > The registrar inserts the P-Associated-URI header field > into the 200 > OK response to a REGISTER request. The header field value is > populated with a list containing zero or more URIs that are > associated to the address-of-record. > If the registrar supports the P-Associated-URI header > extension, then > the registrar MUST always insert the P-Associated-URI > header field in > all the 200 OK responses to a REGISTER request, regardless > of whether > the REGISTER was an initial registration, re-registration, or > de-registration and regardless of whether there are zero or more > associated URIs. > >>> > > it says if the registrar supports P-Associated-URI, then it has to > insert the P-Asserted-URI in 200 OK response for REGISTER > while defining the ABNF for the same its been mentioned as > > P-Associated-URI = "P-Associated-URI" HCOLON > (p-aso-uri-spec) > *(COMMA p-aso-uri-spec) > p-aso-uri-spec = name-addr *(SEMI ai-param) > ai-param = generic-param > > This ABNF syntax says as one or more, not zero or more number of > p-aso-uri-spec, > > Now my question is? > 1) Why do we need to insert the P-Associated-URI header if > there are no > entry to fill in ? > 2) How do we specify the zero or more P-Associated-URI header > values ? > > Best Regards, > Nataraju A.B. > Kodiak Networks Ind Pvt Ltd > "Change your thoughts, and you change your world." > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ > 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 24 01:24:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1HbA-0007lC-5U; Tue, 24 Jan 2006 01:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Hb8-0007jG-5m for sip@megatron.ietf.org; Tue, 24 Jan 2006 01:24:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11594 for ; Tue, 24 Jan 2006 01:22:39 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Hkc-0003iC-Qz for sip@ietf.org; Tue, 24 Jan 2006 01:33:59 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0O6LW8P011516; Tue, 24 Jan 2006 08:21:35 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 08:24:05 +0200 Received: from [127.0.0.1] ([10.162.26.244]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Jan 2006 08:24:04 +0200 Message-ID: <43D5C805.2050907@nokia.com> Date: Tue, 24 Jan 2006 08:24:05 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Nataraju A B Subject: Re: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 References: <000c01c62012$baef1a50$7302a8c0@Nataraju> In-Reply-To: <000c01c62012$baef1a50$7302a8c0@Nataraju> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 06:24:04.0851 (UTC) FILETIME=[C636B430:01C620AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Hi Nataraju. The spirit of the document was to have a simple mechanism where the UAC can notice if the P-Associated-URI extension is supported by the registrar. The idea was that, if the extension is supported, the registrar includes the header in the 200 OK response. That obviously requires the possibility of having an empty header, if the user under registration, does not have an associated URI. Unfortunately, as you discovered, the formal syntax does not reflect this fact, and there is a contradiction between the formal syntax and the normative text. In this case, I consider the normative text to be correct (not the syntax). BR, Miguel Nataraju A B wrote: > Hi All, > > I am posting the same query here in sipping since I did not get any > convincing answers in sip-Implementors list...... > > Thanks & Regards, > Nataraju A.B. > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Nataraju > A B > Sent: Friday, January 20, 2006 11:57 AM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] doubt/bug with RFC-3455 > > Hi All, > > I have a doubt in the rfc 3455 with respect to P-Associated-URI syntax, > > Excerpt from RFC-3455 > <<< > 4.1.2 Usage of the P-Associated-URI header > > The registrar inserts the P-Associated-URI header field into the 200 > OK response to a REGISTER request. The header field value is > populated with a list containing zero or more URIs that are > associated to the address-of-record. > If the registrar supports the P-Associated-URI header extension, then > the registrar MUST always insert the P-Associated-URI header field in > all the 200 OK responses to a REGISTER request, regardless of whether > the REGISTER was an initial registration, re-registration, or > de-registration and regardless of whether there are zero or more > associated URIs. > > it says if the registrar supports P-Associated-URI, then it has to > insert the P-Asserted-URI in 200 OK response for REGISTER > while defining the ABNF for the same its been mentioned as > > P-Associated-URI = "P-Associated-URI" HCOLON > (p-aso-uri-spec) > *(COMMA p-aso-uri-spec) > p-aso-uri-spec = name-addr *(SEMI ai-param) > ai-param = generic-param > > This ABNF syntax says as one or more, not zero or more number of > p-aso-uri-spec, > > Now my question is? > 1) Why do we need to insert the P-Associated-URI header if there are no > entry to fill in ? > 2) How do we specify the zero or more P-Associated-URI header values ? > > Best Regards, > Nataraju A.B. > Kodiak Networks Ind Pvt Ltd > "Change your thoughts, and you change your world." > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ > 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 > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, 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 Tue Jan 24 03:33:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Jcd-0003kB-V3; Tue, 24 Jan 2006 03:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Jcb-0003k4-1q for sip@megatron.ietf.org; Tue, 24 Jan 2006 03:33:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19283 for ; Tue, 24 Jan 2006 03:32:18 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Jlx-0007q0-Tu for sip@ietf.org; Tue, 24 Jan 2006 03:43:39 -0500 Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0O8SkP05679; Tue, 24 Jan 2006 13:58:49 +0530 From: "Nataraju A B" To: "'Michael Hammer \(mhammer\)'" , "'srinidhi n'" , "'Xiao Wang'" , "'Jin, Haipeng'" , "'Manish Joshi'" , "'James Polk \(jmpolk\)'" , "'Miloslavsky Evgeny'" , Subject: RE: [Sip] Re: Re-Invite before ACK Date: Tue, 24 Jan 2006 14:01:49 +0530 Message-ID: <004101c620c0$a05df680$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: <072C5B76F7CEAB488172C6F64B30B5E301030CE7@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 4.0 (++++) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Content-Transfer-Encoding: 7bit Cc: 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 Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Monday, January 23, 2006 8:39 PM To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org Subject: RE: [Sip] Re: Re-Invite before ACK So, let us see if I understood the two cases correctly based on this thread: 1. Offer-Answer complete (no SDP needed in ACK) case: UAC: Upon receipt of 200 OK and transmission of ACK, can send re-INVITE with new Offer. UAS: After sending 200 OK (with Answer), can treat receipt of re-INVITE as an implied ACK to the 200 OK, because otherwise the UAC would have never sent the INVITE. [ABN] we can't assume implicitly, reception re-INVITE does not mean 200OK was received. For UAS to process re-INVITE, ACK should be received @ UAS. So only I mentioned we will drop the re-INVITE received @ UAS before ACK. For instance UAS have some flags like ACK_EXPECTED, (similar to SDP_SENT/SDP_RECEIVED which would be used to decide about delayed or early media negotiation cases...). any way transaction match does not happen since transaction would have terminated soon after sending the 200OK, and dialog matches where based on flags like these we can decide to accept the re-INVITE or not ? Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer before sending re-INVITE to confirm Answer received. [ABN] TRUE (this is already covered in 3261), again based on some logic mentioned earlier (ACK_EXPECTED) 2. Offer-Answer not complete (SDP needed in ACK) case: UAC: Send Answer in ACK, then wait to see if 200 OK is retransmitted, meaning the ACK was not received. Thus, wait 2*T1 (expected bound for Timer G?) after receipt of previous 200 OK. If no 200 OK, then can assume that ACK was received, and proceed to send the re-INVITE. UAS: Reject any re-INVITE before ACK received with 491 Request Pending, since Answer to Offer in 200 OK was not received. Accept re-INVITE with new offer only after ACK received. [ABN] TRUE Where UAS wants to re-INVITE, wait for ACK with Answer to complete Offer in 200 OK before sending re-INVITE. [ABN] TRUE My only question is that Timer G starts with T1 not 2*T1, so is this for margin of safety? Also, doesn't this assume that both UAC and UAS use same T1 value? [ABN] Timer G applicable only for failure responses.. not for 2xx, so not an issue... Mike > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Nataraju A B > Sent: Monday, January 23, 2006 8:52 AM > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish > Joshi'; James Polk (jmpolk); 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK > > RFC does not forbid sending re-INVITE soon after sent the ACK > for the 200OK. > > I guess it would be reasonable to drop that particular > retransmitted INVITE when UAS was in expectation of ACK for > the initial INVITE. If so, the ACK Might reaches the UAS and > the actual intention of the re-INVITE would be taken care by > the subsequent retransmitted re-INVITE. > > Here we are assuming, if re-INVITE can reach UAS, for sure > ACK might also reach UAS, > > Assume if all the re-INVITEs were dropped because ACK was not > received for the earlier INVITE transaction, that lead to > call termination (BYE & > 200) that is very much inline RFC. > > Thanks & Regards, > Nataraju A.B. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of srinidhi n > Sent: Sunday, January 22, 2006 10:38 PM > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M. > Polk'; 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK > > 1. In case an SDP ofer was not made in the original Invite, > there is no way we can honour this Reinvite before an ACK and > the session must be terminated. On the other side, if a offer > was made in the Invite, the reinvite either could be > accepted/rejected(as being discussed). > > Thus, the UAS needs to exhibit a different behavior in cases > where an offer was made in Invite and when it wasn't. This > apart from cancelling the re-transmission of 200 OK on > recepton of ACK and also reinvites. > > 2. 64*T1 is the worst case time period before which a ACK is > to reach the UAS. For every T1 and doubling thereafter till > T2, the UAS retransmits a 200 OK. > Hence, the UAC can safely transmit the next message from ACK > after 2*T1, provided a 200 Ok is not retransmitted, without > worrying about any kind of UAS problems. > > 3.Another problem from UAC side would be how it would handle > a retransmitted 200 OK(assuming the ACK is > lost) after initating a Re-Invite. > > Considering UAS behavior differences it would be easier to > not to handle the reinvite at the UAS. > > -Srinidhi > --- Xiao Wang wrote: > > > inline > > > > Xiao > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > srinidhi n > > > Sent: Saturday, January 21, 2006 1:19 AM > > > To: sip@ietf.org; srinidhi104@yahoo.com > > > Cc: brett@broadsoft.com > > > Subject: [Sip] Re: Re-Invite before ACK > > > > > > Do Correct me if I am wrong. > > > > > > 1. I think unless an ACK is receved by the UAS, > > its > > > transaction will not be complete and the UAS will continue to > > > re-transmit the original 200 OK. > > good > > > 2. As per sec.13 of RFC 3261, > > > If the server retransmits the 2xx response for > > 64*T1 > > > seconds without receiving an ACK, the dialog is > confirmed, but the > > > session SHOULD be terminated. > > This > > > is accomplished with a BYE, as described in > > Section15. > > Note " but the session SHOULD be terminated ",there use " > SHOULD" not > > "MUST". > > That is the protocol allow other cases to the session isn't > > terminated. > > I think if ACK is used to acknowledge that UAC received 200 > OK and not > > taking SDP, the session may not be terminated if the timer > fired and > > UAS received re-INVITE. > > Why may UAC send re-INVITE after send ACK? > > Because the protocol doesn't forbid. If the protocol explicit set a > > rule that UAC MUST wait 64*T1 after received the first 200 > OK before > > send re-INVITE, this will not be flexible. > > In many cases, UAC need rapidly to send re-INVITE to UAS > for exchange > > new SDP after old INVITE transaction complete. > > Another cases, the value of T1 set in UAC may not equal to UAS's, > > therefore, UAC don't know wait how long. > > Alternatively, if UAS receive re-INVITE before ACK that > means to UAC > > already received 200 OK of old INVITE, and UAS must deal with the > > re-INVITE and not simple to return 491 or else failure response. > > > > > In this case, it is really difficult from the UAS perspective to > > > predict if it will receive a "ACK" > > > after the "Re-Invite" although its more likely to receive it. > > > > > > Hence, the UAS may chose to send 491 response. > > > > > > -Srinidhi > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam > > protection around > > > http://mail.yahoo.com > > > > > > _______________________________________________ > > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection > around http://mail.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ 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 24 10:12:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Pqs-0000OT-AU; Tue, 24 Jan 2006 10:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Pqq-0000OL-Bv for sip@megatron.ietf.org; Tue, 24 Jan 2006 10:12:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18788 for ; Tue, 24 Jan 2006 10:11:25 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Q0P-0005kj-Bl for sip@ietf.org; Tue, 24 Jan 2006 10:22:50 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 24 Jan 2006 07:12:47 -0800 X-IronPort-AV: i="4.01,214,1136188800"; d="scan'208"; a="1769521788:sNHT36028232" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0OFCWKt015654; Tue, 24 Jan 2006 07:12:46 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 10:12:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Re-Invite before ACK Date: Tue, 24 Jan 2006 10:12:45 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301031094@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: Re-Invite before ACK Thread-Index: AcYgwMB07I0+cGvfQeORaTBxd/WnZwANaLhw From: "Michael Hammer \(mhammer\)" To: "Nataraju A B" , "srinidhi n" , "Xiao Wang" , "Jin, Haipeng" , "Manish Joshi" , "James Polk \(jmpolk\)" , "Miloslavsky Evgeny" , X-OriginalArrivalTime: 24 Jan 2006 15:12:45.0695 (UTC) FILETIME=[A14F60F0:01C620F8] X-Spam-Score: 1.2 (+) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: quoted-printable Cc: 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 Inline.=20 > -----Original Message----- > From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]=20 > Sent: Tuesday, January 24, 2006 3:32 AM > To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang';=20 > 'Jin, Haipeng'; 'Manish Joshi'; James Polk (jmpolk);=20 > 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 > Comments inline...=20 >=20 > Thanks & Regards, > Nataraju A.B. >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, January 23, 2006 8:39 PM > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish=20 > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 > So, let us see if I understood the two cases correctly based on this > thread: >=20 > 1. Offer-Answer complete (no SDP needed in ACK) case: >=20 > UAC: Upon receipt of 200 OK and transmission of ACK, can=20 > send re-INVITE with new Offer. >=20 > UAS: After sending 200 OK (with Answer), can treat receipt=20 > of re-INVITE as an implied ACK to the 200 OK, because=20 > otherwise the UAC would have never sent the INVITE. =20 >=20 > [ABN] we can't assume implicitly, reception re-INVITE does=20 > not mean 200OK was received.=20 Why not? If the rule for UAC above were followed, a re-INVITE would *ONLY* be sent if the 200 OK had been received. Thus, receipt of the re-INVITE also implies the UAC received the 200 OK. This is straight forward logic contingent on that UAC behavior. > For UAS to process re-INVITE,=20 > ACK should be received @ UAS. So only I mentioned we will=20 > drop the re-INVITE received @ UAS before ACK. For instance=20 > UAS have some flags like ACK_EXPECTED, (similar to=20 > SDP_SENT/SDP_RECEIVED which would be used to decide about=20 > delayed or early media negotiation cases...).=20 This internal ACK_Expected flag would only be needed if the ACK needed to carry an SDP Answer as in Case 2 below. > any way=20 > transaction match does not happen since transaction would=20 > have terminated soon after sending the 200OK, and dialog=20 > matches where based on flags like these we can decide to=20 > accept the re-INVITE or not ? >=20 > Where UAS wants to re-INVITE, wait for ACK to 200 OK with=20 > Answer before sending re-INVITE to confirm Answer received. >=20 > [ABN] TRUE (this is already covered in 3261), again based on=20 > some logic mentioned earlier (ACK_EXPECTED) >=20 > 2. Offer-Answer not complete (SDP needed in ACK) case: >=20 > UAC: Send Answer in ACK, then wait to see if 200 OK is=20 > retransmitted, meaning the ACK was not received. Thus, wait=20 > 2*T1 (expected bound for Timer G?) after receipt of previous=20 > 200 OK. If no 200 OK, then can assume that ACK was received,=20 > and proceed to send the re-INVITE. >=20 > UAS: Reject any re-INVITE before ACK received with 491=20 > Request Pending, since Answer to Offer in 200 OK was not=20 > received. Accept re-INVITE with new offer only after ACK received. >=20 > [ABN] TRUE >=20 > Where UAS wants to re-INVITE, wait for ACK with Answer to=20 > complete Offer in 200 OK before sending re-INVITE. >=20 > [ABN] TRUE >=20 > My only question is that Timer G starts with T1 not 2*T1, so=20 > is this for margin of safety? Also, doesn't this assume that=20 > both UAC and UAS use same T1 value? >=20 > [ABN] Timer G applicable only for failure responses.. not for=20 > 2xx, so not an issue...=20 I think RFC-3261 could be more rigorous here. The table in the back says INVITE responses, period. I thought it was clear that the UAS upon sending a 200 OK will need to retransmit that 200 OK, if it doesn't get an ACK within some timeframe. The UAC could have sent the ACK and won't retranmit it unless it gets another 200 OK. So, there is definitely a timer for 200 OK retranmits. I am contending it is Timer G. If you say it is not, then please identify the name of the Timer. Mike >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > Nataraju A B > > Sent: Monday, January 23, 2006 8:52 AM > > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish=20 > Joshi'; James=20 > > Polk (jmpolk); 'Miloslavsky Evgeny'; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > >=20 > > RFC does not forbid sending re-INVITE soon after sent the=20 > ACK for the=20 > > 200OK. > >=20 > > I guess it would be reasonable to drop that particular=20 > retransmitted=20 > > INVITE when UAS was in expectation of ACK for the initial=20 > INVITE. If=20 > > so, the ACK Might reaches the UAS and the actual intention of the=20 > > re-INVITE would be taken care by the subsequent retransmitted=20 > > re-INVITE. > >=20 > > Here we are assuming, if re-INVITE can reach UAS, for sure=20 > ACK might=20 > > also reach UAS, > >=20 > > Assume if all the re-INVITEs were dropped because ACK was=20 > not received=20 > > for the earlier INVITE transaction, that lead to call=20 > termination (BYE=20 > > & > > 200) that is very much inline RFC. > >=20 > > Thanks & Regards, > > Nataraju A.B. > >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > srinidhi n > > Sent: Sunday, January 22, 2006 10:38 PM > > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M.=20 > > Polk'; 'Miloslavsky Evgeny'; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > >=20 > > 1. In case an SDP ofer was not made in the original Invite,=20 > there is=20 > > no way we can honour this Reinvite before an ACK and the=20 > session must=20 > > be terminated. On the other side, if a offer was made in=20 > the Invite,=20 > > the reinvite either could be accepted/rejected(as being discussed). > >=20 > > Thus, the UAS needs to exhibit a different behavior in=20 > cases where an=20 > > offer was made in Invite and when it wasn't. This apart from=20 > > cancelling the re-transmission of 200 OK on recepton of ACK=20 > and also=20 > > reinvites. > >=20 > > 2. 64*T1 is the worst case time period before which a ACK=20 > is to reach=20 > > the UAS. For every T1 and doubling thereafter till T2, the UAS=20 > > retransmits a 200 OK. > > Hence, the UAC can safely transmit the next message from ACK after=20 > > 2*T1, provided a 200 Ok is not retransmitted, without=20 > worrying about=20 > > any kind of UAS problems. > >=20 > > 3.Another problem from UAC side would be how it would handle a=20 > > retransmitted 200 OK(assuming the ACK is > > lost) after initating a Re-Invite. > >=20 > > Considering UAS behavior differences it would be easier to not to=20 > > handle the reinvite at the UAS. > >=20 > > -Srinidhi > > --- Xiao Wang wrote: > >=20 > > > inline > > >=20 > > > Xiao > > >=20 > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org > > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > > srinidhi n > > > > Sent: Saturday, January 21, 2006 1:19 AM > > > > To: sip@ietf.org; srinidhi104@yahoo.com > > > > Cc: brett@broadsoft.com > > > > Subject: [Sip] Re: Re-Invite before ACK > > > >=20 > > > > Do Correct me if I am wrong. > > > >=20 > > > > 1. I think unless an ACK is receved by the UAS, > > > its > > > > transaction will not be complete and the UAS will continue to=20 > > > > re-transmit the original 200 OK. > > > good > > > > 2. As per sec.13 of RFC 3261, > > > > If the server retransmits the 2xx response for > > > 64*T1 > > > > seconds without receiving an ACK, the dialog is > > confirmed, but the > > > > session SHOULD be terminated. > > > This > > > > is accomplished with a BYE, as described in > > > Section15. > > > Note " but the session SHOULD be terminated ",there use "=20 > > SHOULD" not > > > "MUST". > > > That is the protocol allow other cases to the session isn't=20 > > > terminated. > > > I think if ACK is used to acknowledge that UAC received 200 > > OK and not > > > taking SDP, the session may not be terminated if the timer > > fired and > > > UAS received re-INVITE. > > > Why may UAC send re-INVITE after send ACK? > > > Because the protocol doesn't forbid. If the protocol=20 > explicit set a=20 > > > rule that UAC MUST wait 64*T1 after received the first 200 > > OK before > > > send re-INVITE, this will not be flexible. > > > In many cases, UAC need rapidly to send re-INVITE to UAS > > for exchange > > > new SDP after old INVITE transaction complete. > > > Another cases, the value of T1 set in UAC may not equal to UAS's,=20 > > > therefore, UAC don't know wait how long. > > > Alternatively, if UAS receive re-INVITE before ACK that > > means to UAC > > > already received 200 OK of old INVITE, and UAS must deal with the=20 > > > re-INVITE and not simple to return 491 or else failure response. > > >=20 > > > > In this case, it is really difficult from the UAS=20 > perspective to=20 > > > > predict if it will receive a "ACK" > > > > after the "Re-Invite" although its more likely to receive it. > > > >=20 > > > > Hence, the UAS may chose to send 491 response. > > > >=20 > > > > -Srinidhi > > > >=20 > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Tired of spam? Yahoo! Mail has the best spam > > > protection around > > > > http://mail.yahoo.com > > > >=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 > > >=20 > >=20 > >=20 > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around=20 > > http://mail.yahoo.com > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ 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 24 10:25:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Q2Z-00039V-Ps; Tue, 24 Jan 2006 10:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Q2W-00036C-TZ for sip@megatron.ietf.org; Tue, 24 Jan 2006 10:25:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20525 for ; Tue, 24 Jan 2006 10:23:29 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1QC5-0006Tn-BM for sip@ietf.org; Tue, 24 Jan 2006 10:34:54 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2006 07:24:46 -0800 X-IronPort-AV: i="4.01,214,1136188800"; d="scan'208"; a="250949350:sNHT1772396282" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0OFOVcb006936; Tue, 24 Jan 2006 07:24:45 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 10:24:45 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 10:24:44 -0500 Message-ID: <43D646BC.1070108@cisco.com> Date: Tue, 24 Jan 2006 10:24:44 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 References: <000c01c62012$baef1a50$7302a8c0@Nataraju> <43D5C805.2050907@nokia.com> In-Reply-To: <43D5C805.2050907@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 15:24:45.0005 (UTC) FILETIME=[4E0D5FD0:01C620FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Miguel Garcia wrote: > Hi Nataraju. > > The spirit of the document was to have a simple mechanism where the UAC > can notice if the P-Associated-URI extension is supported by the > registrar. The idea was that, if the extension is supported, the > registrar includes the header in the 200 OK response. That obviously > requires the possibility of having an empty header, if the user under > registration, does not have an associated URI. > > Unfortunately, as you discovered, the formal syntax does not reflect > this fact, and there is a contradiction between the formal syntax and > the normative text. In this case, I consider the normative text to be > correct (not the syntax). Hmm. I buy the text as describing things that are not expressable in ABNF. But its a bit much to expect someone to process messages that conflict with the ABNF based on the text. Paul > BR, > > Miguel > > Nataraju A B wrote: > >> Hi All, >> I am posting the same query here in sipping since I did not get any >> convincing answers in sip-Implementors list...... >> Thanks & Regards, >> Nataraju A.B. >> >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu >> [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Nataraju >> A B >> Sent: Friday, January 20, 2006 11:57 AM >> To: sip-implementors@cs.columbia.edu >> Subject: [Sip-implementors] doubt/bug with RFC-3455 >> >> Hi All, >> I have a doubt in the rfc 3455 with respect to P-Associated-URI syntax, >> Excerpt from RFC-3455 <<< >> 4.1.2 Usage of the P-Associated-URI header >> >> The registrar inserts the P-Associated-URI header field into the 200 >> OK response to a REGISTER request. The header field value is >> populated with a list containing zero or more URIs that are >> associated to the address-of-record. >> If the registrar supports the P-Associated-URI header extension, then >> the registrar MUST always insert the P-Associated-URI header field in >> all the 200 OK responses to a REGISTER request, regardless of whether >> the REGISTER was an initial registration, re-registration, or >> de-registration and regardless of whether there are zero or more >> associated URIs. >> >> it says if the registrar supports P-Associated-URI, then it has to >> insert the P-Asserted-URI in 200 OK response for REGISTER while >> defining the ABNF for the same its been mentioned as >> P-Associated-URI = "P-Associated-URI" HCOLON >> (p-aso-uri-spec) >> *(COMMA p-aso-uri-spec) >> p-aso-uri-spec = name-addr *(SEMI ai-param) >> ai-param = generic-param >> >> This ABNF syntax says as one or more, not zero or more number of >> p-aso-uri-spec, >> Now my question is? 1) Why do we need to insert the P-Associated-URI >> header if there are no >> entry to fill in ? 2) How do we specify the zero or more >> P-Associated-URI header values ? >> Best Regards, >> Nataraju A.B. Kodiak Networks Ind Pvt Ltd >> "Change your thoughts, and you change your world." >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> >> _______________________________________________ >> 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 24 14:44:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1U5U-0000MK-T5; Tue, 24 Jan 2006 14:44:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1U5T-0000MA-5l for sip@megatron.ietf.org; Tue, 24 Jan 2006 14:44:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12568 for ; Tue, 24 Jan 2006 14:42:48 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1UF4-0000AJ-4k for sip@ietf.org; Tue, 24 Jan 2006 14:54:15 -0500 Received: by wproxy.gmail.com with SMTP id i1so13720wra for ; Tue, 24 Jan 2006 11:44:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=rR8CEOGklaHw+UPPzXSDgKDa5JnzOu5j/qsYaCWzW1hb8Xj1ZtHC06lbQwTHwAMORrxUDaDnLOTJ7ThfeZKEdrDiK9HwjB/dc4Ct5nswdAKshh9DMTk3X6vYcgnvqV3KykvPp8C4MrmDaARZXkaBU0yCTSvlsffCxjsS2i4hkcE= Received: by 10.64.53.12 with SMTP id b12mr2591669qba; Tue, 24 Jan 2006 11:44:14 -0800 (PST) Received: by 10.65.103.14 with HTTP; Tue, 24 Jan 2006 11:44:14 -0800 (PST) Message-ID: <5c5981350601241144y9303abao528b534c2de0a976@mail.gmail.com> Date: Tue, 24 Jan 2006 11:44:14 -0800 From: Mohsen Soroushnejad To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Sip] RFC 3261: Setting the expiration interval by Registrar? 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="===============1307564585==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1307564585== Content-Type: multipart/alternative; boundary="----=_Part_7653_15831569.1138131854309" ------=_Part_7653_15831569.1138131854309 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Can Registrar accepts a REGISTER request (send 200 OK) and set the expiration interval to a value greater than one requested in the REGISTER? The text in RFC 3261 (Section 10.3) (snippet below) is not explicit on on this question. It indicates that Registrar MAY reject a REGISTER request with 423 response code (if the conditions mentioned are met). Does it mean that it is also allowed to accept the REGISTER and set the expiration interval to a value greater than requested? >From RFC 3261 (Section 10.3): The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of 423 (Interval Too Brief). This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. ------=_Part_7653_15831569.1138131854309 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Can Registrar accepts a REGISTER request (send 200 OK) and set the exp= iration interval
to a value greater than one requested in the REGISTER?
The text in RFC 3261 (Section 10.3) (snippet below) is not explic= it on on this question.
It indicates that Registrar MAY reject a REGISTER request with 423 res= ponse code
(if the conditions mentioned are met). Does it mean that it is also al= lowed to accept
the REGISTER and set the expiration interval to a value greater than r= equested?
 
 
 
From RFC 3261 (Section 10.3):
The registrar MAY choose an expiration less than the requested
&nbs= p;        expiration interval.  If = and only if the requested expiration
      = ;   interval is greater than zero AND smaller than one hour AND         less than a registrar-co= nfigured minimum, the registrar MAY
         reject the registratio= n with a response of 423 (Interval Too
     &nb= sp;   Brief).  This response MUST contain a Min-Expires head= er field
         that states th= e minimum expiration interval the registrar is
         willing to honor. ------=_Part_7653_15831569.1138131854309-- --===============1307564585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1307564585==-- From sip-bounces@ietf.org Tue Jan 24 14:56:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UGu-0004eO-8S; Tue, 24 Jan 2006 14:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UGs-0004eG-61 for sip@megatron.ietf.org; Tue, 24 Jan 2006 14:56:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13436 for ; Tue, 24 Jan 2006 14:54:34 -0500 (EST) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1UQ8-0000ci-5G for sip@ietf.org; Tue, 24 Jan 2006 15:06:02 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 786316C03B for ; Tue, 24 Jan 2006 14:54:46 -0500 (EST) Subject: Re: [Sip] RFC 3261: Setting the expiration interval by Registrar? From: "Dale R. Worley" To: Sip In-Reply-To: <5c5981350601241144y9303abao528b534c2de0a976@mail.gmail.com> References: <5c5981350601241144y9303abao528b534c2de0a976@mail.gmail.com> Content-Type: text/plain Date: Tue, 24 Jan 2006 14:54:46 -0500 Message-Id: <1138132486.12055.45.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 On Tue, 2006-01-24 at 11:44 -0800, Mohsen Soroushnejad wrote: > Can Registrar accepts a REGISTER request (send 200 OK) and set the > expiration interval > to a value greater than one requested in the REGISTER? No. > The text in RFC 3261 (Section 10.3) (snippet below) is not explicit on > on this question. RFC 3261 says that the registrar may choose an expiration less than the requested expiration interval. It does not say that the registrar may choose an expiration more than the requested expiration interval. Dale _______________________________________________ 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 24 14:58:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UJA-0004sy-Og; Tue, 24 Jan 2006 14:58:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UJ8-0004sk-O4 for sip@megatron.ietf.org; Tue, 24 Jan 2006 14:58:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13574 for ; Tue, 24 Jan 2006 14:56:55 -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.43) id 1F1USj-0000ib-Lh for sip@ietf.org; Tue, 24 Jan 2006 15:08:23 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2006 11:58:16 -0800 X-IronPort-AV: i="4.01,214,1136188800"; d="scan'208"; a="395814677:sNHT35336686" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0OJwGWJ022192; Tue, 24 Jan 2006 11:58:16 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 11:58:14 -0800 Received: from [171.69.220.78] ([171.69.220.78]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 11:58:13 -0800 Message-ID: <43D686D5.4000302@cisco.com> Date: Tue, 24 Jan 2006 14:58:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohsen Soroushnejad Subject: Re: [Sip] RFC 3261: Setting the expiration interval by Registrar? References: <5c5981350601241144y9303abao528b534c2de0a976@mail.gmail.com> In-Reply-To: <5c5981350601241144y9303abao528b534c2de0a976@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 19:58:13.0764 (UTC) FILETIME=[826F4C40:01C62120] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Mohsen Soroushnejad wrote: > Can Registrar accepts a REGISTER request (send 200 OK) and set the > expiration interval > to a value greater than one requested in the REGISTER? No. > The text in RFC 3261 (Section 10.3) (snippet below) is not explicit on > on this question. > It indicates that Registrar MAY reject a REGISTER request with 423 > response code > (if the conditions mentioned are met). Does it mean that it is also > allowed to accept > the REGISTER and set the expiration interval to a value greater than > requested? No. There may be reasons why the client wants its registration to expire in a short time. Its better to play it safe by making the client do something active to keep its registration, rather than doing something active to remove it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Tue Jan 24 16:25:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Vfo-0005Oj-6t; Tue, 24 Jan 2006 16:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Vfm-0005OE-65 for sip@megatron.ietf.org; Tue, 24 Jan 2006 16:25:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29912 for ; Tue, 24 Jan 2006 16:24:22 -0500 (EST) Received: from mailout.excelswitching.com ([208.236.123.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1VpM-0007Vp-4a for sip@ietf.org; Tue, 24 Jan 2006 16:35:49 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar? Date: Tue, 24 Jan 2006 16:25:40 -0500 Message-ID: <656BE56E7D48F6419054CC1C811149270BA23FAE@exch01.corp.xl.com> Thread-Topic: [Sip] RFC 3261: Setting the expiration interval by Registrar? Thread-Index: AcYhIZgj2fP3H1IkQ0+52FK1e0jmxgAAze6w From: "Jain, Rajnish" To: "Jonathan Rosenberg" , "Mohsen Soroushnejad" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 One way to look at this would be to define the Registrar's behavior in such a way that it has complete control over the registration period regardless of the expiration duration clients put in their REGISTER requests. Just like a Registrar has valid reasons to lower the registration period, it may have valid reasons to up the registration period.=20 Let's say a Registrar is getting swamped with registration refresh requests and the resultant read and write operations on the Location Service database. To combat this, the registrar decides to up the registration period. While some clients may be able to honor this, some clients (for good reasons) may not be able to honor this. The clients that are able to honor this will back off and that will manifest as reduced load on the Registrar.=20 =20 If a client, such as one behind a NAT, is not able to honor this it can still go ahead and refresh bindings as frequently as it deems necessary. I don't think RFC 3261 disallows the client from refreshing registrations, for instance, every 60 seconds if the registration expiration period reported by the Registrar was 3600 seconds. If we want to somewhat relieve the registrar from frequent read and write operations into the location service, then the client can issue registration queries instead, which is a read-only operation. =20 I think by giving Registrar a complete control over the registration period, it helps the Registrar to deal with certain situations and it also makes it less confusing to describe/implement the registration period negotiation between the client and the Registrar.=20 Just a thought, Rajnish -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, January 24, 2006 2:58 PM To: Mohsen Soroushnejad Cc: sip@ietf.org Subject: Re: [Sip] RFC 3261: Setting the expiration interval by Registrar? Mohsen Soroushnejad wrote: > Can Registrar accepts a REGISTER request (send 200 OK) and set the=20 > expiration interval > to a value greater than one requested in the REGISTER? No. > The text in RFC 3261 (Section 10.3) (snippet below) is not explicit on > on this question. > It indicates that Registrar MAY reject a REGISTER request with 423=20 > response code > (if the conditions mentioned are met). Does it mean that it is also=20 > allowed to accept > the REGISTER and set the expiration interval to a value greater than=20 > requested? No. There may be reasons why the client wants its registration to expire in a short time. Its better to play it safe by making the client do=20 something active to keep its registration, rather than doing something=20 active to remove it. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Tue Jan 24 16:46:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VzJ-0006tY-D2; Tue, 24 Jan 2006 16:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VzH-0006t6-5h for sip@megatron.ietf.org; Tue, 24 Jan 2006 16:46:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05393 for ; Tue, 24 Jan 2006 16:44:31 -0500 (EST) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1W8p-0001FR-Pz for sip@ietf.org; Tue, 24 Jan 2006 16:55:57 -0500 Received: from sonusmail02.sonusnet.com (sonusmail02.sonusnet.com [10.128.32.96]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k0OLjc4l002535; Tue, 24 Jan 2006 16:45:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar? Date: Tue, 24 Jan 2006 16:45:38 -0500 Message-ID: <05AE95C39E8E2642AF9C04526EDAC414B499BC@sonusmail02.sonusnet.com> Thread-topic: [Sip] RFC 3261: Setting the expiration interval by Registrar? Thread-index: AcYhIZgj2fP3H1IkQ0+52FK1e0jmxgAAze6wAAJpxtA= From: "Bharrat, Shaun" To: "Jain, Rajnish" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Maybe I just don't understand your use case but there is nothing stopping the registrar from controlling the refresh rate. If it wants a lower value, it just lowers it. If it wants a higher value, it sends a 423 with a Min-Expires header. Cheers, Shaun Sonus Networks www.sonusnet.com -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Jain, Rajnish Sent: Tuesday, January 24, 2006 4:26 PM To: Jonathan Rosenberg; Mohsen Soroushnejad Cc: sip@ietf.org Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar? One way to look at this would be to define the Registrar's behavior in such a way that it has complete control over the registration period regardless of the expiration duration clients put in their REGISTER requests. Just like a Registrar has valid reasons to lower the registration period, it may have valid reasons to up the registration period.=20 Let's say a Registrar is getting swamped with registration refresh requests and the resultant read and write operations on the Location Service database. To combat this, the registrar decides to up the registration period. While some clients may be able to honor this, some clients (for good reasons) may not be able to honor this. The clients that are able to honor this will back off and that will manifest as reduced load on the Registrar.=20 =20 If a client, such as one behind a NAT, is not able to honor this it can still go ahead and refresh bindings as frequently as it deems necessary. I don't think RFC 3261 disallows the client from refreshing registrations, for instance, every 60 seconds if the registration expiration period reported by the Registrar was 3600 seconds. If we want to somewhat relieve the registrar from frequent read and write operations into the location service, then the client can issue registration queries instead, which is a read-only operation. =20 I think by giving Registrar a complete control over the registration period, it helps the Registrar to deal with certain situations and it also makes it less confusing to describe/implement the registration period negotiation between the client and the Registrar.=20 Just a thought, Rajnish -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, January 24, 2006 2:58 PM To: Mohsen Soroushnejad Cc: sip@ietf.org Subject: Re: [Sip] RFC 3261: Setting the expiration interval by Registrar? Mohsen Soroushnejad wrote: > Can Registrar accepts a REGISTER request (send 200 OK) and set the=20 > expiration interval > to a value greater than one requested in the REGISTER? No. > The text in RFC 3261 (Section 10.3) (snippet below) is not explicit on > on this question. > It indicates that Registrar MAY reject a REGISTER request with 423=20 > response code > (if the conditions mentioned are met). Does it mean that it is also=20 > allowed to accept > the REGISTER and set the expiration interval to a value greater than=20 > requested? No. There may be reasons why the client wants its registration to expire in a short time. Its better to play it safe by making the client do=20 something active to keep its registration, rather than doing something=20 active to remove it. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 _______________________________________________ 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 24 17:35:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Wkx-0001Pf-4Y; Tue, 24 Jan 2006 17:35:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Wkv-0001Pa-0U for sip@megatron.ietf.org; Tue, 24 Jan 2006 17:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10771 for ; Tue, 24 Jan 2006 17:33:47 -0500 (EST) Received: from mailout.excelswitching.com ([208.236.123.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1WuW-0003hh-B8 for sip@ietf.org; Tue, 24 Jan 2006 17:45:14 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar? Date: Tue, 24 Jan 2006 17:34:58 -0500 Message-ID: <656BE56E7D48F6419054CC1C811149270BA23FB6@exch01.corp.xl.com> Thread-Topic: [Sip] RFC 3261: Setting the expiration interval by Registrar? Thread-Index: AcYhIZgj2fP3H1IkQ0+52FK1e0jmxgAAze6wAAJpxtAAAHPS8A== From: "Jain, Rajnish" To: "Bharrat, Shaun" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 True, but I think that negotiation is somewhat rigid. If a client is not able to honor the Min-Expires period in the 423 response for whatever reason then it will not be able to register at all.=20 A subtle variation could be that the client is given the freedom to refresh/query registrations as frequently as it wants, even though the Registrar only needs to track a bigger expiration period. This is basically stating that given the current mechanisms in RFC 3261, one can build a client that will honor the Min-Expires reported in 423 and will then register for the appropriate duration. However, it can then send registration queries to the Registrar as frequently as it wants.=20 It is a problem local to the client that it wants to refresh frequently. Why should the Registrar be burdened with that and forced to run a smaller timer than it needs to? The NAT scenario would be an exception to this because in that case the Registrar would want to run the same timer that the client is running, so that if the client ever became inaccessible it can be marked so in the location service.=20 -----Original Message----- From: Bharrat, Shaun [mailto:SBharrat@sonusnet.com]=20 Sent: Tuesday, January 24, 2006 4:46 PM To: Jain, Rajnish Cc: sip@ietf.org Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar? Maybe I just don't understand your use case but there is nothing stopping the registrar from controlling the refresh rate. If it wants a lower value, it just lowers it. If it wants a higher value, it sends a 423 with a Min-Expires header. Cheers, Shaun Sonus Networks www.sonusnet.com -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Jain, Rajnish Sent: Tuesday, January 24, 2006 4:26 PM To: Jonathan Rosenberg; Mohsen Soroushnejad Cc: sip@ietf.org Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar? One way to look at this would be to define the Registrar's behavior in such a way that it has complete control over the registration period regardless of the expiration duration clients put in their REGISTER requests. Just like a Registrar has valid reasons to lower the registration period, it may have valid reasons to up the registration period.=20 Let's say a Registrar is getting swamped with registration refresh requests and the resultant read and write operations on the Location Service database. To combat this, the registrar decides to up the registration period. While some clients may be able to honor this, some clients (for good reasons) may not be able to honor this. The clients that are able to honor this will back off and that will manifest as reduced load on the Registrar.=20 =20 If a client, such as one behind a NAT, is not able to honor this it can still go ahead and refresh bindings as frequently as it deems necessary. I don't think RFC 3261 disallows the client from refreshing registrations, for instance, every 60 seconds if the registration expiration period reported by the Registrar was 3600 seconds. If we want to somewhat relieve the registrar from frequent read and write operations into the location service, then the client can issue registration queries instead, which is a read-only operation. =20 I think by giving Registrar a complete control over the registration period, it helps the Registrar to deal with certain situations and it also makes it less confusing to describe/implement the registration period negotiation between the client and the Registrar.=20 Just a thought, Rajnish -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, January 24, 2006 2:58 PM To: Mohsen Soroushnejad Cc: sip@ietf.org Subject: Re: [Sip] RFC 3261: Setting the expiration interval by Registrar? Mohsen Soroushnejad wrote: > Can Registrar accepts a REGISTER request (send 200 OK) and set the=20 > expiration interval > to a value greater than one requested in the REGISTER? No. > The text in RFC 3261 (Section 10.3) (snippet below) is not explicit on > on this question. > It indicates that Registrar MAY reject a REGISTER request with 423=20 > response code > (if the conditions mentioned are met). Does it mean that it is also=20 > allowed to accept > the REGISTER and set the expiration interval to a value greater than=20 > requested? No. There may be reasons why the client wants its registration to expire in a short time. Its better to play it safe by making the client do=20 something active to keep its registration, rather than doing something=20 active to remove it. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 _______________________________________________ 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 24 18:05:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XDq-0008Jj-Na; Tue, 24 Jan 2006 18:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XDo-0008Io-Ki for sip@megatron.ietf.org; Tue, 24 Jan 2006 18:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13362 for ; Tue, 24 Jan 2006 18:03:37 -0500 (EST) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1XN4-0004t9-JT for sip@ietf.org; Tue, 24 Jan 2006 18:15:05 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 966466C032 for ; Tue, 24 Jan 2006 18:03:51 -0500 (EST) Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar? From: "Dale R. Worley" To: Sip In-Reply-To: <656BE56E7D48F6419054CC1C811149270BA23FB6@exch01.corp.xl.com> References: <656BE56E7D48F6419054CC1C811149270BA23FB6@exch01.corp.xl.com> Content-Type: text/plain Date: Tue, 24 Jan 2006 18:03:51 -0500 Message-Id: <1138143831.12055.52.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit 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 On Tue, 2006-01-24 at 17:34 -0500, Jain, Rajnish wrote: > It is a problem local to the client that it wants to refresh frequently. > Why should the Registrar be burdened with that and forced to run a > smaller timer than it needs to? I don't see what the point of all this is. If the registrar is getting overwhelmed, allowing it the luxury of setting longer timers while still having to cope with the same frequency of REGISTER messages will make little difference. As Shaun Bharrat says, SIP provides the 423 response so the registrar can demand that the UA registers for a longer period, which seems to solve the problem you stated at the beginning. If the UA is incapable of registering for longer periods, there is no solution to the problem. So the best result is to have the UA not registered at all, to increase the chance that the user will notice the problem and take corrective action. In any case, SIP has clearly defined rules for how registrars and UAs should behave. If you'd like to propose an upward-compatible change that would be an improvement, please do so... Dale _______________________________________________ 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 24 21:18:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1aF3-00044o-RM; Tue, 24 Jan 2006 21:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1aF1-00044g-Qb for sip@megatron.ietf.org; Tue, 24 Jan 2006 21:18:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27731 for ; Tue, 24 Jan 2006 21:17:04 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1aOf-0003ex-JU for sip@ietf.org; Tue, 24 Jan 2006 21:28:35 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITM00CP8MTY0W@szxga01-in.huawei.com> for sip@ietf.org; Wed, 25 Jan 2006 10:27:34 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITM00FNOMTX2F@szxga01-in.huawei.com> for sip@ietf.org; Wed, 25 Jan 2006 10:27:34 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITM005RJMXCTQ@szxml02-in.huawei.com>; Wed, 25 Jan 2006 10:29:36 +0800 (CST) Date: Wed, 25 Jan 2006 10:17:59 +0800 From: Xiao Wang Subject: RE: [Sip] Re: Re-Invite before ACK In-reply-to: <072C5B76F7CEAB488172C6F64B30B5E301031094@xmb-rtp-20b.amer.cisco.com> To: "'Michael Hammer (mhammer)'" , "'Nataraju A B'" , "'srinidhi n'" , "'Jin, Haipeng'" , "'Manish Joshi'" , "'James Polk (jmpolk)'" , "'Miloslavsky Evgeny'" , sip@ietf.org Message-id: <015001c62155$8f9e70a0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.2 (+) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Content-Transfer-Encoding: 7BIT Cc: 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 Inline Xiao > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, January 24, 2006 11:13 PM > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish Joshi; James Polk > (jmpolk); Miloslavsky Evgeny; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK > > Inline. > > > -----Original Message----- > > From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com] > > Sent: Tuesday, January 24, 2006 3:32 AM > > To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang'; > > 'Jin, Haipeng'; 'Manish Joshi'; James Polk (jmpolk); > > 'Miloslavsky Evgeny'; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > Comments inline... > > > > Thanks & Regards, > > Nataraju A.B. > > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, January 23, 2006 8:39 PM > > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish > > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > So, let us see if I understood the two cases correctly based on this > > thread: > > > > 1. Offer-Answer complete (no SDP needed in ACK) case: > > > > UAC: Upon receipt of 200 OK and transmission of ACK, can > > send re-INVITE with new Offer. > > > > UAS: After sending 200 OK (with Answer), can treat receipt > > of re-INVITE as an implied ACK to the 200 OK, because > > otherwise the UAC would have never sent the INVITE. > > > > [ABN] we can't assume implicitly, reception re-INVITE does > > not mean 200OK was received. > > Why not? If the rule for UAC above were followed, a re-INVITE would > *ONLY* be sent if the 200 OK had been received. Thus, receipt of the > re-INVITE also implies the UAC received the 200 OK. This is straight > forward logic contingent on that UAC behavior. [Xiao] I fully agree with you. I guess that Nataraju points to a particular instance for SIP stack. For UAS, the retransmissions of 2xx response are handled by TU, but the requests are handled by server transaction(ST). For a particular instance, drop re-INVITE before ACK is very simple on coding, but to SIP protocol handles re-INVITE before ACK not only dropping is logical and not very complex. > > For UAS to process re-INVITE, > > ACK should be received @ UAS. So only I mentioned we will > > drop the re-INVITE received @ UAS before ACK. For instance > > UAS have some flags like ACK_EXPECTED, (similar to > > SDP_SENT/SDP_RECEIVED which would be used to decide about > > delayed or early media negotiation cases...). > > This internal ACK_Expected flag would only be needed if the ACK needed > to carry an SDP Answer as in Case 2 below. > > > any way > > transaction match does not happen since transaction would > > have terminated soon after sending the 200OK, and dialog > > matches where based on flags like these we can decide to > > accept the re-INVITE or not ? > > > > Where UAS wants to re-INVITE, wait for ACK to 200 OK with > > Answer before sending re-INVITE to confirm Answer received. > > > > [ABN] TRUE (this is already covered in 3261), again based on > > some logic mentioned earlier (ACK_EXPECTED) > > > > 2. Offer-Answer not complete (SDP needed in ACK) case: > > > > UAC: Send Answer in ACK, then wait to see if 200 OK is > > retransmitted, meaning the ACK was not received. Thus, wait > > 2*T1 (expected bound for Timer G?) after receipt of previous > > 200 OK. If no 200 OK, then can assume that ACK was received, > > and proceed to send the re-INVITE. > > > > UAS: Reject any re-INVITE before ACK received with 491 > > Request Pending, since Answer to Offer in 200 OK was not > > received. Accept re-INVITE with new offer only after ACK received. > > > > [ABN] TRUE > > > > Where UAS wants to re-INVITE, wait for ACK with Answer to > > complete Offer in 200 OK before sending re-INVITE. > > > > [ABN] TRUE > > > > My only question is that Timer G starts with T1 not 2*T1, so > > is this for margin of safety? Also, doesn't this assume that > > both UAC and UAS use same T1 value? > > > > [ABN] Timer G applicable only for failure responses.. not for > > 2xx, so not an issue... > > I think RFC-3261 could be more rigorous here. The table in the back > says INVITE responses, period. I thought it was clear that the UAS upon > sending a 200 OK will need to retransmit that 200 OK, if it doesn't get > an ACK within some timeframe. The UAC could have sent the ACK and won't > retranmit it unless it gets another 200 OK. So, there is definitely a > timer for 200 OK retranmits. I am contending it is Timer G. If you say > it is not, then please identify the name of the Timer. > > Mike > [Xiao] I know your meaning. What time does UAC send re-INVITE after ACK has not a exact time. I think this may be a regulative parameter for user that people can base on a average value of TTL between UACs and UASs add T1, and set this value to SIP stack. > > > > Mike > > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Nataraju A B > > > Sent: Monday, January 23, 2006 8:52 AM > > > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish > > Joshi'; James > > > Polk (jmpolk); 'Miloslavsky Evgeny'; sip@ietf.org > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > > > RFC does not forbid sending re-INVITE soon after sent the > > ACK for the > > > 200OK. > > > > > > I guess it would be reasonable to drop that particular > > retransmitted > > > INVITE when UAS was in expectation of ACK for the initial > > INVITE. If > > > so, the ACK Might reaches the UAS and the actual intention of the > > > re-INVITE would be taken care by the subsequent retransmitted > > > re-INVITE. > > > > > > Here we are assuming, if re-INVITE can reach UAS, for sure > > ACK might > > > also reach UAS, > > > > > > Assume if all the re-INVITEs were dropped because ACK was > > not received > > > for the earlier INVITE transaction, that lead to call > > termination (BYE > > > & > > > 200) that is very much inline RFC. > > > > > > Thanks & Regards, > > > Nataraju A.B. > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > srinidhi n > > > Sent: Sunday, January 22, 2006 10:38 PM > > > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M. > > > Polk'; 'Miloslavsky Evgeny'; sip@ietf.org > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > > > 1. In case an SDP ofer was not made in the original Invite, > > there is > > > no way we can honour this Reinvite before an ACK and the > > session must > > > be terminated. On the other side, if a offer was made in > > the Invite, > > > the reinvite either could be accepted/rejected(as being discussed). > > > > > > Thus, the UAS needs to exhibit a different behavior in > > cases where an > > > offer was made in Invite and when it wasn't. This apart from > > > cancelling the re-transmission of 200 OK on recepton of ACK > > and also > > > reinvites. > > > > > > 2. 64*T1 is the worst case time period before which a ACK > > is to reach > > > the UAS. For every T1 and doubling thereafter till T2, the UAS > > > retransmits a 200 OK. > > > Hence, the UAC can safely transmit the next message from ACK after > > > 2*T1, provided a 200 Ok is not retransmitted, without > > worrying about > > > any kind of UAS problems. > > > > > > 3.Another problem from UAC side would be how it would handle a > > > retransmitted 200 OK(assuming the ACK is > > > lost) after initating a Re-Invite. > > > > > > Considering UAS behavior differences it would be easier to not to > > > handle the reinvite at the UAS. > > > > > > -Srinidhi > > > --- Xiao Wang wrote: > > > > > > > inline > > > > > > > > Xiao > > > > > > > > > -----Original Message----- > > > > > From: sip-bounces@ietf.org > > > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > > > srinidhi n > > > > > Sent: Saturday, January 21, 2006 1:19 AM > > > > > To: sip@ietf.org; srinidhi104@yahoo.com > > > > > Cc: brett@broadsoft.com > > > > > Subject: [Sip] Re: Re-Invite before ACK > > > > > > > > > > Do Correct me if I am wrong. > > > > > > > > > > 1. I think unless an ACK is receved by the UAS, > > > > its > > > > > transaction will not be complete and the UAS will continue to > > > > > re-transmit the original 200 OK. > > > > good > > > > > 2. As per sec.13 of RFC 3261, > > > > > If the server retransmits the 2xx response for > > > > 64*T1 > > > > > seconds without receiving an ACK, the dialog is > > > confirmed, but the > > > > > session SHOULD be terminated. > > > > This > > > > > is accomplished with a BYE, as described in > > > > Section15. > > > > Note " but the session SHOULD be terminated ",there use " > > > SHOULD" not > > > > "MUST". > > > > That is the protocol allow other cases to the session isn't > > > > terminated. > > > > I think if ACK is used to acknowledge that UAC received 200 > > > OK and not > > > > taking SDP, the session may not be terminated if the timer > > > fired and > > > > UAS received re-INVITE. > > > > Why may UAC send re-INVITE after send ACK? > > > > Because the protocol doesn't forbid. If the protocol > > explicit set a > > > > rule that UAC MUST wait 64*T1 after received the first 200 > > > OK before > > > > send re-INVITE, this will not be flexible. > > > > In many cases, UAC need rapidly to send re-INVITE to UAS > > > for exchange > > > > new SDP after old INVITE transaction complete. > > > > Another cases, the value of T1 set in UAC may not equal to UAS's, > > > > therefore, UAC don't know wait how long. > > > > Alternatively, if UAS receive re-INVITE before ACK that > > > means to UAC > > > > already received 200 OK of old INVITE, and UAS must deal with the > > > > re-INVITE and not simple to return 491 or else failure response. > > > > > > > > > In this case, it is really difficult from the UAS > > perspective to > > > > > predict if it will receive a "ACK" > > > > > after the "Re-Invite" although its more likely to receive it. > > > > > > > > > > Hence, the UAS may chose to send 491 response. > > > > > > > > > > -Srinidhi > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Tired of spam? Yahoo! Mail has the best spam > > > > protection around > > > > > http://mail.yahoo.com > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list > > > > https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP > > > > Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions > > > > on current sip > > > > > Use sipping@ietf.org for new developments on the > > > > application of sip > > > > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > http://mail.yahoo.com > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ 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 25 04:03:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1gZ4-0006px-2Z; Wed, 25 Jan 2006 04:03:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1gZ0-0006pd-Db for sip@megatron.ietf.org; Wed, 25 Jan 2006 04:03:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22059 for ; Wed, 25 Jan 2006 04:02:06 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1gif-00083T-Nk for sip@ietf.org; Wed, 25 Jan 2006 04:13:41 -0500 Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0P8wOP06520; Wed, 25 Jan 2006 14:28:27 +0530 From: "Nataraju A B" To: "'Michael Hammer \(mhammer\)'" , "'srinidhi n'" , "'Xiao Wang'" , "'Jin, Haipeng'" , "'Manish Joshi'" , "'James Polk \(jmpolk\)'" , "'Miloslavsky Evgeny'" , Subject: RE: [Sip] Re: Re-Invite before ACK Date: Wed, 25 Jan 2006 14:31:27 +0530 Message-ID: <002301c6218d$f307d540$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: <072C5B76F7CEAB488172C6F64B30B5E301031094@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 4.1 (++++) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Content-Transfer-Encoding: 7bit Cc: 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 Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Tuesday, January 24, 2006 8:43 PM To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org Subject: RE: [Sip] Re: Re-Invite before ACK Inline. > -----Original Message----- > From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com] > Sent: Tuesday, January 24, 2006 3:32 AM > To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang'; > 'Jin, Haipeng'; 'Manish Joshi'; James Polk (jmpolk); > 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK > > Comments inline... > > Thanks & Regards, > Nataraju A.B. > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, January 23, 2006 8:39 PM > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK > > So, let us see if I understood the two cases correctly based on this > thread: > > 1. Offer-Answer complete (no SDP needed in ACK) case: > > UAC: Upon receipt of 200 OK and transmission of ACK, can > send re-INVITE with new Offer. > > UAS: After sending 200 OK (with Answer), can treat receipt > of re-INVITE as an implied ACK to the 200 OK, because > otherwise the UAC would have never sent the INVITE. > > [ABN] we can't assume implicitly, reception re-INVITE does > not mean 200OK was received. Why not? If the rule for UAC above were followed, a re-INVITE would *ONLY* be sent if the 200 OK had been received. Thus, receipt of the re-INVITE also implies the UAC received the 200 OK. This is straight forward logic contingent on that UAC behavior. [ABN] if we decide to accept the re-INVITE, before ACK might lead to a loop hole in the implementations where your stack assumes ACK is received but actually not. This might lead some scenarios use to happen in 2543 complaint stacks (INVITE, CANCEL scenarios, I mean 200 for CANCEL closes INV transaction also) [ABN] its always preferred to make sure you have got what you want within yourself instead of assuming other entity might have sent but not been received... > For UAS to process re-INVITE, > ACK should be received @ UAS. So only I mentioned we will > drop the re-INVITE received @ UAS before ACK. For instance > UAS have some flags like ACK_EXPECTED, (similar to > SDP_SENT/SDP_RECEIVED which would be used to decide about > delayed or early media negotiation cases...). This internal ACK_Expected flag would only be needed if the ACK needed to carry an SDP Answer as in Case 2 below. > any way > transaction match does not happen since transaction would > have terminated soon after sending the 200OK, and dialog > matches where based on flags like these we can decide to > accept the re-INVITE or not ? > > Where UAS wants to re-INVITE, wait for ACK to 200 OK with > Answer before sending re-INVITE to confirm Answer received. > > [ABN] TRUE (this is already covered in 3261), again based on > some logic mentioned earlier (ACK_EXPECTED) > > 2. Offer-Answer not complete (SDP needed in ACK) case: > > UAC: Send Answer in ACK, then wait to see if 200 OK is > retransmitted, meaning the ACK was not received. Thus, wait > 2*T1 (expected bound for Timer G?) after receipt of previous > 200 OK. If no 200 OK, then can assume that ACK was received, > and proceed to send the re-INVITE. > > UAS: Reject any re-INVITE before ACK received with 491 > Request Pending, since Answer to Offer in 200 OK was not > received. Accept re-INVITE with new offer only after ACK received. > > [ABN] TRUE > > Where UAS wants to re-INVITE, wait for ACK with Answer to > complete Offer in 200 OK before sending re-INVITE. > > [ABN] TRUE > > My only question is that Timer G starts with T1 not 2*T1, so > is this for margin of safety? Also, doesn't this assume that > both UAC and UAS use same T1 value? > > [ABN] Timer G applicable only for failure responses.. not for > 2xx, so not an issue... I think RFC-3261 could be more rigorous here. The table in the back says INVITE responses, period. I thought it was clear that the UAS upon sending a 200 OK will need to retransmit that 200 OK, if it doesn't get an ACK within some timeframe. The UAC could have sent the ACK and won't retranmit it unless it gets another 200 OK. So, there is definitely a timer for 200 OK retranmits. I am contending it is Timer G. If you say it is not, then please identify the name of the Timer. [ABN] there is no timer name defined as such, but how often UAS has to retransmit the 2xx response is mentioned in sec 13.3.1.4. The table at the end says only brief about the timers being used in SIP stack implementations... but what is mentioned in the particular section carries more detailed information... Mike > > Mike > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Nataraju A B > > Sent: Monday, January 23, 2006 8:52 AM > > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish > Joshi'; James > > Polk (jmpolk); 'Miloslavsky Evgeny'; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > RFC does not forbid sending re-INVITE soon after sent the > ACK for the > > 200OK. > > > > I guess it would be reasonable to drop that particular > retransmitted > > INVITE when UAS was in expectation of ACK for the initial > INVITE. If > > so, the ACK Might reaches the UAS and the actual intention of the > > re-INVITE would be taken care by the subsequent retransmitted > > re-INVITE. > > > > Here we are assuming, if re-INVITE can reach UAS, for sure > ACK might > > also reach UAS, > > > > Assume if all the re-INVITEs were dropped because ACK was > not received > > for the earlier INVITE transaction, that lead to call > termination (BYE > > & > > 200) that is very much inline RFC. > > > > Thanks & Regards, > > Nataraju A.B. > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > srinidhi n > > Sent: Sunday, January 22, 2006 10:38 PM > > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M. > > Polk'; 'Miloslavsky Evgeny'; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > 1. In case an SDP ofer was not made in the original Invite, > there is > > no way we can honour this Reinvite before an ACK and the > session must > > be terminated. On the other side, if a offer was made in > the Invite, > > the reinvite either could be accepted/rejected(as being discussed). > > > > Thus, the UAS needs to exhibit a different behavior in > cases where an > > offer was made in Invite and when it wasn't. This apart from > > cancelling the re-transmission of 200 OK on recepton of ACK > and also > > reinvites. > > > > 2. 64*T1 is the worst case time period before which a ACK > is to reach > > the UAS. For every T1 and doubling thereafter till T2, the UAS > > retransmits a 200 OK. > > Hence, the UAC can safely transmit the next message from ACK after > > 2*T1, provided a 200 Ok is not retransmitted, without > worrying about > > any kind of UAS problems. > > > > 3.Another problem from UAC side would be how it would handle a > > retransmitted 200 OK(assuming the ACK is > > lost) after initating a Re-Invite. > > > > Considering UAS behavior differences it would be easier to not to > > handle the reinvite at the UAS. > > > > -Srinidhi > > --- Xiao Wang wrote: > > > > > inline > > > > > > Xiao > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org > > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > > srinidhi n > > > > Sent: Saturday, January 21, 2006 1:19 AM > > > > To: sip@ietf.org; srinidhi104@yahoo.com > > > > Cc: brett@broadsoft.com > > > > Subject: [Sip] Re: Re-Invite before ACK > > > > > > > > Do Correct me if I am wrong. > > > > > > > > 1. I think unless an ACK is receved by the UAS, > > > its > > > > transaction will not be complete and the UAS will continue to > > > > re-transmit the original 200 OK. > > > good > > > > 2. As per sec.13 of RFC 3261, > > > > If the server retransmits the 2xx response for > > > 64*T1 > > > > seconds without receiving an ACK, the dialog is > > confirmed, but the > > > > session SHOULD be terminated. > > > This > > > > is accomplished with a BYE, as described in > > > Section15. > > > Note " but the session SHOULD be terminated ",there use " > > SHOULD" not > > > "MUST". > > > That is the protocol allow other cases to the session isn't > > > terminated. > > > I think if ACK is used to acknowledge that UAC received 200 > > OK and not > > > taking SDP, the session may not be terminated if the timer > > fired and > > > UAS received re-INVITE. > > > Why may UAC send re-INVITE after send ACK? > > > Because the protocol doesn't forbid. If the protocol > explicit set a > > > rule that UAC MUST wait 64*T1 after received the first 200 > > OK before > > > send re-INVITE, this will not be flexible. > > > In many cases, UAC need rapidly to send re-INVITE to UAS > > for exchange > > > new SDP after old INVITE transaction complete. > > > Another cases, the value of T1 set in UAC may not equal to UAS's, > > > therefore, UAC don't know wait how long. > > > Alternatively, if UAS receive re-INVITE before ACK that > > means to UAC > > > already received 200 OK of old INVITE, and UAS must deal with the > > > re-INVITE and not simple to return 491 or else failure response. > > > > > > > In this case, it is really difficult from the UAS > perspective to > > > > predict if it will receive a "ACK" > > > > after the "Re-Invite" although its more likely to receive it. > > > > > > > > Hence, the UAS may chose to send 491 response. > > > > > > > > -Srinidhi > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Tired of spam? Yahoo! Mail has the best spam > > > protection around > > > > http://mail.yahoo.com > > > > > > > > _______________________________________________ > > > > Sip mailing list > > > https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP > > > Protocol > > > > Use sip-implementors@cs.columbia.edu for questions > > > on current sip > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ 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 25 07:20:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1jdS-0003D4-JM; Wed, 25 Jan 2006 07:20:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1jdP-0003Cb-UU for sip@megatron.ietf.org; Wed, 25 Jan 2006 07:20:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05823 for ; Wed, 25 Jan 2006 07:18:53 -0500 (EST) Received: from 81-178-58-134.dsl.pipex.com ([81.178.58.134] helo=PJPROJECT.NET) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1jn8-0006NW-CW for sip@ietf.org; Wed, 25 Jan 2006 07:30:28 -0500 Received: from [127.0.0.1] (HP-DESKTOP.home [192.168.0.7]) by PJPROJECT.NET (8.13.4/8.13.4) with ESMTP id k0PCMfwI003247; Wed, 25 Jan 2006 12:22:41 GMT Message-ID: <43D76CDF.2070804@bulukucing.org> Date: Wed, 25 Jan 2006 12:19:43 +0000 From: Benny Prijono User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Re: Re-Invite before ACK References: <072C5B76F7CEAB488172C6F64B30B5E301030CE7@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301030CE7@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0603-0, 15/01/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James Polk \(jmpolk\)" , srinidhi n 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 Michael, I very much like the way you structurized the problem, it makes it very easy to read. Unfortunately the second case doesn't work. More inline. Michael Hammer (mhammer) wrote: > So, let us see if I understood the two cases correctly based on this > thread: > > 1. Offer-Answer complete (no SDP needed in ACK) case: > > UAC: Upon receipt of 200 OK and transmission of ACK, can send re-INVITE > with new Offer. > > UAS: After sending 200 OK (with Answer), can treat receipt of re-INVITE > as an implied ACK to the 200 OK, because otherwise the UAC would have > never sent the INVITE. > Yes, this may work. Although this would be at best seen as "optimization" trick in the implementation, not a change in the standard. I mean, if you choose to do this, then it may work. If you don't want to do this, then it's fine too. But still I don't like the "implied" bits, it sounds like we're violating the standard INVITE cycle. I propose to add additional text to your solution: (UAS): .. But UAS MUST still retransmit the 200 OK until ACK is received, and it SHOULD terminate the dialog usage with BYE if ACK is not received. This way we're not violating the standard (I hope). > Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer before > sending re-INVITE to confirm Answer received. > > 2. Offer-Answer not complete (SDP needed in ACK) case: > > UAC: Send Answer in ACK, then wait to see if 200 OK is retransmitted, > meaning the ACK was not received. Thus, wait 2*T1 (expected bound for > Timer G?) after receipt of previous 200 OK. If no 200 OK, then can > assume that ACK was received, and proceed to send the re-INVITE. > This will not work in all situations. It will only work in the ideal situation where the first 200 OK transmission is received by UAC and the ACK is not lost either. But what if the first three 200 OK responses are lost? The 2*T1 will be useless, since the second 200 response seen by UAC will be received 2 seconds after it received the first one. So in general, I think this type of solution will not work, because there is no way for UAC to know when the next response will arrive. Thus for UAC, the only thing that works is to handle 491 (Request Pending) response when it arrives. -benny > UAS: Reject any re-INVITE before ACK received with 491 Request Pending, > since Answer to Offer in 200 OK was not received. Accept re-INVITE with > new offer only after ACK received. > > Where UAS wants to re-INVITE, wait for ACK with Answer to complete Offer > in 200 OK before sending re-INVITE. > > My only question is that Timer G starts with T1 not 2*T1, so is this for > margin of safety? Also, doesn't this assume that both UAC and UAS use > same T1 value? > > Mike > > _______________________________________________ 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 25 09:46:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1luh-00040f-4S; Wed, 25 Jan 2006 09:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1luc-00040V-WF for sip@megatron.ietf.org; Wed, 25 Jan 2006 09:46:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17748 for ; Wed, 25 Jan 2006 09:44:47 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1m4L-0003YK-Tj for sip@ietf.org; Wed, 25 Jan 2006 09:56:25 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2006 09:45:03 -0500 X-IronPort-AV: i="4.01,217,1136178000"; d="scan'208"; a="80934010:sNHT37234854" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0PEij6T008810; Wed, 25 Jan 2006 09:44:58 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 09:44:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Re-Invite before ACK Date: Wed, 25 Jan 2006 09:44:49 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30103144F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: Re-Invite before ACK Thread-Index: AcYhVaJYAVyzKkZnQEurtPLo9zal4AAZ9ZXw From: "Michael Hammer \(mhammer\)" To: "Xiao Wang" , "Nataraju A B" , "srinidhi n" , "Jin, Haipeng" , "Manish Joshi" , "James Polk \(jmpolk\)" , "Miloslavsky Evgeny" , X-OriginalArrivalTime: 25 Jan 2006 14:44:49.0983 (UTC) FILETIME=[E4EBC4F0:01C621BD] X-Spam-Score: 1.2 (+) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Content-Transfer-Encoding: quoted-printable Cc: 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 BTW, I was not suggesting that this behavior was necessary, only that it could work. If from an implementation standpoint, and still compliant to RFC-3261, you have another way to handle this, then go for it. The crux of the matter for me was that there was an open-endedness to when to send the re-INVITE that could lead to sub-optimal performance from the user experience in terms of getting the SDP to converge on the desired stable state, whatever it was that required the re-INVITE. More in the other emails. Mike =20 > -----Original Message----- > From: Xiao Wang [mailto:wangsmile@huawei.com]=20 > Sent: Tuesday, January 24, 2006 9:18 PM > To: Michael Hammer (mhammer); 'Nataraju A B'; 'srinidhi n';=20 > 'Jin, Haipeng'; 'Manish Joshi'; James Polk (jmpolk);=20 > 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 > Inline >=20 > Xiao >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, January 24, 2006 11:13 PM > > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng;=20 > Manish Joshi;=20 > > James > Polk > > (jmpolk); Miloslavsky Evgeny; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > >=20 > > Inline. > >=20 > > > -----Original Message----- > > > From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com] > > > Sent: Tuesday, January 24, 2006 3:32 AM > > > To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang'; 'Jin,=20 > > > Haipeng'; 'Manish Joshi'; James Polk (jmpolk);=20 > 'Miloslavsky Evgeny';=20 > > > sip@ietf.org > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > >=20 > > > Comments inline... > > > > > > Thanks & Regards, > > > Nataraju A.B. > > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Monday, January 23, 2006 8:39 PM > > > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng;=20 > Manish Joshi;=20 > > > James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > > > So, let us see if I understood the two cases correctly=20 > based on this > > > thread: > > > > > > 1. Offer-Answer complete (no SDP needed in ACK) case: > > > > > > UAC: Upon receipt of 200 OK and transmission of ACK, can send=20 > > > re-INVITE with new Offer. > > > > > > UAS: After sending 200 OK (with Answer), can treat receipt of=20 > > > re-INVITE as an implied ACK to the 200 OK, because=20 > otherwise the UAC=20 > > > would have never sent the INVITE. > > > > > > [ABN] we can't assume implicitly, reception re-INVITE=20 > does not mean=20 > > > 200OK was received. > >=20 > > Why not? If the rule for UAC above were followed, a re-INVITE would > > *ONLY* be sent if the 200 OK had been received. Thus,=20 > receipt of the=20 > > re-INVITE also implies the UAC received the 200 OK. This=20 > is straight=20 > > forward logic contingent on that UAC behavior. > [Xiao] I fully agree with you. I guess that Nataraju points=20 > to a particular instance for SIP stack. > For UAS, the retransmissions of 2xx response are handled by=20 > TU, but the requests are handled by server transaction(ST).=20 > For a particular instance, drop re-INVITE before ACK is very=20 > simple on coding, but to SIP protocol handles re-INVITE=20 > before ACK not only dropping is logical and not very complex. >=20 >=20 > > > For UAS to process re-INVITE, > > > ACK should be received @ UAS. So only I mentioned we will=20 > drop the=20 > > > re-INVITE received @ UAS before ACK. For instance UAS have some=20 > > > flags like ACK_EXPECTED, (similar to SDP_SENT/SDP_RECEIVED which=20 > > > would be used to decide about delayed or early media negotiation=20 > > > cases...). > >=20 > > This internal ACK_Expected flag would only be needed if the=20 > ACK needed=20 > > to carry an SDP Answer as in Case 2 below. > >=20 > > > any way > > > transaction match does not happen since transaction would have=20 > > > terminated soon after sending the 200OK, and dialog matches where=20 > > > based on flags like these we can decide to accept the=20 > re-INVITE or=20 > > > not ? > > > > > > Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer=20 > > > before sending re-INVITE to confirm Answer received. > > > > > > [ABN] TRUE (this is already covered in 3261), again based on some=20 > > > logic mentioned earlier (ACK_EXPECTED) > > > > > > 2. Offer-Answer not complete (SDP needed in ACK) case: > > > > > > UAC: Send Answer in ACK, then wait to see if 200 OK is=20 > > > retransmitted, meaning the ACK was not received. Thus, wait > > > 2*T1 (expected bound for Timer G?) after receipt of=20 > previous 200 OK. =20 > > > If no 200 OK, then can assume that ACK was received, and=20 > proceed to=20 > > > send the re-INVITE. > > > > > > UAS: Reject any re-INVITE before ACK received with 491 Request=20 > > > Pending, since Answer to Offer in 200 OK was not=20 > received. Accept=20 > > > re-INVITE with new offer only after ACK received. > > > > > > [ABN] TRUE > > > > > > Where UAS wants to re-INVITE, wait for ACK with Answer to=20 > complete=20 > > > Offer in 200 OK before sending re-INVITE. > > > > > > [ABN] TRUE > > > > > > My only question is that Timer G starts with T1 not 2*T1,=20 > so is this=20 > > > for margin of safety? Also, doesn't this assume that=20 > both UAC and=20 > > > UAS use same T1 value? > > > > > > [ABN] Timer G applicable only for failure responses.. not=20 > for 2xx,=20 > > > so not an issue... > >=20 > > I think RFC-3261 could be more rigorous here. The table in=20 > the back=20 > > says INVITE responses, period. I thought it was clear that the UAS=20 > > upon sending a 200 OK will need to retransmit that 200 OK, if it=20 > > doesn't get an ACK within some timeframe. The UAC could=20 > have sent the=20 > > ACK and won't retranmit it unless it gets another 200 OK. =20 > So, there=20 > > is definitely a timer for 200 OK retranmits. I am contending it is=20 > > Timer G. If you say it is not, then please identify the=20 > name of the Timer. > >=20 > > Mike > > > [Xiao] I know your meaning. What time does UAC send re-INVITE=20 > after ACK has not a exact time. I think this may be a=20 > regulative parameter for user that people can base on a=20 > average value of TTL between UACs and UASs add T1, and set=20 > this value to SIP stack. >=20 >=20 > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of > > > > Nataraju A B > > > > Sent: Monday, January 23, 2006 8:52 AM > > > > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish > > > Joshi'; James > > > > Polk (jmpolk); 'Miloslavsky Evgeny'; sip@ietf.org > > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > > > > > RFC does not forbid sending re-INVITE soon after sent the > > > ACK for the > > > > 200OK. > > > > > > > > I guess it would be reasonable to drop that particular > > > retransmitted > > > > INVITE when UAS was in expectation of ACK for the initial > > > INVITE. If > > > > so, the ACK Might reaches the UAS and the actual=20 > intention of the=20 > > > > re-INVITE would be taken care by the subsequent retransmitted=20 > > > > re-INVITE. > > > > > > > > Here we are assuming, if re-INVITE can reach UAS, for sure > > > ACK might > > > > also reach UAS, > > > > > > > > Assume if all the re-INVITEs were dropped because ACK was > > > not received > > > > for the earlier INVITE transaction, that lead to call > > > termination (BYE > > > > & > > > > 200) that is very much inline RFC. > > > > > > > > Thanks & Regards, > > > > Nataraju A.B. > > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of > > > > srinidhi n > > > > Sent: Sunday, January 22, 2006 10:38 PM > > > > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M. > > > > Polk'; 'Miloslavsky Evgeny'; sip@ietf.org > > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > > > > > > > 1. In case an SDP ofer was not made in the original Invite, > > > there is > > > > no way we can honour this Reinvite before an ACK and the > > > session must > > > > be terminated. On the other side, if a offer was made in > > > the Invite, > > > > the reinvite either could be accepted/rejected(as being=20 > discussed). > > > > > > > > Thus, the UAS needs to exhibit a different behavior in > > > cases where an > > > > offer was made in Invite and when it wasn't. This apart from=20 > > > > cancelling the re-transmission of 200 OK on recepton of ACK > > > and also > > > > reinvites. > > > > > > > > 2. 64*T1 is the worst case time period before which a ACK > > > is to reach > > > > the UAS. For every T1 and doubling thereafter till T2, the UAS=20 > > > > retransmits a 200 OK. > > > > Hence, the UAC can safely transmit the next message=20 > from ACK after=20 > > > > 2*T1, provided a 200 Ok is not retransmitted, without > > > worrying about > > > > any kind of UAS problems. > > > > > > > > 3.Another problem from UAC side would be how it would handle a=20 > > > > retransmitted 200 OK(assuming the ACK is > > > > lost) after initating a Re-Invite. > > > > > > > > Considering UAS behavior differences it would be easier=20 > to not to=20 > > > > handle the reinvite at the UAS. > > > > > > > > -Srinidhi > > > > --- Xiao Wang wrote: > > > > > > > > > inline > > > > > > > > > > Xiao > > > > > > > > > > > -----Original Message----- > > > > > > From: sip-bounces@ietf.org > > > > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > > > > srinidhi n > > > > > > Sent: Saturday, January 21, 2006 1:19 AM > > > > > > To: sip@ietf.org; srinidhi104@yahoo.com > > > > > > Cc: brett@broadsoft.com > > > > > > Subject: [Sip] Re: Re-Invite before ACK > > > > > > > > > > > > Do Correct me if I am wrong. > > > > > > > > > > > > 1. I think unless an ACK is receved by the UAS, > > > > > its > > > > > > transaction will not be complete and the UAS will=20 > continue to=20 > > > > > > re-transmit the original 200 OK. > > > > > good > > > > > > 2. As per sec.13 of RFC 3261, > > > > > > If the server retransmits the 2xx response for > > > > > 64*T1 > > > > > > seconds without receiving an ACK, the dialog is > > > > confirmed, but the > > > > > > session SHOULD be terminated. > > > > > This > > > > > > is accomplished with a BYE, as described in > > > > > Section15. > > > > > Note " but the session SHOULD be terminated ",there use " > > > > SHOULD" not > > > > > "MUST". > > > > > That is the protocol allow other cases to the session isn't=20 > > > > > terminated. > > > > > I think if ACK is used to acknowledge that UAC received 200 > > > > OK and not > > > > > taking SDP, the session may not be terminated if the timer > > > > fired and > > > > > UAS received re-INVITE. > > > > > Why may UAC send re-INVITE after send ACK? > > > > > Because the protocol doesn't forbid. If the protocol > > > explicit set a > > > > > rule that UAC MUST wait 64*T1 after received the first 200 > > > > OK before > > > > > send re-INVITE, this will not be flexible. > > > > > In many cases, UAC need rapidly to send re-INVITE to UAS > > > > for exchange > > > > > new SDP after old INVITE transaction complete. > > > > > Another cases, the value of T1 set in UAC may not equal to=20 > > > > > UAS's, therefore, UAC don't know wait how long. > > > > > Alternatively, if UAS receive re-INVITE before ACK that > > > > means to UAC > > > > > already received 200 OK of old INVITE, and UAS must deal with=20 > > > > > the re-INVITE and not simple to return 491 or else=20 > failure response. > > > > > > > > > > > In this case, it is really difficult from the UAS > > > perspective to > > > > > > predict if it will receive a "ACK" > > > > > > after the "Re-Invite" although its more likely to=20 > receive it. > > > > > > > > > > > > Hence, the UAS may chose to send 491 response. > > > > > > > > > > > > -Srinidhi > > > > > > > > > > > > __________________________________________________ > > > > > > Do You Yahoo!? > > > > > > Tired of spam? Yahoo! Mail has the best spam > > > > > protection around > > > > > > http://mail.yahoo.com > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list > > > > > https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP > > > > > Protocol > > > > > > Use sip-implementors@cs.columbia.edu for questions > > > > > on current sip > > > > > > Use sipping@ietf.org for new developments on the > > > > > application of sip > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Tired of spam? Yahoo! Mail has the best spam protection around=20 > > > > http://mail.yahoo.com > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > 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=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > 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 Wed Jan 25 09:57:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1m5J-0005zF-4K; Wed, 25 Jan 2006 09:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1m5G-0005xZ-G1 for sip@megatron.ietf.org; Wed, 25 Jan 2006 09:57:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18513 for ; Wed, 25 Jan 2006 09:55:46 -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.43) id 1F1mEy-0003v2-PR for sip@ietf.org; Wed, 25 Jan 2006 10:07:24 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Jan 2006 06:56:49 -0800 X-IronPort-AV: i="4.01,217,1136188800"; d="scan'208"; a="396208663:sNHT36034020732" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0PEubKV021457; Wed, 25 Jan 2006 06:56:49 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 09:56:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Re-Invite before ACK Date: Wed, 25 Jan 2006 09:56:37 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301031465@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: Re-Invite before ACK Thread-Index: AcYhjhPIqPjCp/gxTRKxdClyd8U5UQAL+eyg From: "Michael Hammer \(mhammer\)" To: "Nataraju A B" , "srinidhi n" , "Xiao Wang" , "Jin, Haipeng" , "Manish Joshi" , "James Polk \(jmpolk\)" , "Miloslavsky Evgeny" , X-OriginalArrivalTime: 25 Jan 2006 14:56:38.0689 (UTC) FILETIME=[8B57B910:01C621BF] X-Spam-Score: 1.2 (+) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Content-Transfer-Encoding: quoted-printable Cc: 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 =20 > -----Original Message----- > From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]=20 > Sent: Wednesday, January 25, 2006 4:01 AM > To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang';=20 > 'Jin, Haipeng'; 'Manish Joshi'; James Polk (jmpolk);=20 > 'Miloslavsky Evgeny'; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 > Comments inline...=20 >=20 > Thanks & Regards, > Nataraju A.B. >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, January 24, 2006 8:43 PM > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish=20 > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 > Inline.=20 >=20 > > -----Original Message----- > > From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com] > > Sent: Tuesday, January 24, 2006 3:32 AM > > To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang'; 'Jin,=20 > > Haipeng'; 'Manish Joshi'; James Polk (jmpolk); 'Miloslavsky=20 > Evgeny';=20 > > sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > >=20 > > Comments inline...=20 > >=20 > > Thanks & Regards, > > Nataraju A.B. > >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, January 23, 2006 8:39 PM > > To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng;=20 > Manish Joshi;=20 > > James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > > Subject: RE: [Sip] Re: Re-Invite before ACK > >=20 > > So, let us see if I understood the two cases correctly based on this > > thread: > >=20 > > 1. Offer-Answer complete (no SDP needed in ACK) case: > >=20 > > UAC: Upon receipt of 200 OK and transmission of ACK, can send=20 > > re-INVITE with new Offer. > >=20 > > UAS: After sending 200 OK (with Answer), can treat receipt of=20 > > re-INVITE as an implied ACK to the 200 OK, because=20 > otherwise the UAC=20 > > would have never sent the INVITE. > >=20 > > [ABN] we can't assume implicitly, reception re-INVITE does not mean=20 > > 200OK was received. >=20 > Why not? If the rule for UAC above were followed, a re-INVITE would > *ONLY* be sent if the 200 OK had been received. Thus,=20 > receipt of the re-INVITE also implies the UAC received the=20 > 200 OK. This is straight forward logic contingent on that=20 > UAC behavior. >=20 > [ABN] if we decide to accept the re-INVITE, before ACK might=20 > lead to a loop hole in the implementations where your stack=20 > assumes ACK is received but actually not. This might lead=20 > some scenarios use to happen in 2543 complaint stacks=20 > (INVITE, CANCEL scenarios, I mean 200 for CANCEL closes INV=20 > transaction also) I agree it may be questionable to rely on the compliance of the UAC to standards. The re-INVITE MUST not be sent unless the Offer was Answered in the 200 OK. I could argue that all bets are off if the UAC is violating multiple requirements. But, that is beside the point. There is nothing complelling one to do the above optimization. So, if it hurts you, don't do it. :) > [ABN] its always preferred to make sure you have got what you=20 > want within yourself instead of assuming other entity might=20 > have sent but not been received...=20 I was only suggesting that the sole thing that the ACK tells you is identical to what the re-INVITE would tell you. Nothing more. Of course, I could be overlooking something. > > For UAS to process re-INVITE, > > ACK should be received @ UAS. So only I mentioned we will drop the=20 > > re-INVITE received @ UAS before ACK. For instance UAS have=20 > some flags=20 > > like ACK_EXPECTED, (similar to SDP_SENT/SDP_RECEIVED which would be=20 > > used to decide about delayed or early media negotiation cases...). >=20 > This internal ACK_Expected flag would only be needed if the=20 > ACK needed to carry an SDP Answer as in Case 2 below. >=20 > > any way > > transaction match does not happen since transaction would have=20 > > terminated soon after sending the 200OK, and dialog matches where=20 > > based on flags like these we can decide to accept the=20 > re-INVITE or not=20 > > ? > >=20 > > Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer=20 > > before sending re-INVITE to confirm Answer received. > >=20 > > [ABN] TRUE (this is already covered in 3261), again based on some=20 > > logic mentioned earlier (ACK_EXPECTED) > >=20 > > 2. Offer-Answer not complete (SDP needed in ACK) case: > >=20 > > UAC: Send Answer in ACK, then wait to see if 200 OK is=20 > retransmitted,=20 > > meaning the ACK was not received. Thus, wait > > 2*T1 (expected bound for Timer G?) after receipt of=20 > previous 200 OK. =20 > > If no 200 OK, then can assume that ACK was received, and proceed to=20 > > send the re-INVITE. > >=20 > > UAS: Reject any re-INVITE before ACK received with 491 Request=20 > > Pending, since Answer to Offer in 200 OK was not received. Accept=20 > > re-INVITE with new offer only after ACK received. > >=20 > > [ABN] TRUE > >=20 > > Where UAS wants to re-INVITE, wait for ACK with Answer to complete=20 > > Offer in 200 OK before sending re-INVITE. > >=20 > > [ABN] TRUE > >=20 > > My only question is that Timer G starts with T1 not 2*T1,=20 > so is this=20 > > for margin of safety? Also, doesn't this assume that both=20 > UAC and UAS=20 > > use same T1 value? > >=20 > > [ABN] Timer G applicable only for failure responses.. not=20 > for 2xx, so=20 > > not an issue... >=20 > I think RFC-3261 could be more rigorous here. The table in=20 > the back says INVITE responses, period. I thought it was=20 > clear that the UAS upon sending a 200 OK will need to=20 > retransmit that 200 OK, if it doesn't get an ACK within some=20 > timeframe. The UAC could have sent the ACK and won't=20 > retranmit it unless it gets another 200 OK. So, there is=20 > definitely a timer for 200 OK retranmits. I am contending it=20 > is Timer G. If you say it is not, then please identify the=20 > name of the Timer. >=20 > [ABN] there is no timer name defined as such, but how often=20 > UAS has to retransmit the 2xx response is mentioned in sec 13.3.1.4. I re-read the section. The behavior is identical to the Timer G. There seems to be some suggestion that because RFC-3261 split the behavior into three layers, these timers should be layer specific. So be it. Then the Timer table should identify which timers belong to which layers, and we could call the timer defined in Section 13.3.1.4 Timer G' or some other letter. Maybe on the next version. Mike >=20 > The table at the end says only brief about the timers being=20 > used in SIP stack implementations... but what is mentioned in=20 > the particular section carries more detailed information...=20 >=20 > Mike >=20 > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Nataraju A B > > > Sent: Monday, January 23, 2006 8:52 AM > > > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish > > Joshi'; James > > > Polk (jmpolk); 'Miloslavsky Evgeny'; sip@ietf.org > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > >=20 > > > RFC does not forbid sending re-INVITE soon after sent the > > ACK for the > > > 200OK. > > >=20 > > > I guess it would be reasonable to drop that particular > > retransmitted > > > INVITE when UAS was in expectation of ACK for the initial > > INVITE. If > > > so, the ACK Might reaches the UAS and the actual intention of the=20 > > > re-INVITE would be taken care by the subsequent retransmitted=20 > > > re-INVITE. > > >=20 > > > Here we are assuming, if re-INVITE can reach UAS, for sure > > ACK might > > > also reach UAS, > > >=20 > > > Assume if all the re-INVITEs were dropped because ACK was > > not received > > > for the earlier INVITE transaction, that lead to call > > termination (BYE > > > & > > > 200) that is very much inline RFC. > > >=20 > > > Thanks & Regards, > > > Nataraju A.B. > > >=20 > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > srinidhi n > > > Sent: Sunday, January 22, 2006 10:38 PM > > > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M.=20 > > > Polk'; 'Miloslavsky Evgeny'; sip@ietf.org > > > Subject: RE: [Sip] Re: Re-Invite before ACK > > >=20 > > > 1. In case an SDP ofer was not made in the original Invite, > > there is > > > no way we can honour this Reinvite before an ACK and the > > session must > > > be terminated. On the other side, if a offer was made in > > the Invite, > > > the reinvite either could be accepted/rejected(as being=20 > discussed). > > >=20 > > > Thus, the UAS needs to exhibit a different behavior in > > cases where an > > > offer was made in Invite and when it wasn't. This apart from=20 > > > cancelling the re-transmission of 200 OK on recepton of ACK > > and also > > > reinvites. > > >=20 > > > 2. 64*T1 is the worst case time period before which a ACK > > is to reach > > > the UAS. For every T1 and doubling thereafter till T2, the UAS=20 > > > retransmits a 200 OK. > > > Hence, the UAC can safely transmit the next message from=20 > ACK after=20 > > > 2*T1, provided a 200 Ok is not retransmitted, without > > worrying about > > > any kind of UAS problems. > > >=20 > > > 3.Another problem from UAC side would be how it would handle a=20 > > > retransmitted 200 OK(assuming the ACK is > > > lost) after initating a Re-Invite. > > >=20 > > > Considering UAS behavior differences it would be easier to not to=20 > > > handle the reinvite at the UAS. > > >=20 > > > -Srinidhi > > > --- Xiao Wang wrote: > > >=20 > > > > inline > > > >=20 > > > > Xiao > > > >=20 > > > > > -----Original Message----- > > > > > From: sip-bounces@ietf.org > > > > [mailto:sip-bounces@ietf.org] On Behalf Of > > > > > srinidhi n > > > > > Sent: Saturday, January 21, 2006 1:19 AM > > > > > To: sip@ietf.org; srinidhi104@yahoo.com > > > > > Cc: brett@broadsoft.com > > > > > Subject: [Sip] Re: Re-Invite before ACK > > > > >=20 > > > > > Do Correct me if I am wrong. > > > > >=20 > > > > > 1. I think unless an ACK is receved by the UAS, > > > > its > > > > > transaction will not be complete and the UAS will continue to=20 > > > > > re-transmit the original 200 OK. > > > > good > > > > > 2. As per sec.13 of RFC 3261, > > > > > If the server retransmits the 2xx response for > > > > 64*T1 > > > > > seconds without receiving an ACK, the dialog is > > > confirmed, but the > > > > > session SHOULD be terminated. > > > > This > > > > > is accomplished with a BYE, as described in > > > > Section15. > > > > Note " but the session SHOULD be terminated ",there use "=20 > > > SHOULD" not > > > > "MUST". > > > > That is the protocol allow other cases to the session isn't=20 > > > > terminated. > > > > I think if ACK is used to acknowledge that UAC received 200 > > > OK and not > > > > taking SDP, the session may not be terminated if the timer > > > fired and > > > > UAS received re-INVITE. > > > > Why may UAC send re-INVITE after send ACK? > > > > Because the protocol doesn't forbid. If the protocol > > explicit set a > > > > rule that UAC MUST wait 64*T1 after received the first 200 > > > OK before > > > > send re-INVITE, this will not be flexible. > > > > In many cases, UAC need rapidly to send re-INVITE to UAS > > > for exchange > > > > new SDP after old INVITE transaction complete. > > > > Another cases, the value of T1 set in UAC may not equal=20 > to UAS's,=20 > > > > therefore, UAC don't know wait how long. > > > > Alternatively, if UAS receive re-INVITE before ACK that > > > means to UAC > > > > already received 200 OK of old INVITE, and UAS must=20 > deal with the=20 > > > > re-INVITE and not simple to return 491 or else failure response. > > > >=20 > > > > > In this case, it is really difficult from the UAS > > perspective to > > > > > predict if it will receive a "ACK" > > > > > after the "Re-Invite" although its more likely to receive it. > > > > >=20 > > > > > Hence, the UAS may chose to send 491 response. > > > > >=20 > > > > > -Srinidhi > > > > >=20 > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Tired of spam? Yahoo! Mail has the best spam > > > > protection around > > > > > http://mail.yahoo.com > > > > >=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 > > > >=20 > > >=20 > > >=20 > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around=20 > > > http://mail.yahoo.com > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=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 Wed Jan 25 10:56:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1n0Y-0002Pt-Vp; Wed, 25 Jan 2006 10:56:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1n0W-0002Oo-2d for sip@megatron.ietf.org; Wed, 25 Jan 2006 10:56:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22629 for ; Wed, 25 Jan 2006 10:54:56 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1nAG-0005km-JJ for sip@ietf.org; Wed, 25 Jan 2006 11:06:35 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2006 10:56:00 -0500 X-IronPort-AV: i="4.01,217,1136178000"; d="scan'208"; a="80939031:sNHT40135381194" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0PFtsPO023500; Wed, 25 Jan 2006 10:55:56 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 10:55:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Re-Invite before ACK Date: Wed, 25 Jan 2006 10:55:52 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3010314C6@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: Re-Invite before ACK Thread-Index: AcYhqaZXqDww0UiWSzWHrZbyPjCDzwAFfCyw From: "Michael Hammer \(mhammer\)" To: "Benny Prijono" X-OriginalArrivalTime: 25 Jan 2006 15:55:54.0010 (UTC) FILETIME=[D27AA7A0:01C621C7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "James Polk \(jmpolk\)" , srinidhi n 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 Thanks. More inline.=20 > -----Original Message----- > From: Benny Prijono [mailto:lists@bulukucing.org]=20 > Sent: Wednesday, January 25, 2006 7:20 AM > To: Michael Hammer (mhammer) > Cc: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish=20 > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > Subject: Re: [Sip] Re: Re-Invite before ACK >=20 > Michael, >=20 > I very much like the way you structurized the problem, it=20 > makes it very easy to read. Unfortunately the second case=20 > doesn't work. >=20 > More inline. >=20 >=20 > Michael Hammer (mhammer) wrote: > > So, let us see if I understood the two cases correctly based on this > > thread: > >=20 > > 1. Offer-Answer complete (no SDP needed in ACK) case: > >=20 > > UAC: Upon receipt of 200 OK and transmission of ACK, can send=20 > > re-INVITE with new Offer. > >=20 > > UAS: After sending 200 OK (with Answer), can treat receipt of=20 > > re-INVITE as an implied ACK to the 200 OK, because=20 > otherwise the UAC=20 > > would have never sent the INVITE. > >=20 >=20 > Yes, this may work. Although this would be at best seen as=20 > "optimization" trick in the implementation, not a change in=20 > the standard. I mean, if you choose to do this, then it may=20 > work. If you don't want to do this, then it's fine too. >=20 > But still I don't like the "implied" bits, it sounds like=20 > we're violating the standard INVITE cycle. I propose to add=20 > additional text to your solution: >=20 > (UAS): .. But UAS MUST still retransmit the 200 OK until ACK=20 > is received, and it SHOULD terminate the dialog usage with=20 > BYE if ACK is not received. >=20 > This way we're not violating the standard (I hope). Agree. I was only thinking of whether the Post Dial Delay could be minimized. I think the implication is sound, but all the same, it is probably best to verify with continued 200 OK and ACK retransmissions as you suggest. It could still be possible that the ACK arrives in time to end the Timer G' behavior. =20 > > Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer=20 > > before sending re-INVITE to confirm Answer received. > >=20 > > 2. Offer-Answer not complete (SDP needed in ACK) case: > >=20 > > UAC: Send Answer in ACK, then wait to see if 200 OK is=20 > retransmitted,=20 > > meaning the ACK was not received. Thus, wait 2*T1=20 > (expected bound for=20 > > Timer G?) after receipt of previous 200 OK. If no 200 OK, then can=20 > > assume that ACK was received, and proceed to send the re-INVITE. > >=20 >=20 > This will not work in all situations. It will only work in=20 > the ideal situation where the first 200 OK transmission is=20 > received by UAC and the ACK is not lost either. >=20 > But what if the first three 200 OK responses are lost? The=20 > 2*T1 will be useless, since the second 200 response seen by=20 > UAC will be received > 2 seconds after it received the first one. You misunderstood the actual suggestion because it was not clearly laid out. The idea was that the UAS is going to retransmit 200 OK according to a Timer G' behavior. Let us call what the UAC thinks this behavior is the Timer G". Assuming T1=3D500 ms, Timer G' at UAS will send 200 OK at: Interval: 0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 Times: 0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer H' fires at T1*64=3D32 sec) Timer G" at UAC can have identical behavior. Assume one-way transport time is .1 second. Interval: 0.0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H' fires at = T1*64=3D32 sec) At time 0 the 200 OK is sent. At time 0.1 it is received at the UAC. If the ACK is not received the UAS would send again at time 0.5 and the UAC would receive it at time 0.6 At time 0.6, if a second 200 OK is received, UAC retransmits the ACK and sets Timer G"=3D1 so that it fires at time 1.6. At time 1.6, if a third 200 OK is received, UAC retransmits the ACK and sets Timer G"=3D2 so that it fires at time 3.6 and so on. =20 This is the theoretical minimum. The actual suggestion was to start the Timer G" at 2*T1: Interval: 0.0, 1.0, 2.0, 4.0, 8.0, 16.0 Times: 0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" fires at T1*64=3D32 sec) Compare with the Timer G' behavior adjusted with .1 cross-network transmit time. Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H' fires at = T1*64=3D32 sec) Note that the "200 OK expected" times are increasingly larger than what the actual 200 OK receipt times at the UAC should be. The end-game for Timer H" would need to be handled, but you get the idea now, I hope. > So in general, I think this type of solution will not work,=20 > because there is no way for UAC to know when the next=20 > response will arrive.=20 I would state this the other way. There is no way for the UAC to know that the ACK was received and therefore that a 200 OK will not be forthcoming. The issue still is answering the question (rather than waiting some very long time) when is the earliest it is reasonable to try to send the re-INVITE with high probability of success? If you send immediately and get a 491 in return, this just puts the UAC in the same situation of needing to decide when to retranmit. The ACK could be received immediately after the 491 was sent. So, sending the re-INVITE immediately after ACK has only postponed this decision *IF* the network delivery and handling at the UAS is misordered. =20 Perhaps a compromise is to wait an RTT before sending the re-INVITE and allow Timer A to take care of the rest. (Note Timer A will fire quicker than Timer G'.) Mike > Thus for UAC, the only thing that works is to handle 491 (Request > Pending) response when it arrives. >=20 > -benny >=20 > > UAS: Reject any re-INVITE before ACK received with 491 Request=20 > > Pending, since Answer to Offer in 200 OK was not received. Accept=20 > > re-INVITE with new offer only after ACK received. > >=20 > > Where UAS wants to re-INVITE, wait for ACK with Answer to complete=20 > > Offer in 200 OK before sending re-INVITE. > >=20 > > My only question is that Timer G starts with T1 not 2*T1,=20 > so is this=20 > > for margin of safety? Also, doesn't this assume that both=20 > UAC and UAS=20 > > use same T1 value? > >=20 > > Mike > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 25 12:03:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1o3R-0000OJ-VA; Wed, 25 Jan 2006 12:03:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1o3P-0000Ns-GO for sip@megatron.ietf.org; Wed, 25 Jan 2006 12:03:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01137 for ; Wed, 25 Jan 2006 12:02:01 -0500 (EST) Received: from 81-178-58-134.dsl.pipex.com ([81.178.58.134] helo=PJPROJECT.NET) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1oDA-0000Ht-9W for sip@ietf.org; Wed, 25 Jan 2006 12:13:38 -0500 Received: from [127.0.0.1] (HP-DESKTOP.home [192.168.0.7]) by PJPROJECT.NET (8.13.4/8.13.4) with ESMTP id k0PH4kWt005539; Wed, 25 Jan 2006 17:04:46 GMT Message-ID: <43D7AEF6.5020707@bulukucing.org> Date: Wed, 25 Jan 2006 17:01:42 +0000 From: Benny Prijono User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Re: Re-Invite before ACK References: <072C5B76F7CEAB488172C6F64B30B5E3010314C6@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3010314C6@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0603-0, 15/01/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James Polk \(jmpolk\)" , srinidhi n 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 Michael, even after your lengthy explanation, I still think it wouldn't work. Perhaps it's because I didn't explain it clearly either. More inline. Michael Hammer (mhammer) wrote: > Thanks. More inline. > > You misunderstood the actual suggestion because it was not clearly laid > out. The idea was that the UAS is going to retransmit 200 OK according > to a Timer G' behavior. Let us call what the UAC thinks this behavior > is the Timer G". Assuming T1=500 ms, Timer G' at UAS will send 200 OK > at: > > Interval: 0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > Times: 0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer H' fires at T1*64=32 > sec) > > Timer G" at UAC can have identical behavior. Assume one-way transport > time is .1 second. > Interval: 0.0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H' fires at T1*64=32 > sec) > The problem is, you assumed that timer G" starts in UAC at the same time when timer G' starts in UAS. This is not possible (I think). Timer G" can only start at UAC when UAC receives the first 2xx response. Is this correct, or am I missing something here? If this is correct, then what if the first 2xx response received by UAC is actually the n-th retransmission (because n-1 responses were lost). In this case, timer G' and G" won't be synchronized. Let me illustrate with a diagram. We'll ignore RTT time, for simplification. Time UAC UAS 0.000 lost X <------ 200/OK -- 0.500 lost X <------ 200/OK -- 1.500 lost X <------ 200/OK -- 3.500 <------------------ 200/OK -- -- ACK -----------> X lost 7.500 <------------------ 200/OK -- At time 3.500, UAC starts timer G". After 2*T1, at time 4.500, UAC thinks it's okay to send re-INVITE, because no 200 retransmission is received. But this is wrong, since the retransmission WILL be received at time 7.500. Am I missing something? -benny > At time 0 the 200 OK is sent. At time 0.1 it is received at the UAC. > > If the ACK is not received the UAS would send again at time 0.5 and the > UAC would receive it at time 0.6 > > At time 0.6, if a second 200 OK is received, UAC retransmits the ACK and > sets Timer G"=1 so that it fires at time 1.6. > > At time 1.6, if a third 200 OK is received, UAC retransmits the ACK and > sets Timer G"=2 so that it fires at time 3.6 and so on. > > This is the theoretical minimum. The actual suggestion was to start the > Timer G" at 2*T1: > Interval: 0.0, 1.0, 2.0, 4.0, 8.0, 16.0 > Times: 0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" fires at T1*64=32 > sec) > > Compare with the Timer G' behavior adjusted with .1 cross-network > transmit time. > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H' fires at T1*64=32 > sec) > > Note that the "200 OK expected" times are increasingly larger than what > the actual 200 OK receipt times at the UAC should be. The end-game for > Timer H" would need to be handled, but you get the idea now, I hope. > > >>So in general, I think this type of solution will not work, >>because there is no way for UAC to know when the next >>response will arrive. > > > I would state this the other way. There is no way for the UAC to know > that the ACK was received and therefore that a 200 OK will not be > forthcoming. The issue still is answering the question (rather than > waiting some very long time) when is the earliest it is reasonable to > try to send the re-INVITE with high probability of success? > > If you send immediately and get a 491 in return, this just puts the UAC > in the same situation of needing to decide when to retranmit. The ACK > could be received immediately after the 491 was sent. So, sending the > re-INVITE immediately after ACK has only postponed this decision *IF* > the network delivery and handling at the UAS is misordered. > > Perhaps a compromise is to wait an RTT before sending the re-INVITE and > allow Timer A to take care of the rest. (Note Timer A will fire quicker > than Timer G'.) > > Mike > > >>Thus for UAC, the only thing that works is to handle 491 (Request >>Pending) response when it arrives. >> >>-benny >> >> >>>UAS: Reject any re-INVITE before ACK received with 491 Request >>>Pending, since Answer to Offer in 200 OK was not received. Accept >>>re-INVITE with new offer only after ACK received. >>> >>>Where UAS wants to re-INVITE, wait for ACK with Answer to complete >>>Offer in 200 OK before sending re-INVITE. >>> >>>My only question is that Timer G starts with T1 not 2*T1, >> >>so is this >> >>>for margin of safety? Also, doesn't this assume that both >> >>UAC and UAS >> >>>use same T1 value? >>> >>>Mike >>> >>> >> > _______________________________________________ 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 25 12:42:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ofX-0002SL-Nn; Wed, 25 Jan 2006 12:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ofV-0002Qh-A0 for sip@megatron.ietf.org; Wed, 25 Jan 2006 12:42:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04470 for ; Wed, 25 Jan 2006 12:41:22 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1opI-0001mK-1F for sip@ietf.org; Wed, 25 Jan 2006 12:53:00 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2006 12:42:42 -0500 X-IronPort-AV: i="4.01,218,1136178000"; d="scan'208"; a="80947297:sNHT37951788" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0PHg86j007861; Wed, 25 Jan 2006 12:42:39 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 12:42:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Re-Invite before ACK Date: Wed, 25 Jan 2006 12:42:30 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30103155F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: Re-Invite before ACK Thread-Index: AcYh0S869NIm7JkUQ1O6Nujroy4mhwAASMEw From: "Michael Hammer \(mhammer\)" To: "Benny Prijono" X-OriginalArrivalTime: 25 Jan 2006 17:42:31.0645 (UTC) FILETIME=[B7C448D0:01C621D6] X-Spam-Score: 0.2 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "James Polk \(jmpolk\)" , srinidhi n 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 =20 > -----Original Message----- > From: Benny Prijono [mailto:lists@bulukucing.org]=20 > Sent: Wednesday, January 25, 2006 12:02 PM > To: Michael Hammer (mhammer) > Cc: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish=20 > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > Subject: Re: [Sip] Re: Re-Invite before ACK >=20 > Michael, >=20 > even after your lengthy explanation, I still think it wouldn't work.=20 > Perhaps it's because I didn't explain it clearly either. More inline. >=20 > Michael Hammer (mhammer) wrote: > > Thanks. More inline.=20 > >=20 > > You misunderstood the actual suggestion because it was not clearly=20 > > laid out. The idea was that the UAS is going to retransmit 200 OK=20 > > according to a Timer G' behavior. Let us call what the UAC thinks=20 > > this behavior is the Timer G". Assuming T1=3D500 ms, Timer G' at = UAS=20 > > will send 200 OK > > at: > >=20 > > Interval: 0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > Times: 0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer H' fires=20 > at T1*64=3D32 > > sec) > >=20 > > Timer G" at UAC can have identical behavior. Assume=20 > one-way transport=20 > > time is .1 second. > > Interval: 0.0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H'=20 > fires at T1*64=3D32 > > sec) > >=20 >=20 > The problem is, you assumed that timer G" starts in UAC at=20 > the same time when timer G' starts in UAS. This is not=20 > possible (I think).=20 > Timer G" can only start at UAC when UAC receives the first=20 > 2xx response. Is this correct, or am I missing something here? Yes, Timer G" only gets started once the 200 OK is received and why I had to include the half RTT. > If this is correct, then what if the first 2xx response=20 > received by UAC is actually the n-th retransmission (because=20 > n-1 responses were lost). In this case, timer G' and G" won't=20 > be synchronized. >=20 > Let me illustrate with a diagram. We'll ignore RTT time, for=20 > simplification. >=20 > Time UAC UAS > 0.000 lost X <------ 200/OK -- > 0.500 lost X <------ 200/OK -- > 1.500 lost X <------ 200/OK -- > 3.500 <------------------ 200/OK -- > -- ACK -----------> X lost > 7.500 <------------------ 200/OK -- >=20 > At time 3.500, UAC starts timer G". After 2*T1, at time=20 > 4.500, UAC thinks it's okay to send re-INVITE, because no 200=20 > retransmission is received. But this is wrong, since the=20 > retransmission WILL be received at time 7.500. >=20 > Am I missing something? >=20 > -benny Yes, I see the problem now. The UAS is further out in its backoff interval than the UAC which started its backoff interval later, but more aggressive. Thus, the UAC would always beat the UAS to the punch. Of course once you have two 200 OKs, you would know where in this sequence you were, but that is too complex. This suggested hypothetical behavior would work better (thinking out loud) if Timer G' and G" were more like Timer E and retrans at MIN(2*T1, T2), that is at regular intervals. Or, even just define a T5 value say, 2 seconds, with no back off. =20 Makes me wonder if INVITE response retransmissions in general should not exhibit a backoff. That is Timer G, G', G" should all be at some fixed interval. This would speed up comletion of the INVITE transaction. But, that would require a change to RFC-3261. Would have to think what the downside to that is. The current alternative seems to be keep pounding the UAS with re-INVITEs until one gets through. That is more brute force and would seem to aggravate overload conditions. BTW, I can't claim any credit for this Timer G" idea, I was only following through the thought introduced earlier by someone else. Mike >=20 > > At time 0 the 200 OK is sent. At time 0.1 it is received=20 > at the UAC. > >=20 > > If the ACK is not received the UAS would send again at time 0.5 and=20 > > the UAC would receive it at time 0.6 > >=20 > > At time 0.6, if a second 200 OK is received, UAC=20 > retransmits the ACK=20 > > and sets Timer G"=3D1 so that it fires at time 1.6. > >=20 > > At time 1.6, if a third 200 OK is received, UAC retransmits the ACK=20 > > and sets Timer G"=3D2 so that it fires at time 3.6 and so on. > >=20 > > This is the theoretical minimum. The actual suggestion was=20 > to start=20 > > the Timer G" at 2*T1: > > Interval: 0.0, 1.0, 2.0, 4.0, 8.0, 16.0 > > Times: 0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" fires at = T1*64=3D32 > > sec) > >=20 > > Compare with the Timer G' behavior adjusted with .1 cross-network=20 > > transmit time. > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H'=20 > fires at T1*64=3D32 > > sec) > >=20 > > Note that the "200 OK expected" times are increasingly larger than=20 > > what the actual 200 OK receipt times at the UAC should be. The=20 > > end-game for Timer H" would need to be handled, but you get=20 > the idea now, I hope. > >=20 > >=20 > >>So in general, I think this type of solution will not work, because=20 > >>there is no way for UAC to know when the next response will arrive. > >=20 > >=20 > > I would state this the other way. There is no way for the=20 > UAC to know=20 > > that the ACK was received and therefore that a 200 OK will not be=20 > > forthcoming. The issue still is answering the question=20 > (rather than=20 > > waiting some very long time) when is the earliest it is=20 > reasonable to=20 > > try to send the re-INVITE with high probability of success? > >=20 > > If you send immediately and get a 491 in return, this just puts the=20 > > UAC in the same situation of needing to decide when to=20 > retranmit. The=20 > > ACK could be received immediately after the 491 was sent. =20 > So, sending=20 > > the re-INVITE immediately after ACK has only postponed this=20 > decision=20 > > *IF* the network delivery and handling at the UAS is misordered. > >=20 > > Perhaps a compromise is to wait an RTT before sending the re-INVITE=20 > > and allow Timer A to take care of the rest. (Note Timer A=20 > will fire=20 > > quicker than Timer G'.) > >=20 > > Mike > >=20 > >=20 > >>Thus for UAC, the only thing that works is to handle 491 (Request > >>Pending) response when it arrives. > >> > >>-benny > >> > >> > >>>UAS: Reject any re-INVITE before ACK received with 491 Request=20 > >>>Pending, since Answer to Offer in 200 OK was not received. Accept=20 > >>>re-INVITE with new offer only after ACK received. > >>> > >>>Where UAS wants to re-INVITE, wait for ACK with Answer to complete=20 > >>>Offer in 200 OK before sending re-INVITE. > >>> > >>>My only question is that Timer G starts with T1 not 2*T1, > >> > >>so is this > >> > >>>for margin of safety? Also, doesn't this assume that both > >> > >>UAC and UAS > >> > >>>use same T1 value? > >>> > >>>Mike > >>> > >>> > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 25 17:14:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1sub-0006Ud-7f; Wed, 25 Jan 2006 17:14:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1suX-0006Mo-MB for sip@megatron.ietf.org; Wed, 25 Jan 2006 17:14:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28445 for ; Wed, 25 Jan 2006 17:13:08 -0500 (EST) Received: from zimbra.mailvision.net ([212.143.248.123] helo=mvimap.mailvision.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1t4K-00040d-O9 for sip@ietf.org; Wed, 25 Jan 2006 17:24:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id D0AF28706BD for ; Thu, 26 Jan 2006 00:14:11 +0200 (IST) Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30789-06 for ; Thu, 26 Jan 2006 00:14:11 +0200 (IST) Received: from [192.168.10.100] (diegob.bb.netvision.net.il [212.143.127.193]) by mvimap.mailvision.net (Postfix) with ESMTP id C6A37870643 for ; Thu, 26 Jan 2006 00:14:10 +0200 (IST) Message-ID: <43D7F853.8020200@mailvision.com> Date: Thu, 26 Jan 2006 00:14:43 +0200 From: Diego B User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.244 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=0.155, BAYES_00=-2.599] X-Spam-Score: -4.244 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Sip] Question about Forking in a Proxy 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="===============1174572541==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1174572541== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020404080605000004070309" This is a cryptographically signed message in MIME format. --------------ms020404080605000004070309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi; For example user Tom is registered to Proxy1 from different devices. Proxy1 receives an incoming INVITE for Tom and starts forking the INVITE to all the registered devices. Now, my question. Tom doesn't want to answer, but to reject the call ( some 4xx final response for example). But he can not reject the call from all the devices, because he only has access to one of them. How can Tom sends a response to Proxy1 to: 1- Reject the call ( send to caller non-2xx final response ) and at the same time 2- Cancel all pending Client transactions Thanks; Diego B --------------ms020404080605000004070309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFpzCC AmAwggHJoAMCAQICEG3TF9j428smmpt/imLDz9gwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDEyMTE3MDAxMVoX DTA3MDEyMTE3MDAxMVowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG CSqGSIb3DQEJARYVZGllZ29iQG1haWx2aXNpb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC9aNhu3NL4upmyL/kwYGKbvkqqb/JtlaQy5O8uMm+YyQ36/ogh5U6V3gJOWmiF IuNgxxUe8fgwUdjY7G7j8MX4WsCYXKcEiilCtZBJFNc104w7oCHLgnd5qci4ki5OCHwgUOjl pq0Tpsxl+ugW+Erao/8hxFEpIr3EYuPx4U1xlQIDAQABozIwMDAgBgNVHREEGTAXgRVkaWVn b2JAbWFpbHZpc2lvbi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBIRqB5 0MkdHekEgdQnRFUQd7gld2NOIwPg37RZLzniUyVFREVjIt1l8g6mF0s0sviwPNiE18L2fChS vpDQaKBiyusfPbVY5l6Hxq2lil8AKzKaxoQKizcEoyf6VkjiDQwuvPOcR3EL7AVeCM0jQKOm Rm4aPZL/Hq3pcJGpTKgmtzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggHQMIIBzAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbdMX2Pjb yyaam3+KYsPP2DAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDEyNTIyMTQ0M1owIwYJKoZIhvcNAQkEMRYEFOgNZ3aVrCjMjKtf DrBH8HVXisBwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIGAGRu0dY8U3zwMtd8JOnVjgyjyMbDd0S0IL6lEb+SfICRrPAoAjUic2dijj/LiDToKUDJi 6MUzX4d9YpTzeVS7Sfq5vEufr+Z1JG7ry031O1SVXcyukpUUXSZbl3B6+GFg8TojnGwCCLWo WSSmWJRYqB3WfZO1cSO5nYODgG4q6FQAAAAAAAA= --------------ms020404080605000004070309-- --===============1174572541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1174572541==-- From sip-bounces@ietf.org Wed Jan 25 17:33:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1tD3-00070P-R3; Wed, 25 Jan 2006 17:33:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1tD1-00070D-Se for sip@megatron.ietf.org; Wed, 25 Jan 2006 17:33:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29870 for ; Wed, 25 Jan 2006 17:32:15 -0500 (EST) Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1tMo-0004eq-PY for sip@ietf.org; Wed, 25 Jan 2006 17:43:58 -0500 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.01) id AC910308; Wed, 25 Jan 2006 17:32:49 -0500 Message-ID: <015501c621ff$53e547f0$800101df@acmepacket.com> From: "Bob Penfield" To: "Diego B" , References: <43D7F853.8020200@mailvision.com> Subject: Re: [Sip] Question about Forking in a Proxy Date: Wed, 25 Jan 2006 17:33:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: 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 A 6xx response will cause the proxy server to CANCEL all other branches of the fork. >From RFC 3261, section 16.7: If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Diego B" To: Sent: Wednesday, January 25, 2006 5:14 PM Subject: [Sip] Question about Forking in a Proxy > _______________________________________________ > 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 26 10:42:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F29G7-0001JD-V1; Thu, 26 Jan 2006 10:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F29G6-0001Hm-6V for sip@megatron.ietf.org; Thu, 26 Jan 2006 10:42:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28267 for ; Thu, 26 Jan 2006 10:40:29 -0500 (EST) Received: from mail.infointeractive.com ([207.231.225.15] helo=smtp.infointeractive.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29Q3-0001Mw-Ds for sip@ietf.org; Thu, 26 Jan 2006 10:52:20 -0500 Received: from eng.infointeractive.com ([10.142.0.50]:48092 "EHLO eng.infointeractive.com") by mail.infointeractive.com with ESMTP id S782659AbWAZPlf (ORCPT ); Thu, 26 Jan 2006 11:41:35 -0400 Received: from localhost (user: 'benoit', uid#6008) by eng.infointeractive.com id <214821-8233>; Thu, 26 Jan 2006 11:41:24 -0400 Date: Thu, 26 Jan 2006 11:41:23 -0400 From: David Benoit To: sip@ietf.org Message-ID: <20060126154123.GA20821@infointeractive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Sip] Providing Delayed Call Information 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 Cross posting this as it may be more applicable here. ----- Forwarded message from David Benoit ----- Date: Tue, 24 Jan 2006 16:49:00 -0400 From: David Benoit To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Providing Delayed Call Information Hi, I want to solve the following problem. A large number of the calls that we get from our providers have all the calling information present (i.e. the name of the caller, or CNAM if you wish), but some of the calls don't have that present. We have several alternative sources for calling name information that we consult to populate that name (caches, databases, etc.) but that lookup can take "time" (not a long time, but not instantaneous). The problem is, I don't want to hold back the INVITE until I get that information back; it could take like 100ms or so depending on the source and I am not willing to wait. I want to send out the INVITE to the UAC and when the calling name information has been determined, send that to update the information that was in the INVITE. As an example, for any of you Q.931/850 types out there, it would be the same as getting the Setup message without a calling name and getting a Facility message sometime later on with that name. I initially thought that the UPDATE method was what I wanted, but after actually reading the RFC, it's not at all what I want. I then thought that I wanted an INVITE/Replaces, but that seems to me like using a sledgehammer to hang a picture :) and I'm not really sure it would have the desired effect. So, I need to know if this is already "handled" in SIP. I can't find anything that suggests how to do this and even though I could add support in our systems for a custom method that would allow this, I would rather not if the problem has already been solved. Suggestions? Thanks in advance! David -- David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ----- End forwarded message ----- _______________________________________________ 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 26 11:43:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ADp-0001HC-Qh; Thu, 26 Jan 2006 11:43:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ADo-0001H4-Aq for sip@megatron.ietf.org; Thu, 26 Jan 2006 11:43:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03093 for ; Thu, 26 Jan 2006 11:42:10 -0500 (EST) Received: from mail.infointeractive.com ([207.231.225.15] helo=smtp.infointeractive.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2ANk-0003Xe-VM for sip@ietf.org; Thu, 26 Jan 2006 11:54:03 -0500 Received: from eng.infointeractive.com ([10.142.0.50]:53215 "EHLO eng.infointeractive.com") by mail.infointeractive.com with ESMTP id S770539AbWAZQn0 (ORCPT ); Thu, 26 Jan 2006 12:43:26 -0400 Received: from localhost (user: 'benoit', uid#6008) by eng.infointeractive.com id <214820-8235>; Thu, 26 Jan 2006 12:42:59 -0400 Date: Thu, 26 Jan 2006 12:42:59 -0400 From: David Benoit To: Steve Langstaff Subject: Re: [Sip] Providing Delayed Call Information Message-ID: <20060126164259.GE20718@infointeractive.com> References: <592CA2F7E2BFBD4088AC87ECFF34BECE1F3C55@not01-mxc01.citel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE1F3C55@not01-mxc01.citel.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 On Thu, Jan 26, 2006 at 04:16:39PM -0000, Steve Langstaff wrote: > I know you say that you are not willing to hold back the INVITE, but 100ms is not > really a long time (assuming the calls are generated by people hitting keys)! My problem is that sometimes what might be responding might be an automated system. It may also be just one piece of a chain of systems that are working together to provide a service; 100ms is a long time when you are talking latency. So, in short, we can't wait. 100ms is a LONG time; we can serve about 2000 other things in that time, and the more things I can do in parallel the better. > Here's a nasty workround... SIP's T1 timer is 5 times this at 500ms, so you could probably > just trigger off whatever lookups you want to and drop the initial INVITE. 500ms later > you will get another INVITE through and you can use your (cached) lookup results to rewrite > the calling information. Most of the time the systems I'm talking to get the initial trying back to me in about 2ms. Waiting an additional 498ms to move to the next step of processing is not an option. Relying on the resends should _only_ be used to deal with failures i.e. packet loss, which on "good" networks doesn't really happen. The entire crux of my problem is that I don't want to wait. I want to provide updated information to the callee about the caller. Even the POTS does this type of thing out to your phone... it sends the initial voltage to make your phone ring and then sends the calling information in the WINK... Surely we should be able to this within SIP. Here is another example of why I would want this. Perhaps the "system" I consult is actually the caller. Sometimes we ask the caller if they would like to provide calling information. For example, based on the preferences of the called party we may ask the caller if they want to "lift" their privacy (if the callee doesn't accept calls from unknown parties). That's a LOT of latency. And again, the act of providing this information doesn't constitute a new call, but simply changes some of the attributes of an existing call. If all else fails, I would be willing to work on a draft of how to support this type of update. David > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > David Benoit > Sent: 26 January 2006 15:41 > To: sip@ietf.org > Subject: [Sip] Providing Delayed Call Information > > > Cross posting this as it may be more applicable here. > > ----- Forwarded message from David Benoit ----- > > Date: Tue, 24 Jan 2006 16:49:00 -0400 > From: David Benoit > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Providing Delayed Call Information > > Hi, > > I want to solve the following problem. A large number of the calls that > we get from our providers have all the calling information present > (i.e. the name of the caller, or CNAM if you wish), but some of the calls > don't have that present. We have several alternative sources for calling > name information that we consult to populate that name (caches, databases, > etc.) but that lookup can take "time" (not a long time, but not > instantaneous). > > The problem is, I don't want to hold back the INVITE until I get that > information back; it could take like 100ms or so depending on the source > and I am not willing to wait. I want to send out the INVITE to the UAC > and when the calling name information has been determined, send that to > update the information that was in the INVITE. As an example, for any of > you Q.931/850 types out there, it would be the same as getting the Setup > message without a calling name and getting a Facility message sometime > later on with that name. > > I initially thought that the UPDATE method was what I wanted, but after > actually reading the RFC, it's not at all what I want. I then thought > that I wanted an INVITE/Replaces, but that seems to me like using a > sledgehammer to hang a picture :) and I'm not really sure it would have > the desired effect. > > So, I need to know if this is already "handled" in SIP. I can't find > anything that suggests how to do this and even though I could add support > in our systems for a custom method that would allow this, I would rather > not if the problem has already been solved. > > Suggestions? Thanks in advance! > > David > -- > David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 > "Complex problems have simple, neat and wrong solutions" - H. L. Menken > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ----- End forwarded message ----- > > _______________________________________________ > 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 -- David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ 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 26 12:07:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Ab3-0002YP-EA; Thu, 26 Jan 2006 12:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Ab1-0002Y5-3r for sip@megatron.ietf.org; Thu, 26 Jan 2006 12:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05011 for ; Thu, 26 Jan 2006 12:06:10 -0500 (EST) Received: from mail.infointeractive.com ([207.231.225.15] helo=smtp.infointeractive.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Aky-0004Qu-GU for sip@ietf.org; Thu, 26 Jan 2006 12:18:03 -0500 Received: from eng.infointeractive.com ([10.142.0.50]:55734 "EHLO eng.infointeractive.com") by mail.infointeractive.com with ESMTP id S789298AbWAZRH1 (ORCPT ); Thu, 26 Jan 2006 13:07:27 -0400 Received: from localhost (user: 'benoit', uid#6008) by eng.infointeractive.com id <214820-8233>; Thu, 26 Jan 2006 13:07:08 -0400 Date: Thu, 26 Jan 2006 13:07:07 -0400 From: David Benoit To: Steve Langstaff Subject: Re: [Sip] Providing Delayed Call Information Message-ID: <20060126170707.GF20718@infointeractive.com> References: <592CA2F7E2BFBD4088AC87ECFF34BECE1F3C56@not01-mxc01.citel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE1F3C56@not01-mxc01.citel.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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 On Thu, Jan 26, 2006 at 04:53:11PM -0000, Steve Langstaff wrote: > Fair enough (you have your reasons :) but maybe I expressed myself > unclearly. > > I was proposing that you don't hang round waiting for the response to > your queries doing nothing else, but that this could be part of a parallel > process (i.e. you could have thousands of such requests outstanding. > > So, yes, the latency would be say 100ms, but it would not increase for > each INVITE in such a state. Certainly we would parallelize the requests and have, like you say, thousands of these outstanding. That is the current approach, and it works. I just don't like it. I would rather have a system that can provide updates. We can provide updates to the media, why not the caller info? > Oh, and the act of providing this information might constitute a new > call, if I've already (automatically?) rejected an anonymous call. Agreed, it might. However, the large majority of such interactions happen with a real person and not with an automated system. I guess the answer I'm getting in that this type of thing is not really handled, and the details of any method of providing such updates would have to be explored. On Thu, Jan 26, 2006 at 05:01:28PM -0000, Steve Langstaff wrote: > Another (less yucky) approach might be to send a re-INVITE once you have > the calling information buT: > > *) you are maybe not guaranteed that the called device will render the > new information to the user. > *) you might have to wait for the initial INVITE/OK/ACK to complete > before you can send s re-INVITE. > *) the called device might already have cleared the call. > > Is the device doing this lookup a proxy or B2BUA? It sounds like it's > going to have to track the state of the calls in progress. It's a B2BUA. In terms of using a re-INVITE, I want to present the updated information _before_ the call is answered, so that's a no go. That's also why I had initially looked into using the UPDATE method, but, sadly, that doesn't seem to be able to affect anything but the media parameters. Any chance UPDATE could be updated to do so? David > > -----Original Message----- > From: benoit@infointeractive.com [mailto:benoit@infointeractive.com] > Sent: 26 January 2006 16:43 > To: Steve Langstaff > Cc: sip@ietf.org > Subject: Re: [Sip] Providing Delayed Call Information > > > On Thu, Jan 26, 2006 at 04:16:39PM -0000, Steve Langstaff wrote: > > I know you say that you are not willing to hold back the INVITE, but 100ms is not > > really a long time (assuming the calls are generated by people hitting keys)! > > My problem is that sometimes what might be responding might be an > automated system. It may also be just one piece of a chain of systems > that are working together to provide a service; 100ms is a long time when > you are talking latency. So, in short, we can't wait. 100ms is a LONG > time; we can serve about 2000 other things in that time, and the more > things I can do in parallel the better. > > > Here's a nasty workround... SIP's T1 timer is 5 times this at 500ms, so you could probably > > just trigger off whatever lookups you want to and drop the initial INVITE. 500ms later > > you will get another INVITE through and you can use your (cached) lookup results to rewrite > > the calling information. > > Most of the time the systems I'm talking to get the initial trying back to > me in about 2ms. Waiting an additional 498ms to move to the next step of > processing is not an option. Relying on the resends should _only_ be used > to deal with failures i.e. packet loss, which on "good" networks doesn't > really happen. > > The entire crux of my problem is that I don't want to wait. I want to > provide updated information to the callee about the caller. Even the POTS > does this type of thing out to your phone... it sends the initial voltage > to make your phone ring and then sends the calling information in the > WINK... Surely we should be able to this within SIP. > > Here is another example of why I would want this. Perhaps the "system" I > consult is actually the caller. Sometimes we ask the caller if they would > like to provide calling information. For example, based on the > preferences of the called party we may ask the caller if they want to > "lift" their privacy (if the callee doesn't accept calls from unknown > parties). That's a LOT of latency. And again, the act of providing this > information doesn't constitute a new call, but simply changes some of the > attributes of an existing call. > > If all else fails, I would be willing to work on a draft of how to support > this type of update. > > David > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > David Benoit > > Sent: 26 January 2006 15:41 > > To: sip@ietf.org > > Subject: [Sip] Providing Delayed Call Information > > > > > > Cross posting this as it may be more applicable here. > > > > ----- Forwarded message from David Benoit ----- > > > > Date: Tue, 24 Jan 2006 16:49:00 -0400 > > From: David Benoit > > To: sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] Providing Delayed Call Information > > > > Hi, > > > > I want to solve the following problem. A large number of the calls that > > we get from our providers have all the calling information present > > (i.e. the name of the caller, or CNAM if you wish), but some of the calls > > don't have that present. We have several alternative sources for calling > > name information that we consult to populate that name (caches, databases, > > etc.) but that lookup can take "time" (not a long time, but not > > instantaneous). > > > > The problem is, I don't want to hold back the INVITE until I get that > > information back; it could take like 100ms or so depending on the source > > and I am not willing to wait. I want to send out the INVITE to the UAC > > and when the calling name information has been determined, send that to > > update the information that was in the INVITE. As an example, for any of > > you Q.931/850 types out there, it would be the same as getting the Setup > > message without a calling name and getting a Facility message sometime > > later on with that name. > > > > I initially thought that the UPDATE method was what I wanted, but after > > actually reading the RFC, it's not at all what I want. I then thought > > that I wanted an INVITE/Replaces, but that seems to me like using a > > sledgehammer to hang a picture :) and I'm not really sure it would have > > the desired effect. > > > > So, I need to know if this is already "handled" in SIP. I can't find > > anything that suggests how to do this and even though I could add support > > in our systems for a custom method that would allow this, I would rather > > not if the problem has already been solved. > > > > Suggestions? Thanks in advance! > > > > David > > -- > > David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 > > "Complex problems have simple, neat and wrong solutions" - H. L. Menken > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ----- End forwarded message ----- > > > > _______________________________________________ > > 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 > > -- > David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 > "Complex problems have simple, neat and wrong solutions" - H. L. Menken -- David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ 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 26 12:43:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2B9Q-0003iF-51; Thu, 26 Jan 2006 12:43:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2B9M-0003gx-6J for sip@megatron.ietf.org; Thu, 26 Jan 2006 12:43:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08016 for ; Thu, 26 Jan 2006 12:41:37 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BBW-0005ye-KJ for sip@ietf.org; Thu, 26 Jan 2006 12:45:27 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2006 09:34:56 -0800 X-IronPort-AV: i="4.01,221,1136188800"; d="scan'208"; a="1770442563:sNHT36426876" 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 k0QHYuQJ026729; Thu, 26 Jan 2006 09:34:56 -0800 (PST) Received: from 10.21.145.12 ([10.21.145.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Jan 2006 17:34:56 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 26 Jan 2006 09:35:11 -0800 Subject: Re: [Sip] Providing Delayed Call Information From: Cullen Jennings To: David Benoit , Steve Langstaff Message-ID: Thread-Topic: [Sip] Providing Delayed Call Information Thread-Index: AcYintuIGhxlRo6SEdqoFQARJEEJ/A== In-Reply-To: <20060126170707.GF20718@infointeractive.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 There has been discussion on changing UPDATE to be able to modify some of the non dialog forming information, or at least making UPDATE clearer about what it means if various bits of information changing from the INVITE to the UPDATE. I hope this work does happen, however, I don't think this would solve your problem... It sounds like you have a problem where you are trying to modify the From information before the the dialog is formed and UPDATE won't work in that case. I also doubt that adding 100 ms to the post dial delay time will really matter. Consider if your SIP device that is doing this lookup for the CNAM was instead doing a DNS look up to resolve the host it was going to send to. The DNS lookup could take way more than 100 ms. Your SIP server would not stop doing the 2000 other things while this lookup happened - it would keep doing them and wait for the response from the lookup then continue with the processing. SIP servers do this all the time and it seem to work fine. Cullen On 1/26/06 9:07 AM, "David Benoit" wrote: > On Thu, Jan 26, 2006 at 04:53:11PM -0000, Steve Langstaff wrote: >> Fair enough (you have your reasons :) but maybe I expressed myself >> unclearly. >> >> I was proposing that you don't hang round waiting for the response to >> your queries doing nothing else, but that this could be part of a parallel >> process (i.e. you could have thousands of such requests outstanding. >> >> So, yes, the latency would be say 100ms, but it would not increase for >> each INVITE in such a state. > > Certainly we would parallelize the requests and have, like you say, > thousands of these outstanding. That is the current approach, and it > works. I just don't like it. I would rather have a system that can > provide updates. We can provide updates to the media, why not the caller > info? > >> Oh, and the act of providing this information might constitute a new >> call, if I've already (automatically?) rejected an anonymous call. > > Agreed, it might. However, the large majority of such interactions happen > with a real person and not with an automated system. > > I guess the answer I'm getting in that this type of thing is not really > handled, and the details of any method of providing such updates would > have to be explored. > > On Thu, Jan 26, 2006 at 05:01:28PM -0000, Steve Langstaff wrote: >> Another (less yucky) approach might be to send a re-INVITE once you have >> the calling information buT: >> >> *) you are maybe not guaranteed that the called device will render the >> new information to the user. >> *) you might have to wait for the initial INVITE/OK/ACK to complete >> before you can send s re-INVITE. >> *) the called device might already have cleared the call. >> >> Is the device doing this lookup a proxy or B2BUA? It sounds like it's >> going to have to track the state of the calls in progress. > > It's a B2BUA. In terms of using a re-INVITE, I want to present the > updated information _before_ the call is answered, so that's a no go. > That's also why I had initially looked into using the UPDATE method, but, > sadly, that doesn't seem to be able to affect anything but the media > parameters. > > Any chance UPDATE could be updated to do so? > > David > >> >> -----Original Message----- >> From: benoit@infointeractive.com [mailto:benoit@infointeractive.com] >> Sent: 26 January 2006 16:43 >> To: Steve Langstaff >> Cc: sip@ietf.org >> Subject: Re: [Sip] Providing Delayed Call Information >> >> >> On Thu, Jan 26, 2006 at 04:16:39PM -0000, Steve Langstaff wrote: >>> I know you say that you are not willing to hold back the INVITE, but 100ms >>> is not >>> really a long time (assuming the calls are generated by people hitting >>> keys)! >> >> My problem is that sometimes what might be responding might be an >> automated system. It may also be just one piece of a chain of systems >> that are working together to provide a service; 100ms is a long time when >> you are talking latency. So, in short, we can't wait. 100ms is a LONG >> time; we can serve about 2000 other things in that time, and the more >> things I can do in parallel the better. >> >>> Here's a nasty workround... SIP's T1 timer is 5 times this at 500ms, so you >>> could probably >>> just trigger off whatever lookups you want to and drop the initial INVITE. >>> 500ms later >>> you will get another INVITE through and you can use your (cached) lookup >>> results to rewrite >>> the calling information. >> >> Most of the time the systems I'm talking to get the initial trying back to >> me in about 2ms. Waiting an additional 498ms to move to the next step of >> processing is not an option. Relying on the resends should _only_ be used >> to deal with failures i.e. packet loss, which on "good" networks doesn't >> really happen. >> >> The entire crux of my problem is that I don't want to wait. I want to >> provide updated information to the callee about the caller. Even the POTS >> does this type of thing out to your phone... it sends the initial voltage >> to make your phone ring and then sends the calling information in the >> WINK... Surely we should be able to this within SIP. >> >> Here is another example of why I would want this. Perhaps the "system" I >> consult is actually the caller. Sometimes we ask the caller if they would >> like to provide calling information. For example, based on the >> preferences of the called party we may ask the caller if they want to >> "lift" their privacy (if the callee doesn't accept calls from unknown >> parties). That's a LOT of latency. And again, the act of providing this >> information doesn't constitute a new call, but simply changes some of the >> attributes of an existing call. >> >> If all else fails, I would be willing to work on a draft of how to support >> this type of update. >> >> David >> >>> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>> David Benoit >>> Sent: 26 January 2006 15:41 >>> To: sip@ietf.org >>> Subject: [Sip] Providing Delayed Call Information >>> >>> >>> Cross posting this as it may be more applicable here. >>> >>> ----- Forwarded message from David Benoit ----- >>> >>> Date: Tue, 24 Jan 2006 16:49:00 -0400 >>> From: David Benoit >>> To: sip-implementors@cs.columbia.edu >>> Subject: [Sip-implementors] Providing Delayed Call Information >>> >>> Hi, >>> >>> I want to solve the following problem. A large number of the calls that >>> we get from our providers have all the calling information present >>> (i.e. the name of the caller, or CNAM if you wish), but some of the calls >>> don't have that present. We have several alternative sources for calling >>> name information that we consult to populate that name (caches, databases, >>> etc.) but that lookup can take "time" (not a long time, but not >>> instantaneous). >>> >>> The problem is, I don't want to hold back the INVITE until I get that >>> information back; it could take like 100ms or so depending on the source >>> and I am not willing to wait. I want to send out the INVITE to the UAC >>> and when the calling name information has been determined, send that to >>> update the information that was in the INVITE. As an example, for any of >>> you Q.931/850 types out there, it would be the same as getting the Setup >>> message without a calling name and getting a Facility message sometime >>> later on with that name. >>> >>> I initially thought that the UPDATE method was what I wanted, but after >>> actually reading the RFC, it's not at all what I want. I then thought >>> that I wanted an INVITE/Replaces, but that seems to me like using a >>> sledgehammer to hang a picture :) and I'm not really sure it would have >>> the desired effect. >>> >>> So, I need to know if this is already "handled" in SIP. I can't find >>> anything that suggests how to do this and even though I could add support >>> in our systems for a custom method that would allow this, I would rather >>> not if the problem has already been solved. >>> >>> Suggestions? Thanks in advance! >>> >>> David >>> -- >>> David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 >>> "Complex problems have simple, neat and wrong solutions" - H. L. Menken >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@cs.columbia.edu >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >>> ----- End forwarded message ----- >>> >>> _______________________________________________ >>> 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 >> >> -- >> David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 >> "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ 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 26 12:48:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BEK-0004oH-7F; Thu, 26 Jan 2006 12:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BEH-0004n3-Fd for sip@megatron.ietf.org; Thu, 26 Jan 2006 12:48:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08977 for ; Thu, 26 Jan 2006 12:46:43 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BOG-0007MK-5S for sip@ietf.org; Thu, 26 Jan 2006 12:58:37 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k0QHldGs092652; Thu, 26 Jan 2006 12:47:43 -0500 (EST) From: "Brett Tate" To: "'David Benoit'" Subject: RE: [Sip] Providing Delayed Call Information Date: Thu, 26 Jan 2006 12:48:25 -0500 Message-ID: <000601c622a0$b88a2210$2c28a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <20060126170707.GF20718@infointeractive.com> X-PMX-IsInternal: True X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 > It's a B2BUA. In terms of using a re-INVITE, I want to > present the updated information _before_ the call is > answered, so that's a no go. That's also why I had initially > looked into using the UPDATE method, but, sadly, that doesn't > seem to be able to affect anything but the media parameters. > > Any chance UPDATE could be updated to do so? UPDATE can basically update everything that a re-INVITE can. However if I recall correctly, some on the sip list view the concepts of updating identities and retargeting as evil. The topic was discussed within the following thread. http://130.230.52.14/list-archive/sip/msg07664.html _______________________________________________ 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 26 13:18:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bhi-0002jB-0p; Thu, 26 Jan 2006 13:18:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bhf-0002i6-C1 for sip@megatron.ietf.org; Thu, 26 Jan 2006 13:18:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11865 for ; Thu, 26 Jan 2006 13:17:08 -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.43) id 1F2Brd-0000B1-Oi for sip@ietf.org; Thu, 26 Jan 2006 13:28:59 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2006 10:18:26 -0800 X-IronPort-AV: i="4.01,221,1136188800"; d="scan'208"; a="396854043:sNHT32271680" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0QIIPWH005150; Thu, 26 Jan 2006 10:18:26 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 10:18:26 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 10:18:25 -0800 Message-Id: <4.3.2.7.2.20060126121511.03e125d8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jan 2006 12:18:24 -0600 To: "Brett Tate" , "'David Benoit'" From: "James M. Polk" Subject: RE: [Sip] Providing Delayed Call Information In-Reply-To: <000601c622a0$b88a2210$2c28a8c0@brett1> References: <20060126170707.GF20718@infointeractive.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jan 2006 18:18:25.0649 (UTC) FILETIME=[E610F610:01C622A4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 At 12:48 PM 1/26/2006 -0500, Brett Tate wrote: > > It's a B2BUA. In terms of using a re-INVITE, I want to > > present the updated information _before_ the call is > > answered, so that's a no go. That's also why I had initially > > looked into using the UPDATE method, but, sadly, that doesn't > > seem to be able to affect anything but the media parameters. > > > > Any chance UPDATE could be updated to do so? > >UPDATE can basically update everything that a re-INVITE can. But that list is the Call-ID To From (and tag) CSeq and this "problem" seems to want to modify the From (and From tag) fields, which makes UPDATE and reINVITE each a non-starter. >However if I >recall correctly, some on the sip list view the concepts of updating >identities and retargeting as evil. > >The topic was discussed within the following thread. > >http://130.230.52.14/list-archive/sip/msg07664.html > > > > >_______________________________________________ >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 26 13:49:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CBw-0006Se-Qy; Thu, 26 Jan 2006 13:49:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CBv-0006SU-DA for sip@megatron.ietf.org; Thu, 26 Jan 2006 13:49:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15033 for ; Thu, 26 Jan 2006 13:48:23 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2CLu-0001Rx-1d for sip@ietf.org; Thu, 26 Jan 2006 14:00:16 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k0QInb4Q098405; Thu, 26 Jan 2006 13:49:46 -0500 (EST) From: "Brett Tate" To: "'James M. Polk'" , "'David Benoit'" Subject: RE: [Sip] Providing Delayed Call Information Date: Thu, 26 Jan 2006 13:50:23 -0500 Message-ID: <000b01c622a9$6392f2b0$2c28a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <4.3.2.7.2.20060126121511.03e125d8@email.cisco.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 > But that list is the >=20 > Call-ID > To > From (and tag) > CSeq >=20 > and this "problem" seems to want to modify the=20 > From (and From tag) fields, which makes UPDATE=20 > and reINVITE each a non-starter. I agree that no RFC has yet obsoleted the RFC 3261 backward = compatibility requirement concerning changing To and From URIs. And I do not recall = if RFC 3261 has the same requirement concerning the display name of the To = and From. If the devices support the various identity extensions (or changing = display names is valid), using UPDATE might solve the problem. Per RFC 3891 section 4, INVITE with Replaces MUST NOT be sent to replace = an early dialog unless the receiver originated the dialog to be replaced. = It indicates forking as the reason. Thus the "sledgehammer" approach which = was mentioned is also not currently valid (unless the restriction is removed = by another RFC). _______________________________________________ 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 26 13:54:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CGo-0000tL-4V; Thu, 26 Jan 2006 13:54:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CGl-0000sc-Te for sip@megatron.ietf.org; Thu, 26 Jan 2006 13:54:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15595 for ; Thu, 26 Jan 2006 13:53:24 -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.43) id 1F2CQl-0001gW-7b for sip@ietf.org; Thu, 26 Jan 2006 14:05:16 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2006 10:54:45 -0800 X-IronPort-AV: i="4.01,221,1136188800"; d="scan'208"; a="396866708:sNHT33077634" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0QIsfk1015868; Thu, 26 Jan 2006 10:54:44 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 13:54:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Providing Delayed Call Information Date: Thu, 26 Jan 2006 13:54:42 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301031977@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Providing Delayed Call Information Thread-Index: AcYiqXboJKzMYNOARsuwDBd0Zcom/wAAFqEg From: "Michael Hammer \(mhammer\)" To: "Brett Tate" , "James Polk \(jmpolk\)" , "David Benoit" X-OriginalArrivalTime: 26 Jan 2006 18:54:43.0476 (UTC) FILETIME=[F826FD40:01C622A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 But if the issue is providing information in "trusted" headers, isn't the From a non-starter? Wouldn't SASL or some P-header approach be the focus of attention? Mike =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Brett Tate > Sent: Thursday, January 26, 2006 1:50 PM > To: James Polk (jmpolk); 'David Benoit' > Cc: sip@ietf.org > Subject: RE: [Sip] Providing Delayed Call Information >=20 > > But that list is the > >=20 > > Call-ID > > To > > From (and tag) > > CSeq > >=20 > > and this "problem" seems to want to modify the From (and From tag)=20 > > fields, which makes UPDATE and reINVITE each a non-starter. >=20 > I agree that no RFC has yet obsoleted the RFC 3261 backward=20 > compatibility requirement concerning changing To and From=20 > URIs. And I do not recall if RFC 3261 has the same=20 > requirement concerning the display name of the To and From. >=20 > If the devices support the various identity extensions (or=20 > changing display names is valid), using UPDATE might solve=20 > the problem. >=20 > Per RFC 3891 section 4, INVITE with Replaces MUST NOT be sent=20 > to replace an early dialog unless the receiver originated the=20 > dialog to be replaced. It indicates forking as the reason. =20 > Thus the "sledgehammer" approach which was mentioned is also=20 > not currently valid (unless the restriction is removed by=20 > another RFC). >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 Thu Jan 26 14:13:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CYi-0000Rj-K1; Thu, 26 Jan 2006 14:13:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CYg-0000QW-T7 for sip@megatron.ietf.org; Thu, 26 Jan 2006 14:13:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16994 for ; Thu, 26 Jan 2006 14:11:55 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Cig-0002Lf-AK for sip@ietf.org; Thu, 26 Jan 2006 14:23:47 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2006 11:13:15 -0800 X-IronPort-AV: i="4.01,221,1136188800"; d="scan'208"; a="1770489257:sNHT33537628" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0QJDEWF020259; Thu, 26 Jan 2006 11:13:14 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 11:13:14 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.124]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 11:13:13 -0800 Message-Id: <4.3.2.7.2.20060126131231.032ece10@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jan 2006 13:13:12 -0600 To: "Michael Hammer \(mhammer\)" , "Brett Tate" , "David Benoit" From: "James M. Polk" Subject: RE: [Sip] Providing Delayed Call Information In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301031977@xmb-rtp-20b.amer. cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jan 2006 19:13:13.0597 (UTC) FILETIME=[8DD602D0:01C622AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 At 10:54 AM 1/26/2006 -0800, Michael Hammer \(mhammer\) wrote: >But if the issue is providing information in "trusted" headers, isn't >the From a non-starter? > >Wouldn't SASL or some P-header approach be the focus of attention? Are you suggesting an assertion after the initial INVITE? This is an interesting thought on the surface >Mike > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Brett Tate > > Sent: Thursday, January 26, 2006 1:50 PM > > To: James Polk (jmpolk); 'David Benoit' > > Cc: sip@ietf.org > > Subject: RE: [Sip] Providing Delayed Call Information > > > > > But that list is the > > > > > > Call-ID > > > To > > > From (and tag) > > > CSeq > > > > > > and this "problem" seems to want to modify the From (and From tag) > > > fields, which makes UPDATE and reINVITE each a non-starter. > > > > I agree that no RFC has yet obsoleted the RFC 3261 backward > > compatibility requirement concerning changing To and From > > URIs. And I do not recall if RFC 3261 has the same > > requirement concerning the display name of the To and From. > > > > If the devices support the various identity extensions (or > > changing display names is valid), using UPDATE might solve > > the problem. > > > > Per RFC 3891 section 4, INVITE with Replaces MUST NOT be sent > > to replace an early dialog unless the receiver originated the > > dialog to be replaced. It indicates forking as the reason. > > Thus the "sledgehammer" approach which was mentioned is also > > not currently valid (unless the restriction is removed by > > another RFC). > > > > > > > > _______________________________________________ > > 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 26 14:27:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Cls-0005oJ-77; Thu, 26 Jan 2006 14:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Cln-0005oE-S5 for sip@megatron.ietf.org; Thu, 26 Jan 2006 14:27:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18255 for ; Thu, 26 Jan 2006 14:25:28 -0500 (EST) Message-Id: <200601261925.OAA18255@ietf.org> Received: from smtp107.biz.mail.mud.yahoo.com ([68.142.200.255]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2Cvn-0002rL-DH for sip@ietf.org; Thu, 26 Jan 2006 14:37:21 -0500 Received: (qmail 71544 invoked from network); 26 Jan 2006 19:26:38 -0000 Received: from unknown (HELO KASTURI) (knarayan@sipera.com@69.15.249.65 with login) by smtp107.biz.mail.mud.yahoo.com with SMTP; 26 Jan 2006 19:26:38 -0000 From: "Kasturi Narayanan" To: "'David Benoit'" , Subject: RE: [Sip] Providing Delayed Call Information Date: Thu, 26 Jan 2006 13:26:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <20060126154123.GA20821@infointeractive.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYij3qlbUnQyn/YTvC931xh5o9YogAHZhWg X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: 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 David, If the intention is to provide the identity (name) to the called party, so that it can be used to take a decision whether to answer the call or not etc then it needs to be included in the Invite message. And BTW in the Traditional PSTN world the called party is not alerted until the caller-id info (name) is fetched from the LIDB database. So withholding an Invite and launching a Query to get the name is not a Bad idea. At the same time the caller can be returned a 100 trying or a provisional response equilvalent to Call-Proceeding (without SDP even when PRACK is enabled and Invite is received w/o SDP ). This way the UAC can be satisfied not to Retransmit and at the same time if the UAC also can be enabled to play a local call-setup tone to satisfy the caller's ear. Kasturi -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of David Benoit Sent: Thursday, January 26, 2006 9:41 AM To: sip@ietf.org Subject: [Sip] Providing Delayed Call Information Cross posting this as it may be more applicable here. ----- Forwarded message from David Benoit ----- Date: Tue, 24 Jan 2006 16:49:00 -0400 From: David Benoit To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Providing Delayed Call Information Hi, I want to solve the following problem. A large number of the calls that we get from our providers have all the calling information present (i.e. the name of the caller, or CNAM if you wish), but some of the calls don't have that present. We have several alternative sources for calling name information that we consult to populate that name (caches, databases, etc.) but that lookup can take "time" (not a long time, but not instantaneous). The problem is, I don't want to hold back the INVITE until I get that information back; it could take like 100ms or so depending on the source and I am not willing to wait. I want to send out the INVITE to the UAC and when the calling name information has been determined, send that to update the information that was in the INVITE. As an example, for any of you Q.931/850 types out there, it would be the same as getting the Setup message without a calling name and getting a Facility message sometime later on with that name. I initially thought that the UPDATE method was what I wanted, but after actually reading the RFC, it's not at all what I want. I then thought that I wanted an INVITE/Replaces, but that seems to me like using a sledgehammer to hang a picture :) and I'm not really sure it would have the desired effect. So, I need to know if this is already "handled" in SIP. I can't find anything that suggests how to do this and even though I could add support in our systems for a custom method that would allow this, I would rather not if the problem has already been solved. Suggestions? Thanks in advance! David -- David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ----- End forwarded message ----- _______________________________________________ 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 27 03:38:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2P7q-0000x2-Vy; Fri, 27 Jan 2006 03:38:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2P7o-0000vj-GU for sip@megatron.ietf.org; Fri, 27 Jan 2006 03:38:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18652 for ; Fri, 27 Jan 2006 03:37:00 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2PHv-0005V1-57 for sip@ietf.org; Fri, 27 Jan 2006 03:49:00 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0R8XWcw017731 for ; Fri, 27 Jan 2006 10:33:35 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 10:38:23 +0200 Received: from [172.21.38.209] ([172.21.38.209]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 27 Jan 2006 10:38:24 +0200 Message-ID: <43D9DBFE.4060904@nokia.com> Date: Fri, 27 Jan 2006 10:38:22 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2006 08:38:24.0069 (UTC) FILETIME=[091F0750:01C6231D] X-Spam-Score: 2.1 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Sip] New draft about etags in subscribe/notify 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 Hi All, I just submitted a new draft defining extensions to SIP events for allowing conditional subscribes: http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-00.txt The issue this attempts to fix were documented in a sipping draft [1], and discussed in IETF 63. My impression of that discussion was moderate interest, so here's the mechanism proposal. Comments are very welcome. Cheers, Aki [1] http://www.softarmor.com/wgdb/docs/draft-niemi-sipping-subnot-issues-00.txt (expired) _______________________________________________ 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 27 08:38:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Tnc-0001JV-7f; Fri, 27 Jan 2006 08:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2TnY-0001Du-Ia for sip@megatron.ietf.org; Fri, 27 Jan 2006 08:37:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08346 for ; Fri, 27 Jan 2006 08:36:24 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Txg-0006t3-GX for sip@ietf.org; Fri, 27 Jan 2006 08:48:26 -0500 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k0RDbfu7016603 for ; Fri, 27 Jan 2006 07:37:42 -0600 (CST) Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Jan 2006 21:37:45 +0800 Received: from [192.11.23.52] ([192.11.23.52]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Jan 2006 21:37:44 +0800 Message-ID: <43DA2225.7040308@lucent.com> Date: Fri, 27 Jan 2006 21:37:41 +0800 From: "Bourne Li" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: X-OriginalArrivalTime: 27 Jan 2006 13:37:44.0683 (UTC) FILETIME=[DA7B3BB0:01C62346] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [Sip] SIPS vs 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: , Content-Type: multipart/mixed; boundary="===============1972525139==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1972525139== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="------------050600090201040000080609" This is a multi-part message in MIME format. --------------050600090201040000080609 Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi All, I have one question regarding to TLS and SIPS. Per RFC 3261, if SIPS URI is used as the R-URI, it indicates all the signaling hop (except the last one to the UAS) must be secured by TLS. I'm doubting if the converse is true. If transport protocol is TLS, does thisimply R-URI and/or topmost route is SIPS? RFC 3263 (locating SIP server) has one requirement: RFC 3263 Section 4.1, 1st paragraph on page 7. First, a client resolving a SIPS URI MUST discard any services that do not contain "SIPS" as the protocol in the service field. *The converse is not true, however. A client resolving a SIP URI SHOULD retain records with "SIPS" as the protocol, if the client supports TLS. * If the client retain the DNS records with "SIPS" even when the input to DNS is SIP URI, it may use the TLS for the transport if the client supports TLS. My question is -- will UE promote the R-URI (or topmost route) from SIP URI to SIPS URI after selecting TLS as the transport protocol. Result of DNS query shall not modify the DNS input (R-URI or topmost URI), but do the promotion or not is not clearly specified in either 3263 and 3261 and client behavior may be different. One potential approach of using SIP URI over TLS is using the security negotiation. RFC 3329. Section 2.4 "security mechanism initiation" specified: If "tls" is chosen, the client uses the procedures of Section 8.1.2 of rfc 3261 to determine the URI to be used as an input to the DNS procedures of rfc3263. However, if the URI is a SIP URI, it MUST treat the scheme as if it were sips, not sip. If the URI scheme is not sip, the request MUST be sent using TLS. The example in section 4.1 shows SIP URI is used after TLS is established as the result of security negotiation. And, RFC 3329 section 2.3.1 specified If a client ends up using TLS to contact the server because it has followed the rules specified in [5], the client MUST NOT use the security agreement procedure of this specification. If a client ends up using non-TLS connections because of the rules in [5], the client MAY use the security agreement of this specification to detect DNS spoofing, or to negotiate some other security than TLS. So, SIPS URI shall not allow security negotiation, and SIP URI may use the TLS after security negotiation. Can we assume that SIP URI not SIPS URI shall be used for security negotiation (even when TLS is selected as the result of negotiation)? And, there is a similar question, will the UE promote the R-URI from SIP to SIPS URI, once TLS is selected. Thanks, Bourne --------------050600090201040000080609 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi All,

I have one question regarding to TLS and SIPS.

Per RFC 3261, if SIPS URI is used as the R-URI, it indicates all the signaling hop (except the last one to the UAS) must be secured by TLS.  I'm doubting if the converse is true. If transport protocol is TLS, does thisimply R-URI and/or topmost route is SIPS?

RFC 3263 (locating SIP server) has one requirement:
    RFC 3263 Section 4.1, 1st paragraph on page 7.
    First, a client resolving a SIPS URI MUST discard any services that
    do not contain "SIPS" as the protocol in the service field.  The
    converse is not true, however.  A client resolving a SIP URI SHOULD
    retain records with "SIPS" as the protocol, if the client supports
    TLS.

If the client retain the DNS records with "SIPS" even when the input to DNS is SIP URI, it may use the TLS for the transport if the client supports TLS. My question is -- will UE promote the R-URI (or topmost route) from SIP URI to SIPS URI after selecting TLS as the transport protocol. Result of DNS query shall not modify the DNS input (R-URI or topmost URI), but do the promotion or not is not clearly specified in either 3263 and 3261 and client behavior may be different.

One potential approach of using SIP URI over TLS is using the security negotiation.

    RFC 3329. Section 2.4 "security mechanism initiation" specified:
    If "tls" is chosen, the client uses the procedures of Section 8.1.2
    of rfc 3261 to determine the URI to be used as an input to the DNS
    procedures of rfc3263.  However, if the URI is a SIP URI, it MUST
    treat the scheme as if it were sips, not sip.  If the URI scheme is
    not sip, the request MUST be sent using TLS.
   
    The example in section 4.1 shows SIP URI is used after TLS is established as the result of security negotiation.
   
   And, RFC 3329 section 2.3.1 specified
   If a client ends up using TLS to contact the server because it has
   followed the rules specified in [5], the client MUST NOT use the
   security agreement procedure of this specification.  If a client ends
   up using non-TLS connections because of the rules in [5], the client
   MAY use the security agreement of this specification to detect DNS
   spoofing, or to negotiate some other security than TLS.

So, SIPS URI shall not allow security negotiation, and SIP URI may use the TLS after security negotiation. Can we assume that SIP URI not SIPS URI shall be used for security negotiation (even when TLS is selected as the result of negotiation)? And, there is a similar question, will the UE promote the R-URI from SIP to SIPS URI, once TLS is selected.

Thanks,
Bourne

 --------------050600090201040000080609-- --===============1972525139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1972525139==-- From sip-bounces@ietf.org Fri Jan 27 10:17:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VLq-0000JW-FH; Fri, 27 Jan 2006 10:17:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VLo-0000JM-Fq for sip@megatron.ietf.org; Fri, 27 Jan 2006 10:17:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18137 for ; Fri, 27 Jan 2006 10:15:51 -0500 (EST) Received: from web34203.mail.mud.yahoo.com ([66.163.178.118]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2VVr-0002dg-3Y for sip@ietf.org; Fri, 27 Jan 2006 10:27:52 -0500 Received: (qmail 19982 invoked by uid 60001); 27 Jan 2006 15:17:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wEVpeHQ+5r4MdYfymNG3hA5DKSMFT8Hs6JVFrtspzVP3kFGN8a3wdZPXX3UB+QKGFG0szAQi5ncH/wMvLUmBAxWM0/DOuD1BPoFNrS0F+wSWTklNOXhPFW+RhX6JStjUOZqPLbGtAoAorAuKQ0pbMejtqhQB2us7Q4VsArhb7Kg= ; Message-ID: <20060127151705.19980.qmail@web34203.mail.mud.yahoo.com> Received: from [201.134.153.34] by web34203.mail.mud.yahoo.com via HTTP; Fri, 27 Jan 2006 07:17:05 PST Date: Fri, 27 Jan 2006 07:17:05 -0800 (PST) From: srinidhi n To: sip@ietf.org, mhammer@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: 8bit Cc: Subject: [Sip] Re: Sip Digest, Vol 21, Issue 21 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 Looks like there is some confusion on this timers. 1. You are right. Timers need not be of the same value on UAS and UAC and need not start at the same time. 2. The discussion was if sending a Re-Invite immediately to ACK was correct. 3. The question as to what would happen if the 'n'th 200 Ok was the one received by the UAC. In this case, till the UAC recevies a 200 Ok , it wont send a ACK and neither an Re-invite.So no problem as this is not the issue we are discussing. So my suggestion was merely that, whenever the UAC recevied a 200 Ok, it would send ACK. Before initating a reinvite if UAC waited for atleast 2*T1 (with T1 being UAC value and started after sending ACK), then atleast 1 200 Ok retransmission would be recevied if UAS never recevied ACK and then the UAC can safely send Re-Invite without worrying about the UAS problems. Hope this clarifies. Thanks, Srinidhi --- sip-request@ietf.org wrote: > Send Sip mailing list submissions to > sip@ietf.org > > To subscribe or unsubscribe via the World Wide Web, > visit > https://www1.ietf.org/mailman/listinfo/sip > or, via email, send a message with subject or body > 'help' to > sip-request@ietf.org > > You can reach the person managing the list at > sip-owner@ietf.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of Sip digest..." > > > Today's Topics: > > 1. Re: Re: Re-Invite before ACK (Benny Prijono) > 2. RE: Re: Re-Invite before ACK (Michael Hammer > (mhammer)) > 3. Question about Forking in a Proxy (Diego B) > 4. Re: Question about Forking in a Proxy (Bob > Penfield) > 5. Providing Delayed Call Information (David > Benoit) > 6. Re: Providing Delayed Call Information (David > Benoit) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Jan 2006 17:01:42 +0000 > From: Benny Prijono > Subject: Re: [Sip] Re: Re-Invite before ACK > To: "Michael Hammer (mhammer)" > Cc: sip@ietf.org, "James Polk \(jmpolk\)" > , srinidhi > n > Message-ID: <43D7AEF6.5020707@bulukucing.org> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > Michael, > > even after your lengthy explanation, I still think > it wouldn't work. > Perhaps it's because I didn't explain it clearly > either. More inline. > > Michael Hammer (mhammer) wrote: > > Thanks. More inline. > > > > You misunderstood the actual suggestion because it > was not clearly laid > > out. The idea was that the UAS is going to > retransmit 200 OK according > > to a Timer G' behavior. Let us call what the UAC > thinks this behavior > > is the Timer G". Assuming T1=500 ms, Timer G' at > UAS will send 200 OK > > at: > > > > Interval: 0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > Times: 0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer > H' fires at T1*64=32 > > sec) > > > > Timer G" at UAC can have identical behavior. > Assume one-way transport > > time is .1 second. > > Interval: 0.0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 > (Timer H' fires at T1*64=32 > > sec) > > > > The problem is, you assumed that timer G" starts in > UAC at the same > time when timer G' starts in UAS. This is not > possible (I think). > Timer G" can only start at UAC when UAC receives the > first 2xx > response. Is this correct, or am I missing something > here? > > If this is correct, then what if the first 2xx > response received by > UAC is actually the n-th retransmission (because n-1 > responses were > lost). In this case, timer G' and G" won't be > synchronized. > > Let me illustrate with a diagram. We'll ignore RTT > time, for > simplification. > > Time UAC UAS > 0.000 lost X <------ 200/OK -- > 0.500 lost X <------ 200/OK -- > 1.500 lost X <------ 200/OK -- > 3.500 <------------------ 200/OK -- > -- ACK -----------> X lost > 7.500 <------------------ 200/OK -- > > At time 3.500, UAC starts timer G". After 2*T1, at > time 4.500, UAC > thinks it's okay to send re-INVITE, because no 200 > retransmission is > received. But this is wrong, since the > retransmission WILL be received > at time 7.500. > > Am I missing something? > > -benny > > > At time 0 the 200 OK is sent. At time 0.1 it is > received at the UAC. > > > > If the ACK is not received the UAS would send > again at time 0.5 and the > > UAC would receive it at time 0.6 > > > > At time 0.6, if a second 200 OK is received, UAC > retransmits the ACK and > > sets Timer G"=1 so that it fires at time 1.6. > > > > At time 1.6, if a third 200 OK is received, UAC > retransmits the ACK and > > sets Timer G"=2 so that it fires at time 3.6 and > so on. > > > > This is the theoretical minimum. The actual > suggestion was to start the > > Timer G" at 2*T1: > > Interval: 0.0, 1.0, 2.0, 4.0, 8.0, 16.0 > > Times: 0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" > fires at T1*64=32 > > sec) > > > > Compare with the Timer G' behavior adjusted with > .1 cross-network > > transmit time. > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 > (Timer H' fires at T1*64=32 > > sec) > > > > Note that the "200 OK expected" times are > increasingly larger than what > > the actual 200 OK receipt times at the UAC should > be. The end-game for > > Timer H" would need to be handled, but you get the > idea now, I hope. > > > > > >>So in general, I think this type of solution will > not work, > >>because there is no way for UAC to know when the > next > >>response will arrive. > > > > > > I would state this the other way. There is no way > for the UAC to know > > that the ACK was received and therefore that a 200 > OK will not be > > forthcoming. The issue still is answering the > question (rather than > > waiting some very long time) when is the earliest > it is reasonable to > > try to send the re-INVITE with high probability of > success? > > > > If you send immediately and get a 491 in return, > this just puts the UAC > > in the same situation of needing to decide when to > retranmit. The ACK > > could be received immediately after the 491 was > sent. So, sending the > > re-INVITE immediately after ACK has only postponed > this decision *IF* > > the network delivery and handling at the UAS is > misordered. > > > > Perhaps a compromise is to wait an RTT before > sending the re-INVITE and > > allow Timer A to take care of the rest. (Note > Timer A will fire quicker > > than Timer G'.) > > > > Mike > > > > > >>Thus for UAC, the only thing that works is to > handle 491 (Request > >>Pending) response when it arrives. > >> > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 27 11:00:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W1y-00049R-BT; Fri, 27 Jan 2006 11:00:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W1x-00049J-4k for sip@megatron.ietf.org; Fri, 27 Jan 2006 11:00:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21777 for ; Fri, 27 Jan 2006 10:59:24 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2WC8-0004KJ-9C for sip@ietf.org; Fri, 27 Jan 2006 11:11:29 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 27 Jan 2006 08:00:48 -0800 X-IronPort-AV: i="4.01,226,1136188800"; d="scan'208"; a="1770811719:sNHT36991106" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0RG0jjv022289; Fri, 27 Jan 2006 08:00:46 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 11:00:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2006 11:00:33 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301031BDF@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Sip Digest, Vol 21, Issue 21 Thread-Index: AcYjVL0O5M57D2ZmSx6fJsbAHoSpxwABAEvQ From: "Michael Hammer \(mhammer\)" To: "srinidhi n" , X-OriginalArrivalTime: 27 Jan 2006 16:00:43.0963 (UTC) FILETIME=[D42178B0:01C6235A] X-Spam-Score: 1.1 (+) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Sip] RE: Sip Digest, Vol 21, Issue 21 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 There is some confusion about what does 2*T1 mean. I think the intent of the language in RFC 3261 was that a given timer would copy the configured value of T1=3D0.5 sec, then timer x variable gets doubled = after each iteration. So, T1 remains a constant, but the timer start value doubles each time. That said, what I think you are saying is that what I called Timer G" exhibits this behavior: Interval: 0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, ... Times: 0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, ... until BYE received or 7 ACKs sent Event [re-]setting timer: receipt of 200 OK and sending of ACK Event upon timer expiry: Send re-INVITE Event disabling timer: 7 ACKs sent or BYE received Does that capture it? Mike > -----Original Message----- > From: srinidhi n [mailto:srinidhi104@yahoo.com]=20 > Sent: Friday, January 27, 2006 10:17 AM > To: sip@ietf.org; Michael Hammer (mhammer) > Subject: Re: Sip Digest, Vol 21, Issue 21 >=20 > Looks like there is some confusion on this timers. >=20 > 1. You are right. Timers need not be of the same value on UAS=20 > and UAC and need not start at the same time. >=20 > 2. The discussion was if sending a Re-Invite immediately to=20 > ACK was correct. >=20 > 3. The question as to what would happen if the 'n'th 200 Ok=20 > was the one received by the UAC. In this case, till the UAC=20 > recevies a 200 Ok , it wont send a ACK and neither an=20 > Re-invite.So no problem as this is not the issue we are discussing. >=20 > So my suggestion was merely that, whenever the UAC recevied a=20 > 200 Ok, it would send ACK. Before initating a reinvite if UAC=20 > waited for atleast 2*T1 (with T1 being UAC value and started=20 > after sending ACK), then atleast 1 200 Ok retransmission=20 > would be recevied if UAS never recevied ACK and then the UAC=20 > can safely send Re-Invite without worrying about the UAS problems. >=20 > Hope this clarifies. >=20 > Thanks, > Srinidhi > --- sip-request@ietf.org wrote: >=20 > > Send Sip mailing list submissions to > > sip@ietf.org > >=20 > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www1.ietf.org/mailman/listinfo/sip > > or, via email, send a message with subject or body 'help' to > > sip-request@ietf.org > >=20 > > You can reach the person managing the list at > > sip-owner@ietf.org > >=20 > > When replying, please edit your Subject line so it is more specific=20 > > than "Re: Contents of Sip digest..." > >=20 > >=20 > > Today's Topics: > >=20 > > 1. Re: Re: Re-Invite before ACK (Benny Prijono) > > 2. RE: Re: Re-Invite before ACK (Michael Hammer > > (mhammer)) > > 3. Question about Forking in a Proxy (Diego B) > > 4. Re: Question about Forking in a Proxy (Bob > > Penfield) > > 5. Providing Delayed Call Information (David > > Benoit) > > 6. Re: Providing Delayed Call Information (David > > Benoit) > >=20 > >=20 > > > ---------------------------------------------------------------------- > >=20 > > Message: 1 > > Date: Wed, 25 Jan 2006 17:01:42 +0000 > > From: Benny Prijono > > Subject: Re: [Sip] Re: Re-Invite before ACK > > To: "Michael Hammer (mhammer)" > > Cc: sip@ietf.org, "James Polk \(jmpolk\)" > > , srinidhi > > n > > Message-ID: <43D7AEF6.5020707@bulukucing.org> > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > >=20 > > Michael, > >=20 > > even after your lengthy explanation, I still think it wouldn't work. > > Perhaps it's because I didn't explain it clearly either.=20 > More inline. > >=20 > > Michael Hammer (mhammer) wrote: > > > Thanks. More inline.=20 > > >=20 > > > You misunderstood the actual suggestion because it > > was not clearly laid > > > out. The idea was that the UAS is going to > > retransmit 200 OK according > > > to a Timer G' behavior. Let us call what the UAC > > thinks this behavior > > > is the Timer G". Assuming T1=3D500 ms, Timer G' at > > UAS will send 200 OK > > > at: > > >=20 > > > Interval: 0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > > Times: 0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer > > H' fires at T1*64=3D32 > > > sec) > > >=20 > > > Timer G" at UAC can have identical behavior.=20 > > Assume one-way transport > > > time is .1 second. > > > Interval: 0.0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 > > (Timer H' fires at T1*64=3D32 > > > sec) > > >=20 > >=20 > > The problem is, you assumed that timer G" starts in UAC at the same=20 > > time when timer G' starts in UAS. This is not possible (I think). > > Timer G" can only start at UAC when UAC receives the first 2xx=20 > > response. Is this correct, or am I missing something here? > >=20 > > If this is correct, then what if the first 2xx response received by=20 > > UAC is actually the n-th retransmission (because n-1 responses were=20 > > lost). In this case, timer G' and G" won't be synchronized. > >=20 > > Let me illustrate with a diagram. We'll ignore RTT time, for=20 > > simplification. > >=20 > > Time UAC UAS > > 0.000 lost X <------ 200/OK -- > > 0.500 lost X <------ 200/OK -- > > 1.500 lost X <------ 200/OK -- > > 3.500 <------------------ 200/OK -- > > -- ACK -----------> X lost > > 7.500 <------------------ 200/OK -- > >=20 > > At time 3.500, UAC starts timer G". After 2*T1, at time 4.500, UAC=20 > > thinks it's okay to send re-INVITE, because no 200=20 > retransmission is=20 > > received. But this is wrong, since the retransmission WILL=20 > be received=20 > > at time 7.500. > >=20 > > Am I missing something? > >=20 > > -benny > >=20 > > > At time 0 the 200 OK is sent. At time 0.1 it is > > received at the UAC. > > >=20 > > > If the ACK is not received the UAS would send > > again at time 0.5 and the > > > UAC would receive it at time 0.6 > > >=20 > > > At time 0.6, if a second 200 OK is received, UAC > > retransmits the ACK and > > > sets Timer G"=3D1 so that it fires at time 1.6. > > >=20 > > > At time 1.6, if a third 200 OK is received, UAC > > retransmits the ACK and > > > sets Timer G"=3D2 so that it fires at time 3.6 and > > so on. =20 > > >=20 > > > This is the theoretical minimum. The actual > > suggestion was to start the > > > Timer G" at 2*T1: > > > Interval: 0.0, 1.0, 2.0, 4.0, 8.0, 16.0 > > > Times: 0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" > > fires at T1*64=3D32 > > > sec) > > >=20 > > > Compare with the Timer G' behavior adjusted with > > .1 cross-network > > > transmit time. > > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 > > (Timer H' fires at T1*64=3D32 > > > sec) > > >=20 > > > Note that the "200 OK expected" times are > > increasingly larger than what > > > the actual 200 OK receipt times at the UAC should > > be. The end-game for > > > Timer H" would need to be handled, but you get the > > idea now, I hope. > > >=20 > > >=20 > > >>So in general, I think this type of solution will > > not work, > > >>because there is no way for UAC to know when the > > next > > >>response will arrive.=20 > > >=20 > > >=20 > > > I would state this the other way. There is no way > > for the UAC to know > > > that the ACK was received and therefore that a 200 > > OK will not be > > > forthcoming. The issue still is answering the > > question (rather than > > > waiting some very long time) when is the earliest > > it is reasonable to > > > try to send the re-INVITE with high probability of > > success? > > >=20 > > > If you send immediately and get a 491 in return, > > this just puts the UAC > > > in the same situation of needing to decide when to > > retranmit. The ACK > > > could be received immediately after the 491 was > > sent. So, sending the > > > re-INVITE immediately after ACK has only postponed > > this decision *IF* > > > the network delivery and handling at the UAS is > > misordered. =20 > > >=20 > > > Perhaps a compromise is to wait an RTT before > > sending the re-INVITE and > > > allow Timer A to take care of the rest. (Note > > Timer A will fire quicker > > > than Timer G'.) > > >=20 > > > Mike > > >=20 > > >=20 > > >>Thus for UAC, the only thing that works is to > > handle 491 (Request > > >>Pending) response when it arrives. > > >> > >=20 > =3D=3D=3D message truncated =3D=3D=3D >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 27 14:32:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ZKj-0007UK-7A; Fri, 27 Jan 2006 14:32:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ZKg-0007Sh-Ce for sip@megatron.ietf.org; Fri, 27 Jan 2006 14:32:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07565 for ; Fri, 27 Jan 2006 14:30:58 -0500 (EST) Received: from 81-178-58-134.dsl.pipex.com ([81.178.58.134] helo=PJPROJECT.NET) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2ZUr-0002fW-GD for sip@ietf.org; Fri, 27 Jan 2006 14:43:04 -0500 Received: from [127.0.0.1] (HP-DESKTOP.home [192.168.0.7]) by PJPROJECT.NET (8.13.4/8.13.4) with ESMTP id k0RJZBAh031520; Fri, 27 Jan 2006 19:35:11 GMT Message-ID: <43DA7531.1010100@bulukucing.org> Date: Fri, 27 Jan 2006 19:32:01 +0000 From: Benny Prijono User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: srinidhi n Subject: Re: [Sip] Re: Sip Digest, Vol 21, Issue 21 References: <20060127151705.19980.qmail@web34203.mail.mud.yahoo.com> In-Reply-To: <20060127151705.19980.qmail@web34203.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0603-0, 15/01/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.1 (+) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a 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 srinidhi n wrote: > So my suggestion was merely that, whenever the UAC > recevied a 200 Ok, it would send ACK. Before initating > a reinvite if UAC waited for atleast 2*T1 (with T1 > being UAC value and started after sending ACK), then > atleast 1 200 Ok retransmission would be recevied if > UAS never recevied ACK and then the UAC can safely > send Re-Invite without worrying about the UAS > problems. > We have discussed that this wouldn't work in all cases, and the example that I've given has proved it. If you care to read my post again carefully, perhaps you'll come to the same conclussion. Or perhaps no, in that case I'll be glad to hear it. -benny > Hope this clarifies. > > Thanks, > Srinidhi > --- sip-request@ietf.org wrote: > > >>Send Sip mailing list submissions to >> sip@ietf.org >> >>To subscribe or unsubscribe via the World Wide Web, >>visit >> https://www1.ietf.org/mailman/listinfo/sip >>or, via email, send a message with subject or body >>'help' to >> sip-request@ietf.org >> >>You can reach the person managing the list at >> sip-owner@ietf.org >> >>When replying, please edit your Subject line so it >>is more specific >>than "Re: Contents of Sip digest..." >> >> >>Today's Topics: >> >> 1. Re: Re: Re-Invite before ACK (Benny Prijono) >> 2. RE: Re: Re-Invite before ACK (Michael Hammer >>(mhammer)) >> 3. Question about Forking in a Proxy (Diego B) >> 4. Re: Question about Forking in a Proxy (Bob >>Penfield) >> 5. Providing Delayed Call Information (David >>Benoit) >> 6. Re: Providing Delayed Call Information (David >>Benoit) >> >> >> > > ---------------------------------------------------------------------- > >>Message: 1 >>Date: Wed, 25 Jan 2006 17:01:42 +0000 >>From: Benny Prijono >>Subject: Re: [Sip] Re: Re-Invite before ACK >>To: "Michael Hammer (mhammer)" >>Cc: sip@ietf.org, "James Polk \(jmpolk\)" >>, srinidhi >> n >>Message-ID: <43D7AEF6.5020707@bulukucing.org> >>Content-Type: text/plain; charset=ISO-8859-1; >>format=flowed >> >>Michael, >> >>even after your lengthy explanation, I still think >>it wouldn't work. >>Perhaps it's because I didn't explain it clearly >>either. More inline. >> >>Michael Hammer (mhammer) wrote: >> >>>Thanks. More inline. >>> >>>You misunderstood the actual suggestion because it >> >>was not clearly laid >> >>>out. The idea was that the UAS is going to >> >>retransmit 200 OK according >> >>>to a Timer G' behavior. Let us call what the UAC >> >>thinks this behavior >> >>>is the Timer G". Assuming T1=500 ms, Timer G' at >> >>UAS will send 200 OK >> >>>at: >>> >>>Interval: 0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 >>>Times: 0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer >> >>H' fires at T1*64=32 >> >>>sec) >>> >>>Timer G" at UAC can have identical behavior. >> >>Assume one-way transport >> >>>time is .1 second. >>>Interval: 0.0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 >>>Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 >> >>(Timer H' fires at T1*64=32 >> >>>sec) >>> >> >>The problem is, you assumed that timer G" starts in >>UAC at the same >>time when timer G' starts in UAS. This is not >>possible (I think). >>Timer G" can only start at UAC when UAC receives the >>first 2xx >>response. Is this correct, or am I missing something >>here? >> >>If this is correct, then what if the first 2xx >>response received by >>UAC is actually the n-th retransmission (because n-1 >>responses were >>lost). In this case, timer G' and G" won't be >>synchronized. >> >>Let me illustrate with a diagram. We'll ignore RTT >>time, for >>simplification. >> >>Time UAC UAS >>0.000 lost X <------ 200/OK -- >>0.500 lost X <------ 200/OK -- >>1.500 lost X <------ 200/OK -- >>3.500 <------------------ 200/OK -- >> -- ACK -----------> X lost >>7.500 <------------------ 200/OK -- >> >>At time 3.500, UAC starts timer G". After 2*T1, at >>time 4.500, UAC >>thinks it's okay to send re-INVITE, because no 200 >>retransmission is >>received. But this is wrong, since the >>retransmission WILL be received >>at time 7.500. >> >>Am I missing something? >> >>-benny >> >> >>>At time 0 the 200 OK is sent. At time 0.1 it is >> >>received at the UAC. >> >>>If the ACK is not received the UAS would send >> >>again at time 0.5 and the >> >>>UAC would receive it at time 0.6 >>> >>>At time 0.6, if a second 200 OK is received, UAC >> >>retransmits the ACK and >> >>>sets Timer G"=1 so that it fires at time 1.6. >>> >>>At time 1.6, if a third 200 OK is received, UAC >> >>retransmits the ACK and >> >>>sets Timer G"=2 so that it fires at time 3.6 and >> >>so on. >> >>>This is the theoretical minimum. The actual >> >>suggestion was to start the >> >>>Timer G" at 2*T1: >>>Interval: 0.0, 1.0, 2.0, 4.0, 8.0, 16.0 >>>Times: 0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" >> >>fires at T1*64=32 >> >>>sec) >>> >>>Compare with the Timer G' behavior adjusted with >> >>.1 cross-network >> >>>transmit time. >>>Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 >> >>(Timer H' fires at T1*64=32 >> >>>sec) >>> >>>Note that the "200 OK expected" times are >> >>increasingly larger than what >> >>>the actual 200 OK receipt times at the UAC should >> >>be. The end-game for >> >>>Timer H" would need to be handled, but you get the >> >>idea now, I hope. >> >>> >>>>So in general, I think this type of solution will >> >>not work, >> >>>>because there is no way for UAC to know when the >> >>next >> >>>>response will arrive. >>> >>> >>>I would state this the other way. There is no way >> >>for the UAC to know >> >>>that the ACK was received and therefore that a 200 >> >>OK will not be >> >>>forthcoming. The issue still is answering the >> >>question (rather than >> >>>waiting some very long time) when is the earliest >> >>it is reasonable to >> >>>try to send the re-INVITE with high probability of >> >>success? >> >>>If you send immediately and get a 491 in return, >> >>this just puts the UAC >> >>>in the same situation of needing to decide when to >> >>retranmit. The ACK >> >>>could be received immediately after the 491 was >> >>sent. So, sending the >> >>>re-INVITE immediately after ACK has only postponed >> >>this decision *IF* >> >>>the network delivery and handling at the UAS is >> >>misordered. >> >>>Perhaps a compromise is to wait an RTT before >> >>sending the re-INVITE and >> >>>allow Timer A to take care of the rest. (Note >> >>Timer A will fire quicker >> >>>than Timer G'.) >>> >>>Mike >>> >>> >>> >>>>Thus for UAC, the only thing that works is to >> >>handle 491 (Request >> >>>>Pending) response when it arrives. >>>> >> > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 29 07:29:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Bgd-00044P-T0; Sun, 29 Jan 2006 07:29:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3BgW-00040q-9P for sip@megatron.ietf.org; Sun, 29 Jan 2006 07:29:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24891 for ; Sun, 29 Jan 2006 07:28:00 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3Bqy-0006Hn-2m for sip@ietf.org; Sun, 29 Jan 2006 07:40:30 -0500 Received: (qmail 15994 invoked from network); 29 Jan 2006 12:28:59 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;c5c3743224d52119bc2a2cac0da95321; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 29 Jan 2006 12:28:59 -0000 Received: (qmail 8462 invoked from network); 29 Jan 2006 12:29:00 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;82349defaafb43a93cbdc2d0f7a93c95; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 29 Jan 2006 12:29:00 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 20:28:59 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sun, 29 Jan 2006 20:28:58 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC6AA9@hcbjdc2> Thread-Topic: One IETF related Workshop informaiton, Thread-Index: AcYkz5M+s6WWFkP8QCORp9rwOWciLw== From: "DENG, HUI -HCHBJ" To: "DENG, HUI -HCHBJ" , X-OriginalArrivalTime: 29 Jan 2006 12:28:59.0847 (UTC) FILETIME=[94B6B570:01C624CF] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1138537740.41-8459-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.06 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1138537739.48-15986-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.02/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: mip6@ietf.org, sip@ietf.org, wuhq@catt.ac.cn, mip4@ietf.org, softwires@ietf.org, jianping@cernet.edu.cn, netlmm@ngnet.it Subject: [Sip] One IETF related Workshop informaiton, 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="===============1646428917==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1646428917== content-class: urn:content-classes:message Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBBbGwNCiANClRvZGF5IGlzIENoaW5hJ3MgbHVuYXIgbmV3IHllYXIgZGF5LCBhbmQgdGhp cyB5ZWFyIHNheXMgIkRvZyIgeWVhci4gQnkgdGFraW5nIHRoaXMgb3Bwb3J0dW5pdHksDQpXZSdk IGxpa2UgdG8gYW5ub3VuY2Ugb25lIHdvcmtzaG9wIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlbGF0 ZWQgdG8gSUVURiBtYWlubHkuDQogDQpBcm91bmQgRmViLiAyNy0yOHRoLCAyMDA2LCBCZWlqaW5n LCBDaGluYSwgQ05HSSBFeHBlcnQgQ29tbWlzc2lvbiB3aWxsIGhvc3QgYSAgc3BlY2lhbCANCndv cmtzaG9wIG9uIE5ldyBUcmVuZCBvZiBOZXh0IEdlbmVyYXRpb24gSW50ZXJuZXQuIFdlIHdlbGNv bWUgYW5kIGludml0ZSAgcmVzZWFyY2hlcnMgDQp3aG8gaXMgaW52b2x2ZWQgaW4gSUVURiwgM0dQ UDIsIElFRUUgcmVsYXRlZCB0byBNSVAsIElQdjYsIFNJUCwgYW5kIEZNQyBldCBhbC4gDQp0byBh dHRlbmQgdGhpcyB3b3Jrc2hvcCBmb3IgZnJlZS4gSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIGF0 dGVuZGluZyB0aGlzIHdvcmtzaG9wLA0KcGxlYXNlIGRvbnQnIGhlc2l0YXRlIHRvIGxldCB1cyBr bm93IGl0Lg0KIA0KVGhlIGZvbGxvd2luZyBsaW5rIGlzIGxhc3QgeWVhciB3b3Jrc2hvcCBpbmZv cm1hdGlvbjoNCmh0dHA6Ly93d3cxLmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlwNi9jdXJy ZW50L21zZzAyMzUzLmh0bWwNCiANCldlIGFyZSBhbHNvIGV4cGVjdGluZyB0aGF0IElFVEYgbWVl dGluZyBjb3VsZCBiZSBoZWxkIGluIENoaW5hIHNvbWVkYXkuDQogDQpIYXBweSBEb2dnaWUsIERv ZywgRG9uZ2xlIFllYXIgdG8gcGVvcGxlIHdobyBpcyBpbnRlcmVzdGVkIGluIENoaW5hJ3MgY3Vs dHVyZS4NCk1hbnkgdGhhbmtzLA0KIA0KUHJvZi4gSGVxdWFuIFd1DQpDaGllZiBTY2llbnRpc3Qs IENoaW5hIE5leHQtR2VuZXJhdGlvbiBJbnRlcm5ldCBFeHBlcnRzIENvbW1pc3Npb24gDQpWaWNl IFByZXNpZGVudCwgQ2hpbmVzZSBBY2FkZW15IG9mIEVuZ2luZWVyaW5nDQogDQpIdWkgRGVuZw0K Q2hhaXIgb2YgT3JnYW5pemluZyBDb21taXR0ZWUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IC0tLS0tLS0tLS0tLS0tLS0tLSANCldvcmtzaG9wIG9uIE5ldyBUcmVuZCBvZiBOZXh0IEdlbmVy YXRpb24gSW50ZXJuZXQNCg0KKDEpIE9yZ2FuaXplcnM6ICBDaGluYSBOZXh0LUdlbmVyYXRpb24g SW50ZXJuZXQgRXhwZXJ0cyBDb21taXNzaW9uDQogICAgICBIb3N0OiAgICAgICAgICBDRVJORVQg Q2VudGVyOiBDaGluYSBFZHVjYXRpb24gYW5kIFJlc2VhcmNoIE5ldHdvcmsgQ2VudGVyDQogICAg ICBTcG9uc29yOiAgICAgSGl0YWNoaSAoQ2hpbmEpIFImRCBDb3Jwb3JhdGlvbi4NCigyKSBEYXRl L1RpbWU6ICAgRmViLiAyN3RoLTI4dGguIE1vbmRheS9UdWVzZGF5LCAyMDA2DQooMykgUGxhY2U6 ICAgICAgICAgIFRzaW5naHVhIFVuaXYuIEZJVCBCdWlsZGluZw0KDQpDb250YWN0IFBlb3BsZToN CiANCiBGYW5nIEx2DQogVGVsOiAoODYpIDEw77yNNjI3OTU4MTjvvI02MzIyDQogRS1tYWlsOiBm YW5nbEBjZXJuZXQuZWR1LmNuDQogDQogWWFvaHVpIEFuDQogVGVsOiAoODYpIDEwLTY4NTIyNjY5 DQogRmF4OiAoODYpIDEwLTY4NTIyNjY5DQogRS1tYWlsOiBheWhAY2FlLmNuDQogDQogSHVpIERF TkcNCiBNb2I6ICg4NikgMTM5MTA3NTAyMDENCiBGYXg6ICg4NikgMTAtNjU5MC04MTc5DQogRS1t YWlsOiBoZGVuZ0BoaXRhY2hpLmNuDQoNCldvcmtzaG9wIFRvcGljczoNCi0gSUVURiBNb2JpbGUg SVAgcmVsYXRlZCAoTUlQdjQsIE1JUDYsIE5FTU8sIE1vYm9wdHMsIE5FVExNTSkuDQotIElFVEYg U0lQIHJlbGF0ZWQgKDNHUFAyIHJlbGF0ZWQpLg0KLSAzR1BQMiBJUCByZWxhdGVkIHRlY2hub2xv Z3kgKE1JUCBhbmQgSU1TKS4NCi0gSUVFRSA4MDIuMTYsMjEgSUVURiByZWxhdGVkDQotIDEwMCBi eSAxMDAgcHJvamVjdCByZWxhdGVkDQotIEdFTkkgcHJvamVjdCByZWxhdGVkDQotIENoaW5hIE1v YmlsZSBPcGVyYXRvcnMgc3RyYXRlZ3kgYW5kIHNvbWUgc29sdXRpb24uIChDaGluYSBNb2JpbGUg YW5kIENoaW5hICBVbmljb20pDQotIENoaW5hIEZpeGVkIE9wZXJhdG9ycyBzdHJhdGVneSBhbmQg c29tZSBzb2x1dGlvbi4gKENoaW5hIFRlbGVjb20gYW5kIENoaW5hICBOZXRjb20pDQotIEZvcmVp Z24gTW9iaWxlIENhcnJpZXIncyBzdHJhdGVneSBmb3IgbmV4dCBnZW5lcmF0aW9uIEludGVybmV0 Lg0KLSBDaGluYSBSZXNlYXJjaCBOZXR3b3JrIFN0cmF0ZWd5IGZvciBuZXh0IGdlbmVyYXRpb24g SW50ZXJuZXQuIChDRVJORVQpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpEcmFmdCBBZ2VuZGEgYnV0IG5vdCB5ZXQgZmluYWxpemVkOg0KIA0K RmViLiAyN3RoDQrvvJxNb3JuaW5nIFNlc3Npb27vvJ7jgIDjgIDjgIDjgIBDaGFpcjogUHJvZi4g SGVxdWFuIFd1IChDaGllZiBTY2llbnRpc3Qgb2YgQ05HSSBFeHBlcnRzIENvbW1pc3Npb24pDQo5 OjAwLTk6MzAgICAgT3BlbmluZyBBZGRyZXNzDQogICAgICAgICAgICAgRHIuIEhlcXVhbiBXdSAg KENoaWVmIFNjaWVudGlzdCBvZiBDTkdJIEV4cGVydHMgQ29tbWlzc2lvbikNCjk6MzAtMTA6MDAg ICBNb2JpbGl0eSBpbiBJUHY0OiBUZWNobm9sb2d5IGFuZCBEZXBsb3ltZW50LCBhbmQgb3RoZXIg bmV3IHRyZW5kcyBvZiBuZXR3b3JrLg0KICAgICAgICAgICAgIE1yLiBIZW5yaWsgTGV2a293ZXR6 IChDaGFpciBvZiBNSVA0IFdHIGluIElFVEYpDQoxMDowMC0xMDozMCAgSW52aXRlZCBzcGVha2Vy IGZvcm0gTlNGIG9mIFVTQQ0KICAgICAgICAgICAgIE1yLiAoSW52aXRlZCBieSBDRVJORVQpDQox MDozMC0xMDo0MCAgIO+8nCAgQ29mZmVlIEJyZWFrIO+8ng0KMTA6NDAtMTE6MTAgIE5ldyBUcmVu ZCBvZiBOZXh0IEdlbmVyYXRpb24gSW50ZXJuZXQgb2YgQ2hpbmEgVW5pY29tLg0KICAgICAgICAg ICAgIERyLiBZdW5qaWUgTGl1IChQcmUtQ1RPIG9mIENoaW5hIFVuaWNvbSkNCjExOjEwLTExOjQw ICBEb2NvbW8gTmV4dCBHZW5lcmF0aW9uIEFsbCBJUCBuZXR3b3JrDQogICAgICAgICAgICAgTXIu IE1hc2FtaSBZYWJ1c2FraSAoRGlyZWN0b3Igb2YgQWxsLUlQIG5ldHdvcmsgZGV2ZWxvcG1lbnQg YW5kIHN0YW5kYXJkaXphdGlvbiwgRG9Db01vKQ0KICAgICAgICANCu+8nCBMdW5jaCDvvJ4NCjEy OjIwLTE0OjAwICANCu+8nEFmdGVybm9vbiBTZXNzaW9u77yeICAgICAgIENoYWlyOiBHb3BhbCBE b21tZXR5IChWaWNlIENoYWlybWFuIG9mIE1JUDYgV0cpDQoxNDowMC0xNDozMCAgQ0VSTkVUMg0K ICAgICAgICAgICAgIE1yLiAgICggQ0VSTkVUKQ0KMTQ6MzAtMTU6MDAgIC4uIFdHIGluIElFVEYN CiAgICAgICAgICAgICBNci4gIChJRVRGKSANCjE1OjAwLTE1OjIwICAg77ycICBDb2ZmZWUgQnJl YWsg77yeDQoxNToyMC0xNTo1MCAgTmV3IFRyZW5kIG9mIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5l dCBvZiBDaGluYSBUZWxlY29tLg0KICAgICAgICAgICAgIE1yLiAoQ2hpbmEgVGVsZWNvbSkNCjE1 OjUwLTE2OjIwICBGaXhlZCBhbmQgTW9iaWxlIGNvbnZlcmdlbmNlDQogICAgICAgICAgICAgRHIu ICAoSGl0YWNoaSkNCjE2OjIwLTE2OjUwICBJVFUgYW5kIElFVEYgcmVsYXRpb25zaGlwDQogICAg ICAgICAgICAgTXMuICAoSVRVKSAoTGluZ3RhbywgSmlhbmcpDQoxNjo1MC0xNzoyMCAgTmV0d29y ayBUcmVuZA0KICAgICAgICAgICAgIE1zLiAoSW52aXRlZCBieSBDRVJORVQpDQoxNzoyMC0xODow MCAgM0dQUDIgSU1TDQogICAgICAgICAgICAgTXMuIFlhbiBMaSAoUXVhbGNvbW0pDQo8QmFucXVl dD4gICAgMTg6MjAtMjA6MDANCkZlYi4gMjh0aA0K77ycTW9ybmluZyBTZXNzaW9u77ye44CA44CA 44CA44CAQ2hhaXI6IFByb2YuWmlxaWFuZyBIb3UgKENoaWVmIEFkdmlzb3Igb2YgQ2hpbmEgTmV0 Y29tKQ0KOTowMC05OjMwICAgIElFRUUgODAyLjE2IGFuZCBIdWF3ZWkNCiAgICAgICAgICAgIE1y LiBQaGlsbGlwIEJhcmJlciAgKENoYWlyIG9mIE5FVE1BTiwgSUVFRSA4MDIuMTYpDQo5OjMwLTEw OjAwICAgTW9iaWxlIElQdjYgaW4gSUVURg0KICAgICAgICAgICAgRHIuIEdvcGFsIERvbW1ldHkg KENvLUNoYWlyIG9mIE1JUDYgV0cgaW4gSUVURiwgQ2lzY28pIA0KMTA6MDAtMTA6MzAgIEludml0 ZWQgc3BlYWtlciBmb3JtIENoaW5hIEFjYWRlbXkgb2YgU2NpZW5jZQ0KICAgICAgICAgICAgIE1y Lg0KMTA6MzAtMTA6NDAgICDvvJwgIENvZmZlZSBCcmVhayDvvJ4NCjEwOjQwLTExOjEwICBOZXcg VHJlbmQgb2YgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0IG9mIENoaW5hIE1vYmlsZS4NCiAgICAg ICAgICAgICBNcy4gKENoaW5hIE1vYmlsZSkNCjExOjEwLTExOjQwICBJRUVFIDgwMi4yMSBXRw0K ICAgICAgICAgICAgIERyLiBBamF5IFJhamt1bWFyIChMdWNlbnQpDQoxMDozMC0xMTowMCAgTmV3 IFRyZW5kIG9mIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5ldCBvZiBDaGluYSBOZXRjb20uDQogICAg ICAgICAgICAgTXMuIChDaGluYSBOZXRjb20pDQoNCu+8nEFmdGVybm9vbiBTZXNzaW9u77yeICBE aXJlY3RvciBvZiBDRVJORVQsIERyLiBKaWFucGluZyBXdQ0KIEZvcnVtIGFuZCBWaXNpdCBDRVJO RVQyDQogIEFsbCBJbnZpdGVkIFNwZWFrZXJzOg0KICBUb3BpY3M6IE5ldyBUcmVuZCBvZiBOZXh0 IEdlbmVyYXRpb24gSW50ZXJuZXQNCkNsb3NpbmcgQWRkcmVzcw0KIA0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpQbGVhc2UgYWxsb3cgdXMg dG8gaW50cm9kdWNlIENOR0kgaGVyZSwNCiANClRoZSBDTkdJIChDaGluYSBOZXh0IEdlbmVyYXRp b24gSW50ZXJuZXQgUHJvamVjdCkgd2FzIHN0YXJ0ZWQgaW4gMjAwMy4gSXQgd2lsbCAgY29uc3Ry dWN0IGEgYmlnIElQdjYgbmV0d29yayBieSB0aGUgZW5kIG9mIDIwMDUgdGhhdCB3aWxsIGNvdmVy IHdob2xlIGNvdW50cnksIDIwKyAgY2l0aWVzLCAzOSBjb3JlIG5vZGVzLCBhbmQgMzAwKyBhY2Nl c3Mgbm9kZXMuIFRoZW4gQ2hpbmEgbWF5IGJlY29tZSBhIGNvdW50cnkgdGhhdCAgaGFzIHRoZSBs YXJnZXN0IElQdjYgbmV0d29yay4gVGhlIENOR0kgcHJvamVjdCBpcyBsZWFkZWQgYnkgc3RhdGUg YWRtaW5pc3RyYXRpb25zLiAgVGhleSBhcmUgTmF0aW9uYWwgRGV2ZWxvcG1lbnQgYW5kIFJlZm9y bSBDb21taXNzaW9uIChORFJDKSx0aGUgTWluaXN0cnkgb2YgU2NpZW5jZSAgYW5kIFRlY2hub2xv Z3kgKE1PU1QpLCB0aGUgTWluaXN0cnkgb2YgRWR1Y2F0aW9uIChNT0UpLCB0aGUgTWluaXN0cnkg b2YgSW5mb3JtYXRpb24gIEluZHVzdHJ5IChNSUkpLCB0aGUgU3RhdGUgQ291bmNpbCBJbmZvcm1h dGl6YXRpb24gT2ZmaWNlLCB0aGUgQ2hpbmVzZSBBY2FkZW15IG9mICBTY2llbmNlcyAoQ0FTKSwg dGhlIENoaW5lc2UgQWNhZGVteSBvZiBFbmdpbmVlcmluZyAoQ0FFKSBhbmQgdGhlIE5hdGlvbmFs IE5hdHVyYWwgIFNjaWVuY2UgRm91bmRhdGlvbiBvZiBDaGluYSAoTlNGQykuIA0KIA0KVG8gYmUg dGhlIHBhcnQgb2YgQ05HSSBwcm9qZWN0LCB0aGUgdGVsZWNvbSBvcGVyYXRvcnMsIHdobyBpbmNs dWRlIENoaW5hIFRlbGVjb20sICBDaGluYSBVbmljb20sIENoaW5hIE5ldGNvbSwgQ2hpbmEgTW9i aWxlIGFuZCBDaGluYSBSYWlsY29tLCBhbG9uZyB3aXRoIHRoZSBhY2FkZW1pYyAgbmV0d29yayBD RVJORVQgYW5kIENTVE5FVCwgYXJlIHJlc3BvbnNpYmxlIGZvciBjb25zdHJ1Y3RpbmcgdGhlaXIg b3duIElQdjYgY29yZSAgbmV0d29ya3MuIFRoZSBDTkdJIG5ldHdvcmsgc3dpdGNoIGNlbnRlcnMg bG9jYXRlZCBpbiBCZWlqaW5nIGFuZCBTaGFuZ2hhaSB3aWxsICBjb25uZWN0IGFib3ZlIElQdjYg Y29yZSBuZXR3b3JrcyBhbmQgaW50ZXItd29ya2luZyB3aXRoIGludGVybmF0aW9uYWwgSVB2NiB0 cmFpbCAgbmV0d29ya3MuIC4gDQogDQpUaGUgQ05HSSBFeHBlcnQgQ29tbWlzc2lvbiB3YXMgZXN0 YWJsaXNoZWQgdG8gbWFuYWdlIHRoZSBwcm9qZWN0LCBhbmQgdGVsZWNvbSAgb3BlcmF0b3JzLCBt YW51ZmFjdHVyZXMgYW5kIHJlc2VhcmNoIGluc3RpdHV0ZXMgaGF2ZSBqb2luZWQgdGhlIGVmZm9y dC4gQ05HSSBFeHBlcnQgIENvbW1pc3Npb24gaGFzIHRocmVlIHN1YiB3b3JraW5nIGdyb3Vwczog dGhlIENOR0kgTmV0d29yayBDb25zdHJ1Y3Rpb24gV29ya2luZyAgR3JvdXAsIHRoZSBOZXR3b3Jr IEFwcGxpY2F0aW9uIGFuZCBTZXJ2aWNlIFdvcmtpbmcgR3JvdXAgYW5kIHRoZSBOZXR3b3JrIFIm RCBhbmQgIEluZHVzdHJpYWxpemF0aW9uIFdvcmtpbmcgR3JvdXAuIA0KIA0KQ0VSTkVUMiAoTmV4 dCBHZW5lcmF0aW9uIEVkdWNhdGlvbiBhbmQgUmVzZWFyY2ggTmV0d29yayBpbiBDaGluYSkgaXMg dGhlIGJpZ2dlc3QgIE5hdGl2ZSBJUHY2IG5ldHdvcmsgYXJvdW5kIHRoZSB3b3JsZCB3aGljaCBj b25uZWN0IDEwMCsgVW5pdmVyc2l0aWVzIGFuZCAxMDArICBSZXNlYXJjaCBJbnN0aXR1dGVzIGF0 IDFHYnBzKyANCkNoaW5hIE1vYmlsZTogICAgTW9iaWxlIE9wZXJhdG9yIHdpdGggbGFyZ2VzdCBj YXBhY2l0eSBpbiB0aGUgd29ybGQNCkNoaW5hIFRlbGVjb206ICBNb3N0IHNvdXRoIHBhcnQgb2Yg Q2hpbmEgZml4ZWQgb3BlcmF0b3IgYW5kIG5ldHdvcmsgYWNjZXNzIHByb3ZpZGVyDQpDaGluYSBV bmljb206ICAgTm8uIDMgTW9iaWxlIE9wZXJhdG9yIGFuZCBOby4gMiBDRE1BIG9wZXJhdG9yIHJh bmtlZCBpbiBudW1iZXIgb2YgIHN1YnNjcmliZXIgaW4gdGhlIHdvcmxkDQpDaGluYSBOZXRjb206 ICAgTW9zdCBub3J0aCBwYXJ0IG9mIENoaW5hIGZpeGVkIG9wZXJhdG9yIGFuZCBuZXR3b3JrIGFj Y2VzcyBwcm92aWRlcg0KQ1NUTkVUICAgICAgICAgIChDaGluYSBTY2llbmNlIGFuZCBUZWNobm9s b2d5IE5ldHdvcmspDQpDaGluYSBSYWlsY29tOiAgTmV3IHRlbGVjb20gb3BlcmF0b3IuDQoNCg== Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============1646428917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1646428917==-- From sip-bounces@ietf.org Mon Jan 30 05:32:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3WKI-0003iE-HK; Mon, 30 Jan 2006 05:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3WKG-0003hw-7A for sip@megatron.ietf.org; Mon, 30 Jan 2006 05:32:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11724 for ; Mon, 30 Jan 2006 05:30:15 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3WUm-00072m-Ku for sip@ietf.org; Mon, 30 Jan 2006 05:42:57 -0500 Received: from kodiaktemp ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0UARuP16954; Mon, 30 Jan 2006 15:57:56 +0530 From: "Nataraju A B" To: "'Aki Niemi'" , Subject: RE: [Sip] New draft about etags in subscribe/notify Date: Mon, 30 Jan 2006 16:00:59 +0530 Message-ID: <001201c62588$42f2b4a0$7302a8c0@kodiaktemp> 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 In-Reply-To: <43D9DBFE.4060904@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 4.9 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: 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 Dear Neimi, Please find some comments on the draft "draft-niemi-sip-subnot-etags-00.txt" 1. If I understand correctly, if the e-tags match between the SUBSCRIBE requests and the one available with NOTIFIER, then the notify request need not carry the message body (carrying the current state of the event). But in section 4.3 Suppressing NOTIFY Bodies section, it's been mentioned as if the entity-tags do not match, the notifier MUST suppress the body of the resulting NOTIFY request... Suggestion 1: when the suppression has to happen, can we suppress the whole NOTIFY message instead of only body of the NOTIFY request... since NOTIFY is not a mandatory request for each successful subscription... Suggestion 2: when the suppression has to happen, can we return a success response (for instance 203 "Subscription extended" or some thing similar reason phrase) instead or 412 response... ? <<<<<<<<< Suggestion 3: to fetch or poll for the subscription state, overload the SUBSCRIBE header and add a parameter in event header which specifies fetch the current state of the subscription. Similarly we can add one more parameter value for poll operation also... OR Other option would be we can add one more header which specifies action like fetch, poll, subscribe, terminate Subscribe-Action: "subscribe"/"fetch"/"poll"/"terminate".... >>>>>>> We also need to describe the notifier behavior for all these operations.... Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Aki Niemi Sent: Friday, January 27, 2006 2:08 PM To: sip@ietf.org Subject: [Sip] New draft about etags in subscribe/notify Hi All, I just submitted a new draft defining extensions to SIP events for allowing conditional subscribes: http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-00.txt The issue this attempts to fix were documented in a sipping draft [1], and discussed in IETF 63. My impression of that discussion was moderate interest, so here's the mechanism proposal. Comments are very welcome. Cheers, Aki [1] http://www.softarmor.com/wgdb/docs/draft-niemi-sipping-subnot-issues-00. txt (expired) _______________________________________________ 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 30 06:00:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Wlk-0007n4-JF; Mon, 30 Jan 2006 06:00:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Wlj-0007lb-2r for sip@megatron.ietf.org; Mon, 30 Jan 2006 06:00:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13401 for ; Mon, 30 Jan 2006 05:58:41 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3WwK-0007rP-Mo for sip@ietf.org; Mon, 30 Jan 2006 06:11:23 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0UAvMTK031719; Mon, 30 Jan 2006 12:57:22 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 13:00:02 +0200 Received: from [172.21.35.153] ([172.21.35.153]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Jan 2006 13:00:02 +0200 Message-ID: <43DDF1B1.9090201@nokia.com> Date: Mon, 30 Jan 2006 13:00:01 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Nataraju A B Subject: Re: [Sip] New draft about etags in subscribe/notify References: <001201c62588$42f2b4a0$7302a8c0@kodiaktemp> In-Reply-To: <001201c62588$42f2b4a0$7302a8c0@kodiaktemp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2006 11:00:02.0246 (UTC) FILETIME=[51AB2E60:01C6258C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Hi Nataraju, Thanks for the comments, please find my answers below. ext Nataraju A B wrote: > Dear Neimi, > > Please find some comments on the draft > "draft-niemi-sip-subnot-etags-00.txt" > > 1. If I understand correctly, if the e-tags match between the SUBSCRIBE > requests and the one available with NOTIFIER, then the notify request > need not carry the message body (carrying the current state of the > event). > But in section 4.3 Suppressing NOTIFY Bodies section, it's been > mentioned as if the entity-tags do not match, the notifier MUST > suppress the body of the resulting NOTIFY request... Uhh, it should say that if the condition fails, i.e., the entity-tags *do* match (since the condition was a if-none-match), then the NOTIFY is suppressed. Thanks for catching this. > Suggestion 1: when the suppression has to happen, can we suppress the > whole NOTIFY message instead of only body of the NOTIFY request... since > NOTIFY is not a mandatory request for each successful subscription... Actually, the NOTIFY is mandatory after each successful subscribe. So that doesn't really work but... > Suggestion 2: when the suppression has to happen, can we return a > success response (for instance 203 "Subscription extended" or some thing > similar reason phrase) instead or 412 response... ? ...this is another alternative, and the next best one after suppressing just the NOTIFY body. That is, we definitely want a 2xx for the SUBSCRIBE, so that the expiry can be extended, even if the conditional request fails. But the problem is that RFC3265 says a NOTIFY must always follow a 2xx to a SUBSCRIBE; the request also contains the Subscription-State header field, which contains relevant state information. So it seems the NOTIFY simply can't be suppressed totally, and we have to make due with suppressing just the body. > <<<<<<<<< > Suggestion 3: to fetch or poll for the subscription state, overload the > SUBSCRIBE header and add a parameter in event header which specifies > fetch the current state of the subscription. Similarly we can add one > more parameter value for poll operation also... I don't quite follow. This is the default operation anyway, i.e., a SUBSCRIBE with Expires: 0 fetches the current state without creating a subscription. What the etags allow is to communicate which version of state the fetcher already has possession of, so that it need not be sent again. > OR > Other option would be we can add one more header which specifies action > like fetch, poll, subscribe, terminate > Subscribe-Action: "subscribe"/"fetch"/"poll"/"terminate".... This is all there already, and depends on the Expires header field value of the SUBSCRIBE. Perhaps it could have been clearer to define specific methods for these operations, but this is the age-old debate about which is better: do(method, params) vs. do_method(params) Both work. Cheers, Aki _______________________________________________ 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 31 01:52:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3pNV-0006L6-Ja; Tue, 31 Jan 2006 01:52:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3pNS-0006DN-Af for sip@megatron.ietf.org; Tue, 31 Jan 2006 01:52:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19762 for ; Tue, 31 Jan 2006 01:50:50 -0500 (EST) From: andal.sambandam@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3pY2-0007pv-Lr for sip@ietf.org; Tue, 31 Jan 2006 02:03:41 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C8E8205F9 for ; Tue, 31 Jan 2006 12:06:37 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 3EDF8205DE for ; Tue, 31 Jan 2006 12:06:37 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 12:21:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Jan 2006 12:18:15 +0530 Message-ID: <5DEA672491D2B947B9EAB1EFF968D00C019BDA77@BLR-EC-MBX02.wipro.com> Thread-Topic: Question on SIP Torture test message Thread-Index: AcYmMk/eEqKmj/6UR+2ldDKwiK87bg== To: X-OriginalArrivalTime: 31 Jan 2006 06:51:19.0623 (UTC) FILETIME=[BD815D70:01C62632] X-Spam-Score: 1.1 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Sip] Question on SIP Torture test message 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="===============1298584257==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1298584257== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62632.BD17C64B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62632.BD17C64B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In the first version "SIP Torture test messages draft " (http://www.iptel.org/info/players/ietf/callflows/draft-ietf-sipping-tor ture-tests-00.txt ), there was a test case "2.15 INVITE with Invalid Via and Contact Headers" and for this test case, the expected behavior stated was " The server should respond with a Bad Request error."=20 =20 Later I found that, this particular test case is missing in the latest versions of the draft (from 01 to latest, this test case is missing). On analysing the test message, this is what I inferred : =20 " When we have parsing errors in the VIA header field, we do not send any error response back because we need the values from the VIA header to send the response back for that request as according to the RFC, so in this case we are not able to send any response back. The possible solutions that we could have is to send the response back using CONTACT header value or we could send it back from the IP address it came from, but both these methods can have serious side effects on the intermediate proxies in certain cases.So, it is better to ignore the INVITE message with invalid Via or contact header fields rather than sending Bad request error. "=20 =20 I want to know, whether my inference on this test case is correct? Also, other than this, is there any particular reason for removal of this test case in the later versions?=20 =20 Regards, Andal. ------_=_NextPart_001_01C62632.BD17C64B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
In=20 the first version "SIP Torture test messages draft "=20  (http://www.iptel.org/info/players/ietf/callflows/draft-ietf-sipp= ing-torture-tests-00.txt), there was a test case "2.15 INVITE with Invalid Via and = Contact=20 Headers" and for this test case, the expected behavior stated was " The = server=20 should respond with a Bad Request error."=20
 
Later I found=20 that, this particular test case is missing in the latest versions of the = draft=20 (from 01 to latest, this test case is missing).  On analysing the = test=20 message, this is what I inferred :
 
" When = we have=20 parsing errors in the VIA header field, we do not send any error = response back=20 because we need the values from the VIA header to send the response back = for=20 that request as according to the RFC, so in this case we are not able to = send=20 any response back. The possible solutions that we could have is = to send=20 the response back using CONTACT header value or we could send it back = from the=20 IP address it came from, but both these methods can have serious side = effects on=20 the intermediate proxies in certain cases.So, it is better to ignore the INVITE message = with=20 invalid Via or contact header fields rather than sending Bad request = error.=20 "
 
I want to know, whether my inference on = this test=20 case is correct? Also, other than this, is there any particular reason = for=20 removal of this test case in the later versions? =
 
Regards,
Andal.
= ------_=_NextPart_001_01C62632.BD17C64B-- --===============1298584257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1298584257==-- From sip-bounces@ietf.org Tue Jan 31 06:37:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tpM-0007cX-0u; Tue, 31 Jan 2006 06:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tpK-0007bJ-Uy for sip@megatron.ietf.org; Tue, 31 Jan 2006 06:37:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07768 for ; Tue, 31 Jan 2006 06:36:03 -0500 (EST) Received: from smtp11.clb.oleane.net ([213.56.31.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3u0I-0007q5-Fb for sip@ietf.org; Tue, 31 Jan 2006 06:48:59 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp11.clb.oleane.net with ESMTP id k0VBb7Ae019108 for ; Tue, 31 Jan 2006 12:37:27 +0100 Message-Id: <200601311137.k0VBb7Ae019108@smtp11.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 31 Jan 2006 12:37:19 +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: AcYmWrFp0ZqW0EMDRXSLHaW1+lR8Tw== X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Sip] International SIP/WiMAX Summit - 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="===============1635739393==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1635739393== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01C62663.137EE960" This is a multi-part message in MIME format. ------=_NextPart_000_00BC_01C62663.137EE960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit More than 500 participants will attend International SIP and the WiMAX Summit next February 21st to 24th in Paris. Registration is still open for both events. The 7th edition of the International SIP conference program is mainly dedicated to IMS architectures and Peer-to-Peer communications: http://www.upperside.fr/sip2006/sip2006intro.htm The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant operators: http://www.upperside.fr/wimax2006/wimax2006intro.htm Close to the conference rooms an exhibition welcomes industrials involved in VoIP and wireless broadband access. ------=_NextPart_000_00BC_01C62663.137EE960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

More than 500 participants will attend = International = SIP and the WiMAX Summit next February 21st to 24th in = Paris.

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           =

Registration is still open for both = events.

 

The 7th edition of the International SIP = conference program is mainly dedicated to IMS architectures = and Peer-to-Peer communications:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant = operators:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

Close to the conference rooms an exhibition = welcomes industrials involved in VoIP and wireless broadband = access.

 

------=_NextPart_000_00BC_01C62663.137EE960-- --===============1635739393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1635739393==--