From mailnull@www1.ietf.org Thu May 1 03:47:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01389 for ; Thu, 1 May 2003 03:47:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417r8t31852 for sip-archive@odin.ietf.org; Thu, 1 May 2003 03:53:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h417qh831777; Thu, 1 May 2003 03:52:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h417gX831440 for ; Thu, 1 May 2003 03:42:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01174 for ; Thu, 1 May 2003 03:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8e2-000739-00 for sip@ietf.org; Thu, 01 May 2003 03:38:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8dw-00072v-00 for sip@ietf.org; Thu, 01 May 2003 03:38:12 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417bsdh004784; Thu, 1 May 2003 03:37:58 -0400 (EDT) Message-ID: <3EB08BE3.2040006@dynamicsoft.com> Date: Wed, 30 Apr 2003 22:52:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: wenkai CC: Christer Holmberg , sip@ietf.org Subject: Re: [Sip] can i change my own dialog info in mid-dialog? References: <00b001c30a2b$6a1db870$af064d0a@w07087a> <3EA78A6F.1C67E563@lmf.ericsson.se> <000c01c30a34$90589f10$af064d0a@w07087a> <3EA9F280.8010800@dynamicsoft.com> <000701c30d71$f4ac3d60$af064d0a@w07087a> In-Reply-To: <000701c30d71$f4ac3d60$af064d0a@w07087a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit wenkai wrote: > I would like make my original question more clear by dividing it into two > parts. > > The first part: > "UA can change his local uri and remote uri by himself in mid-dialog.", i > think it is correct in RFC3261. To be clear; rfc3261 forbids this because of compatibility with rfc2543. > > The second part: > "UA can change his request-uri by himself in mid-dialog." Maybe we can not > do it. > RFC3261 said, in mid-dialog, "The UAC uses the remote target and route set > to build the Request-URI". UA can not change "remote target" and "route > set" by himself in mid-dialog. So, UA can not change his request-uri by > himself in mid-dialog. The UA can change his request-uri by opposite UA's > instruction. > > I ask this question because request-uri can be used as service > identification. If UA can change the request-uri by itself, so UA can use > request-uri to carry different service request during mid-dialog. Maybe we > can use parameters to achieve this target. I have seen this proposed in the past as one of sevearl possible approaches for using SIP as an application control protocol. INFO is the other favorite. I still believe that this is generally outside the scope of SIP. If you want to control an application to which you have initiated a session, you should open a "control session" which is e2e. This control session, like the audio session, is signaling with the SDP, and based on some non-SIP protocol. I actually really like MSRP (draft-campbell-simple-im-sessions-01) as a means for conveying e2e control messages. I think many folks still like INFO, but perhaps this is mostly because of the lack of a viable alternative. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 1 03:52:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01593 for ; Thu, 1 May 2003 03:52:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417wTv32184 for sip-archive@odin.ietf.org; Thu, 1 May 2003 03:58:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h417wC832167; Thu, 1 May 2003 03:58:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h417pa831745 for ; Thu, 1 May 2003 03:51:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01348 for ; Thu, 1 May 2003 03:45:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8mn-00075z-00 for sip@ietf.org; Thu, 01 May 2003 03:47:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8mi-00075j-00 for sip@ietf.org; Thu, 01 May 2003 03:47:16 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417c7dh004791; Thu, 1 May 2003 03:38:10 -0400 (EDT) Message-ID: <3EB08D34.8000005@dynamicsoft.com> Date: Wed, 30 Apr 2003 22:57:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vkenneally@cit.ie CC: sip@ietf.org Subject: Re: [Sip] Complete list of transport protocols upon which SIP can run! References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit TCP, UDP and SCTP. It can also use TLS over TCP. -Jonathan R. Valerie Kenneally wrote: > Hi All, > > Just wondering if anyone knows where I might find a complete list of the > transport protocols upon which SIP can run? > > Cheers, > Val > > > -------------------Legal Disclaimer--------------------------------------- > > The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. > > ---------------------------------------------------------------------------------------- > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 1 05:54:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03811 for ; Thu, 1 May 2003 05:54:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41A0rZ07710 for sip-archive@odin.ietf.org; Thu, 1 May 2003 06:00:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41A0M807694; Thu, 1 May 2003 06:00:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h419oB807356 for ; Thu, 1 May 2003 05:50:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03673 for ; Thu, 1 May 2003 05:43:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BAdG-0007hX-00 for sip@ietf.org; Thu, 01 May 2003 05:45:38 -0400 Received: from mirlo.dit.upm.es ([138.4.5.18]) by ietf-mx with esmtp (Exim 4.12) id 19BAd1-0007hB-00 for sip@ietf.org; Thu, 01 May 2003 05:45:23 -0400 Received: from Perdiz (perdiz [138.4.50.3]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id JAA24704 for ; Thu, 1 May 2003 09:45:20 GMT From: =?Windows-1252?Q?Manuel_Moreno_Mart=EDn?= To: "Sip" Date: Thu, 1 May 2003 11:44:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] over SIP timers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please: Is correct the denomination "retransmit timer" for the timers T2,A,D,E,G,I,J and K ??? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 1 06:24:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04548 for ; Thu, 1 May 2003 06:24:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41AU6H09441 for sip-archive@odin.ietf.org; Thu, 1 May 2003 06:30:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41ATl809422; Thu, 1 May 2003 06:29:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41AOO809309 for ; Thu, 1 May 2003 06:24:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04493 for ; Thu, 1 May 2003 06:17:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BBAb-00003p-00 for sip@ietf.org; Thu, 01 May 2003 06:20:05 -0400 Received: from mirlo.dit.upm.es ([138.4.5.18]) by ietf-mx with esmtp (Exim 4.12) id 19BBAM-00003l-00 for sip@ietf.org; Thu, 01 May 2003 06:19:50 -0400 Received: from Perdiz (perdiz [138.4.50.3]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id KAA24739 for ; Thu, 1 May 2003 10:20:16 GMT From: =?Windows-1252?Q?Manuel_Moreno_Mart=EDn?= To: "Sip" Date: Thu, 1 May 2003 12:19:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] over SIP timers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please: With more precission ... Are the timers T2, A, D, E, G, I, J and K "retransmission timers"??? Are the timers B, C, F and H "timeout timers"?? Which denomination to use for the timers T1 and T4?? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 1 08:56:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07324 for ; Thu, 1 May 2003 08:56:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41D1RC19330 for sip-archive@odin.ietf.org; Thu, 1 May 2003 09:01:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D0x818757; Thu, 1 May 2003 09:00:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41CrT817831 for ; Thu, 1 May 2003 08:53:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07024 for ; Thu, 1 May 2003 08:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BDUq-0000ca-00 for sip@ietf.org; Thu, 01 May 2003 08:49:08 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19BDUe-0000cF-00 for sip@ietf.org; Thu, 01 May 2003 08:48:56 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41CmeO20418 for ; Thu, 1 May 2003 08:48:40 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 13:48:39 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED04@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Roland Gloeckler'" Cc: sip@ietf.org Subject: RE: [Sip] Motivation for RFC 3325 Date: Thu, 1 May 2003 13:48:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41CrT817832 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I believe the two main drivers in its development were the IP Cable people and 3GPP. It is currently specified for use to provide calling user and connected user identity in 3GPP IP multimedia core network subsystem specifications, which use SIP (3GPP TS 24.229). It is also specified for use in SS7 to ISUP/BICC interworking specifications in ITU-T. The key constraint on its use is that it requires a trust domain to exist, and that is why it is not generally applicable in all SIP environments. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Roland Gloeckler [mailto:gloeckle@ikr.uni-stuttgart.de] > Sent: 30 April 2003 11:16 > To: mwatson@nortelnetworks.com; Jon.Peterson@NeuStar.biz; > fluffy@cisco.com > Cc: sip@ietf.org > Subject: [Sip] Motivation for RFC 3325 > > > Dear Sirs, > > I would like to know which Scenarios you had in mind for the > usage of RFC 3325. > > In chapter 1 you state the following: > "An example deployment would be a closed network which > emulates a traditional circuit switched telephone network." > > Is this the Scenario that motivated you or are the others? > > Regards > > Roland Glöckler > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Fri May 2 04:19:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09065 for ; Fri, 2 May 2003 04:19:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h428Pdj00698 for sip-archive@odin.ietf.org; Fri, 2 May 2003 04:25:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h428Oi800642; Fri, 2 May 2003 04:24:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h419aK806136 for ; Thu, 1 May 2003 05:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03489 for ; Thu, 1 May 2003 05:29:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BAPr-0007ea-00 for sip@ietf.org; Thu, 01 May 2003 05:31:47 -0400 Received: from tssg.wit.ie ([193.1.185.11] helo=mail.tssg.org) by ietf-mx with esmtp (Exim 4.12) id 19BAPm-0007eN-00 for sip@ietf.org; Thu, 01 May 2003 05:31:42 -0400 Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 29D1B180A0 for ; Thu, 1 May 2003 10:31:56 +0100 (IST) From: "Shane McCormack" To: Date: Thu, 1 May 2003 10:36:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3EB08BE3.2040006@dynamicsoft.com> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] SIP INVITE request mapping to call object Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I am currently working on my thesis which involves me creating a simplified generic java API layer above SIP and parlay for easier service development. This involves the creation of call objects similar to Java Call Control, and Parlay. When mapping an incoming INVITE (or incoming requests such as a NOTIFY for presence for other similar objects), some mapping has to be performed. My question is would you associate a call object with a request callid or dialog? or both. So that when some routing operation is performed by the client application using my API the correct incoming INVITE is referenced in the underlying SIP stack when the call object is passed back to be routed or proxied. I am actually using SIP servlets for this implementation so SIP stack is not correct term to use. Regards Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.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 mailnull@www1.ietf.org Fri May 2 09:39:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13751 for ; Fri, 2 May 2003 09:39:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42Djco22378 for sip-archive@odin.ietf.org; Fri, 2 May 2003 09:45:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Dj4822358; Fri, 2 May 2003 09:45:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42DeW822187 for ; Fri, 2 May 2003 09:40:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13455 for ; Fri, 2 May 2003 09:33:13 -0400 (EDT) From: maria.a.cuevas@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BahA-0004GN-00 for sip@ietf.org; Fri, 02 May 2003 09:35:24 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt03.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19Bah4-0004Fo-00 for sip@ietf.org; Fri, 02 May 2003 09:35:18 -0400 Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 2 May 2003 14:35:10 +0100 Message-ID: <7497DCA1C240C042B28F6657ADFD8E0953849A@i2km11-ukbr.domain1.systemhost.net> To: sip@ietf.org Date: Fri, 2 May 2003 14:34:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Question about resource management Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, I have a question regarding resource management and in particular related to at which point in the session establishment may resource reservation be initiated. I would appreciate any comments on this. I have noticed that the examples given in RFC 3312 seem to indicate that resource reservation may be initiated as soon as an answer has been sent (by the answerer) or received (by the offerer). At some point the RFC says: "If the resource reservation mechanism used requires participation of both user agents, the answerer SHOULD start resource reservation after having sent the answer and the offerer SHOULD start resource reservation as soon as the answer is received. If participation of the peer user agent is not needed (e.g., segmented status type), the offerer MAY start resource reservation before sending the offer and the answerer MAY start it before sending the answer." My question is: if the answer (lets assume that it is carried in a 183 response) is carrying a list of codecs taken from the initial offer (my understanding is that this is possible under the answer/offer model), shouldn't both user agents wait for the updated (final) answer to be sent and received (in the PRACK or the 200 OK to the PRACK) before initiating resource reservation? Following on that, I have also noticed that 3GPP call flows as specified in TS 24.228 show resource reservation happening after the 200 OK for the PRACK is sent and received. Couldn't the reservation start just after the PRACK message (carrying the final answer) is sent/received? So, when can we assume that resource reservation can start? Can we assume that it can start as soon as a final offer is sent/received? Thank you very much in advance. Regards Maria _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 2 11:35:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18126 for ; Fri, 2 May 2003 11:35:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42Fg7e32019 for sip-archive@odin.ietf.org; Fri, 2 May 2003 11:42:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42FfR831954; Fri, 2 May 2003 11:41:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Fbg831777 for ; Fri, 2 May 2003 11:37:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17961 for ; Fri, 2 May 2003 11:30:37 -0400 (EDT) From: krisztian.kiss@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BcWk-00050b-00 for sip@ietf.org; Fri, 02 May 2003 11:32:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19BcWf-00050S-00 for sip@ietf.org; Fri, 02 May 2003 11:32:41 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h42FXD719838 for ; Fri, 2 May 2003 18:33:13 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 May 2003 18:33:11 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 2 May 2003 18:33:13 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 2 May 2003 18:33:12 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 2 May 2003 18:33:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question about resource management Date: Fri, 2 May 2003 18:33:11 +0300 Message-ID: Thread-Topic: [Sip] Question about resource management Thread-Index: AcMQsVgXGdULs4SnQnGwMtHGRJVyjwAByhRQ To: , X-OriginalArrivalTime: 02 May 2003 15:33:12.0361 (UTC) FILETIME=[24334190:01C310C0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42Fbg831780 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Maria, a quick clarification for the 3GPP call flows: according to the very latest changes to the last version of the call flows document (3GPP TS 24.228 5.4.0): - the offerer can start the resource reservation procedure right after receiving the answer in 183, if the answer is satisfactory, i.e. it contains single codecs per media flows. In case there is a need to include a second offer in PRACK in order to reduce to the "single codec per media" case, the resource reservation can be started right after sending the PRACK. - the answerer can start the resource reservation procedure right after having sent the answer in 183, if the answer contains single codec per media flows. In case the first answer has multiple codecs per media, the answerer should wait with resource reservation until generating the second answer. Regards, Krisztian > -----Original Message----- > From: ext maria.a.cuevas@bt.com [mailto:maria.a.cuevas@bt.com] > Sent: Friday, May 02, 2003 4:35 PM > To: sip@ietf.org > Subject: [Sip] Question about resource management > > > Dear all, > > I have a question regarding resource management and in > particular related to > at which point in the session establishment may resource > reservation be > initiated. I would appreciate any comments on this. > > I have noticed that the examples given in RFC 3312 seem to > indicate that > resource reservation may be initiated as soon as an answer > has been sent (by > the answerer) or received (by the offerer). At some point the > RFC says: > > "If the resource reservation mechanism used requires participation of > both user agents, the answerer SHOULD start resource reservation > after having sent the answer and the offerer SHOULD start resource > reservation as soon as the answer is received. If participation of > the peer user agent is not needed (e.g., segmented status > type), the > offerer MAY start resource reservation before sending the offer and > the answerer MAY start it before sending the answer." > > My question is: if the answer (lets assume that it is carried in a 183 > response) is carrying a list of codecs taken from the initial > offer (my > understanding is that this is possible under the answer/offer model), > shouldn't both user agents wait for the updated (final) > answer to be sent > and received (in the PRACK or the 200 OK to the PRACK) before > initiating > resource reservation? > > Following on that, I have also noticed that 3GPP call flows > as specified in > TS 24.228 show resource reservation happening after the 200 > OK for the PRACK > is sent and received. Couldn't the reservation start just > after the PRACK > message (carrying the final answer) is sent/received? > > So, when can we assume that resource reservation can start? > Can we assume > that it can start as soon as a final offer is sent/received? > > > Thank you very much in advance. > Regards > Maria > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Fri May 2 12:10:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19074 for ; Fri, 2 May 2003 12:10:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42GHCP02874 for sip-archive@odin.ietf.org; Fri, 2 May 2003 12:17:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GGZ802852; Fri, 2 May 2003 12:16:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GD7802666 for ; Fri, 2 May 2003 12:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18933 for ; Fri, 2 May 2003 12:06:02 -0400 (EDT) From: maria.a.cuevas@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bd51-0005F8-00 for sip@ietf.org; Fri, 02 May 2003 12:08:11 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt08.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19Bd4v-0005Ew-00 for sip@ietf.org; Fri, 02 May 2003 12:08:06 -0400 Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 2 May 2003 16:45:51 +0100 Message-ID: <7497DCA1C240C042B28F6657ADFD8E0953849B@i2km11-ukbr.domain1.systemhost.net> To: krisztian.kiss@nokia.com, sip@ietf.org Subject: RE: [Sip] Question about resource management Date: Fri, 2 May 2003 16:45:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Krisztian, thanks a lot for your answer. I have a further question on this same subject though: - Could the updated offer in the PRACK contain more than one codec again? And, if the answer in the 200 OK (PRACK) still contains a list of codecs, when will resource reservation happend then? Is any of the user agents (offerer or answerer) obliged to reduce the list to a single codec at some point in the offer/answer model? Thank you very much Regards Maria -----Original Message----- From: krisztian.kiss@nokia.com [mailto:krisztian.kiss@nokia.com] Sent: 02 May 2003 16:33 To: Cuevas,MA,Maria,XGH4 R; sip@ietf.org Subject: RE: [Sip] Question about resource management Hi Maria, a quick clarification for the 3GPP call flows: according to the very latest changes to the last version of the call flows document (3GPP TS 24.228 5.4.0): - the offerer can start the resource reservation procedure right after receiving the answer in 183, if the answer is satisfactory, i.e. it contains single codecs per media flows. In case there is a need to include a second offer in PRACK in order to reduce to the "single codec per media" case, the resource reservation can be started right after sending the PRACK. - the answerer can start the resource reservation procedure right after having sent the answer in 183, if the answer contains single codec per media flows. In case the first answer has multiple codecs per media, the answerer should wait with resource reservation until generating the second answer. Regards, Krisztian > -----Original Message----- > From: ext maria.a.cuevas@bt.com [mailto:maria.a.cuevas@bt.com] > Sent: Friday, May 02, 2003 4:35 PM > To: sip@ietf.org > Subject: [Sip] Question about resource management > > > Dear all, > > I have a question regarding resource management and in > particular related to > at which point in the session establishment may resource > reservation be > initiated. I would appreciate any comments on this. > > I have noticed that the examples given in RFC 3312 seem to > indicate that > resource reservation may be initiated as soon as an answer > has been sent (by > the answerer) or received (by the offerer). At some point the > RFC says: > > "If the resource reservation mechanism used requires participation of > both user agents, the answerer SHOULD start resource reservation > after having sent the answer and the offerer SHOULD start resource > reservation as soon as the answer is received. If participation of > the peer user agent is not needed (e.g., segmented status > type), the > offerer MAY start resource reservation before sending the offer and > the answerer MAY start it before sending the answer." > > My question is: if the answer (lets assume that it is carried in a 183 > response) is carrying a list of codecs taken from the initial > offer (my > understanding is that this is possible under the answer/offer model), > shouldn't both user agents wait for the updated (final) > answer to be sent > and received (in the PRACK or the 200 OK to the PRACK) before > initiating > resource reservation? > > Following on that, I have also noticed that 3GPP call flows > as specified in > TS 24.228 show resource reservation happening after the 200 > OK for the PRACK > is sent and received. Couldn't the reservation start just > after the PRACK > message (carrying the final answer) is sent/received? > > So, when can we assume that resource reservation can start? > Can we assume > that it can start as soon as a final offer is sent/received? > > > Thank you very much in advance. > Regards > Maria > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Fri May 2 16:40:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01801 for ; Fri, 2 May 2003 16:40:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42Klbj25771 for sip-archive@odin.ietf.org; Fri, 2 May 2003 16:47:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Kl0825736; Fri, 2 May 2003 16:47:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42KcZ825382 for ; Fri, 2 May 2003 16:38:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01427 for ; Fri, 2 May 2003 16:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BhDa-0007gS-00 for sip@ietf.org; Fri, 02 May 2003 16:33:18 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19BhDU-0007fz-00 for sip@ietf.org; Fri, 02 May 2003 16:33:12 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6) with ESMTP id h41IKfbd016962; Thu, 1 May 2003 20:20:41 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id KBTHAT1N; Thu, 1 May 2003 20:20:39 +0200 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h41IKe2b005748; Thu, 1 May 2003 21:20:40 +0300 (EET DST) Message-ID: <3EB165FB.90FDF134@lmf.ericsson.se> Date: Thu, 01 May 2003 21:22:51 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjay Sinha CC: sip@ietf.org Subject: Re: [Sip] Question on RFC 3263 References: <3EADA6A1.5010302@cisco.com> <3EAE8F5D.C3C1FE84@lmf.ericsson.se> <3EAE95E3.5000906@cisco.com> <3EAFA36A.5492523C@lmf.ericsson.se> <3EAFD79D.7070302@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > >>>>1) Since ACK for 200 response indicates a new transaction and follows > >>>>rules of sec. 4.2 to find out the ip address of next hop element to send > >>>>ACK to, how does the client transaction detect failure for ACK and move > >>>>to next record in the list if used with UDP and the next hop does not generate transport errors. > >>>> > >>>> > >>>> > >>>> > >>>[CHH] It is true that the remote server will not be able to send eg a 503 response for an ACK, but if the failure occurs on the transport level you will be notified >it the same way as you would for any other request (ICMP errors etc). These are sent independently on if the remote server generates SIP responses or not. > >>> > >>> > >>> > >>[SS] But the client transport layer will not get ICMP errors if the > >>first record from the list has crashed or has it's interface shutdown. > >> > >> > > > >[CHH] Well, if the ACK doesn't reach the server you will get retransmits of the 200 OK (unless they are supposed to be sent from the same interface which has crashed, of course).. > > > [SS] Right, but how does the client's transaction figure out that 200 > retransmissions are because of Ack going to the wrong interface from the > list vs. Ack being lost in the network/network delay and whether it > should cycle to the next record or not. [CHH] I guess you will have to use logic based on local policy to decide when to "switch" from one address to another, if the 200 responses don't stop coming, even if you send ACK... > >>>2) For PRACK, if the client transaction layer times out waiting for 200 > >>>OK to PRACK before moving to the next record, the server transaction may > >>>run out of 18x retries waiting for PRACK and disconnect the call, if the > >>>next record happens to be the one that sent 18x. > >>> > >>> > >>> > >>>[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to the same IP address as the INVITE, so if you don't get a reply (even if you get >replies to the INVITE) something is probably wrong on the remote side anway... > >>> > >>> > >>> > >>[SS] I do not think that's true. If the proxy in-between did not > >>record-route, PRACK will be sent to Contact of 18x and not where the > >>Invite was sent. > >> > >> > > > >[CHH] True, but what I meant is that the remote UAS (ie the one generating and sending the 18x messages, and that will eventually receive the PRACK) is the same. > > > >UAC PROXY UAS > > > >--- INVITE ---> --->INVITE---> > ><--18x---------- <---18x---------- > >----PRACK-----------------------> > > > [SS] Not neccesarily, if the UAS has dual interface (for redundancy > etc.) and uses fqdn in contact of 18x with one interface having higher > priority than the other one and the high priority interface down for > some reason. UAC, after dns resolution of contact's fqdn, will use it > for sending Prack and will keep retransmitting till it gets 200 OK and > will cycle to the next record when it runs out of retries. But the UAS > is also retransmitting 18x waiting for Prack since the interface it's > getting Prack on is down and when it runs out of retries will disconnect > the call. [CHH] Well, if one interface, which is to be used to send messages to, is not working, I think disconnecting the call is the only thing you can do... These kind of scenarios have been discussed on the list before. It is possible to come up with an infinite number of them, and the spec can't cover them all, so it's pretty much an implementation issue. In general I would say: if something in the call setup fails you terminate the call setup. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 5 04:35:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26931 for ; Mon, 5 May 2003 04:35:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h458h7L15108 for sip-archive@odin.ietf.org; Mon, 5 May 2003 04:43:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h458ck814955; Mon, 5 May 2003 04:38:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h458Yg814018 for ; Mon, 5 May 2003 04:34:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26872 for ; Mon, 5 May 2003 04:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CbKT-0004VM-00 for sip@ietf.org; Mon, 05 May 2003 04:28:09 -0400 Received: from gate.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx with esmtp (Exim 4.12) id 19CbKN-0004V6-00 for sip@ietf.org; Mon, 05 May 2003 04:28:03 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by gate.ikr.uni-stuttgart.de (Postfix) with ESMTP id C36AE2AD96; Mon, 5 May 2003 10:27:50 +0200 (CEST) Received: from there (lnc2 [10.21.12.22]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 509408D790; Mon, 5 May 2003 10:27:50 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Roland Gloeckler Organization: University of Stuttgart, IKR To: "Drage, Keith (Keith)" Subject: Re: [Sip] Motivation for RFC 3325 Date: Mon, 5 May 2003 10:27:50 +0200 X-Mailer: KMail [version 1.3.1] References: <475FF955A05DD411980D00508B6D5FB00439ED04@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439ED04@en0033exch001u.uk.lucent.com> Cc: sip@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20030505082750.509408D790@netsrv1.ikr.uni-stuttgart.de> Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Mr. Drage, thanks for your answer. Do you know of other documents coping with ISUP interworking and Network Asserted Identities? Regards Roland Glöckler > > It is also specified for use in SS7 to ISUP/BICC interworking > specifications in ITU-T. > > The key constraint on its use is that it requires a trust domain to exist, > and that is why it is not generally applicable in all SIP environments. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Roland Gloeckler [mailto:gloeckle@ikr.uni-stuttgart.de] > > Sent: 30 April 2003 11:16 > > To: mwatson@nortelnetworks.com; Jon.Peterson@NeuStar.biz; > > fluffy@cisco.com > > Cc: sip@ietf.org > > Subject: [Sip] Motivation for RFC 3325 > > > > > > Dear Sirs, > > > > I would like to know which Scenarios you had in mind for the > > usage of RFC 3325. > > > > In chapter 1 you state the following: > > "An example deployment would be a closed network which > > emulates a traditional circuit switched telephone network." > > > > Is this the Scenario that motivated you or are the others? > > > > Regards > > > > Roland Glöckler > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@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 mailnull@www1.ietf.org Mon May 5 14:59:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11438 for ; Mon, 5 May 2003 14:59:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45J7lL26832 for sip-archive@odin.ietf.org; Mon, 5 May 2003 15:07:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45J7D826157; Mon, 5 May 2003 15:07:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45J5Z825869 for ; Mon, 5 May 2003 15:05:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11350 for ; Mon, 5 May 2003 14:56:59 -0400 (EDT) From: krisztian.kiss@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ClB2-0007hW-00 for sip@ietf.org; Mon, 05 May 2003 14:59:04 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ClAw-0007hM-00 for sip@ietf.org; Mon, 05 May 2003 14:58:58 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h45IxLD06726 for ; Mon, 5 May 2003 21:59:21 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 5 May 2003 21:59:21 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 5 May 2003 21:59:20 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 5 May 2003 21:59:20 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 5 May 2003 21:59:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question about resource management Date: Mon, 5 May 2003 21:59:19 +0300 Message-ID: Thread-Topic: [Sip] Question about resource management Thread-Index: AcMQweF+I/ly/845SsyuAfd9vl80eAAA6f6w To: , X-OriginalArrivalTime: 05 May 2003 18:59:19.0757 (UTC) FILETIME=[6EFB5FD0:01C31338] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45J5o825872 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Maria, > Krisztian, thanks a lot for your answer. > > I have a further question on this same subject though: > - Could the updated offer in the PRACK contain more than one > codec again? If either the offerer or the answerer is only able to support the "single codec per media" case, then they should reduce in the first answer (answerer) or in the second offer (offerer). > And, if the answer in the 200 OK (PRACK) still contains a > list of codecs, > when will resource reservation happend then? If both parties are able to support multiple codecs per media, then there is no need for the second offer-answer, resource reservation can be performed according to the result of the first offer-answer. > Is any of the user agents (offerer or answerer) obliged to > reduce the list > to a single codec at some point in the offer/answer model? Only, if one of them cannot support the multiple codecs per media. But, in any case, two offer-answer exchanges make the job. Regards, Krisztian > > Thank you very much > Regards > Maria > > > -----Original Message----- > From: krisztian.kiss@nokia.com [mailto:krisztian.kiss@nokia.com] > Sent: 02 May 2003 16:33 > To: Cuevas,MA,Maria,XGH4 R; sip@ietf.org > Subject: RE: [Sip] Question about resource management > > > Hi Maria, > > a quick clarification for the 3GPP call flows: > according to the very latest changes to the last version of > the call flows > document (3GPP TS 24.228 5.4.0): > - the offerer can start the resource reservation procedure right after > receiving the answer in 183, if the answer is satisfactory, > i.e. it contains > single codecs per media flows. In case there is a need to > include a second > offer in PRACK in order to reduce to the "single codec per > media" case, the > resource reservation can be started right after sending the PRACK. > - the answerer can start the resource reservation procedure > right after > having sent the answer in 183, if the answer contains single > codec per media > flows. In case the first answer has multiple codecs per > media, the answerer > should wait with resource reservation until generating the > second answer. > > Regards, > Krisztian > > > > -----Original Message----- > > From: ext maria.a.cuevas@bt.com [mailto:maria.a.cuevas@bt.com] > > Sent: Friday, May 02, 2003 4:35 PM > > To: sip@ietf.org > > Subject: [Sip] Question about resource management > > > > > > Dear all, > > > > I have a question regarding resource management and in > > particular related to > > at which point in the session establishment may resource > > reservation be > > initiated. I would appreciate any comments on this. > > > > I have noticed that the examples given in RFC 3312 seem to > > indicate that > > resource reservation may be initiated as soon as an answer > > has been sent (by > > the answerer) or received (by the offerer). At some point the > > RFC says: > > > > "If the resource reservation mechanism used requires > participation of > > both user agents, the answerer SHOULD start resource reservation > > after having sent the answer and the offerer SHOULD > start resource > > reservation as soon as the answer is received. If > participation of > > the peer user agent is not needed (e.g., segmented status > > type), the > > offerer MAY start resource reservation before sending > the offer and > > the answerer MAY start it before sending the answer." > > > > My question is: if the answer (lets assume that it is > carried in a 183 > > response) is carrying a list of codecs taken from the initial > > offer (my > > understanding is that this is possible under the > answer/offer model), > > shouldn't both user agents wait for the updated (final) > > answer to be sent > > and received (in the PRACK or the 200 OK to the PRACK) before > > initiating > > resource reservation? > > > > Following on that, I have also noticed that 3GPP call flows > > as specified in > > TS 24.228 show resource reservation happening after the 200 > > OK for the PRACK > > is sent and received. Couldn't the reservation start just > > after the PRACK > > message (carrying the final answer) is sent/received? > > > > So, when can we assume that resource reservation can start? > > Can we assume > > that it can start as soon as a final offer is sent/received? > > > > > > Thank you very much in advance. > > Regards > > Maria > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@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 mailnull@www1.ietf.org Tue May 6 06:42:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13953 for ; Tue, 6 May 2003 06:42:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46AooC10054 for sip-archive@odin.ietf.org; Tue, 6 May 2003 06:50:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46AZf808294; Tue, 6 May 2003 06:35:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46APO807904 for ; Tue, 6 May 2003 06:25:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13454 for ; Tue, 6 May 2003 06:16:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CzWc-0004ju-00 for sip@ietf.org; Tue, 06 May 2003 06:18:18 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19CzWX-0004jn-00 for sip@ietf.org; Tue, 06 May 2003 06:18:13 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 3F04B3399D for ; Tue, 6 May 2003 12:18:08 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id ECD483F43B for ; Tue, 6 May 2003 12:19:51 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003050612174627070 for ; Tue, 06 May 2003 12:17:46 +0200 Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by sparte.int-evry.fr (Postfix) with ESMTP id B5C573F460 for ; Tue, 6 May 2003 12:18:13 +0200 (CEST) Received: from int-evry.fr (unknown [157.159.10.13]) by molure.int-evry.fr (Postfix) with ESMTP id 2441FC21BE for ; Tue, 6 May 2003 12:15:45 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: [157.159.103.65] Date: Tue, 06 May 2003 12:21:32 +0300 From: Hassan CHOUMAR In-Reply-To: To: sip@ietf.org MIME-Version: 1.0 User-Agent: IMHO/0.98.3 (Webmail for Roxen) Message-Id: <20030506101545.2441FC21BE@molure.int-evry.fr> Content-Transfer-Encoding: 8bit Subject: [Sip] Question about entities SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello all Anybody can help me to find information to buy the entities of SIP or to download them free on the Internet. Thank you in advance _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 6 06:57:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14167 for ; Tue, 6 May 2003 06:57:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46B5iS10706 for sip-archive@odin.ietf.org; Tue, 6 May 2003 07:05:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46B0i810455; Tue, 6 May 2003 07:00:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Ap0810090 for ; Tue, 6 May 2003 06:51:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13951 for ; Tue, 6 May 2003 06:42:03 -0400 (EDT) From: rakhan@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Czvd-0004rr-00 for sip@ietf.org; Tue, 06 May 2003 06:44:09 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19CzvX-0004rc-00 for sip@ietf.org; Tue, 06 May 2003 06:44:03 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h46AfcX07755 for ; Tue, 6 May 2003 16:11:38 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h46Afb907745; Tue, 6 May 2003 16:11:37 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h46Aig117221; Tue, 6 May 2003 16:14:42 +0530 (IST) Subject: Re: [Sip] Question about entities SIP To: Hassan CHOUMAR Cc: sip@ietf.org Date: Tue, 6 May 2003 16:09:43 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 06/05/2003 04:09:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, One of helpful sites is vovida.org regards Rayees Hassan CHOUMAR @ietf.org on 05/06/2003 02:51:32 PM Sent by: sip-admin@ietf.org To: sip@ietf.org cc: Subject: [Sip] Question about entities SIP Hello all Anybody can help me to find information to buy the entities of SIP or to download them free on the Internet. Thank you in advance _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 mailnull@www1.ietf.org Tue May 6 07:54:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15898 for ; Tue, 6 May 2003 07:54:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46C3Oa15223 for sip-archive@odin.ietf.org; Tue, 6 May 2003 08:03:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46C33815194; Tue, 6 May 2003 08:03:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Bqt814617 for ; Tue, 6 May 2003 07:52:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15375 for ; Tue, 6 May 2003 07:43:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D0tI-0005C2-00 for sip@ietf.org; Tue, 06 May 2003 07:45:48 -0400 Received: from [218.36.19.10] (helo=iftel.brain21.com) by ietf-mx with esmtp (Exim 4.12) id 19D0tC-0005Au-00 for sip@ietf.org; Tue, 06 May 2003 07:45:42 -0400 Received: from shpark ([218.36.19.189]) by iftel.brain21.com (8.11.6+Sun/8.11.4) with SMTP id h46BhZ407634; Tue, 6 May 2003 20:43:35 +0900 (KST) Message-ID: <006001c313c5$619d4e10$bd1324da@shpark> From: =?utf-8?B?67CV7Iq57ZuI?= To: "Hassan CHOUMAR" , References: <20030506101545.2441FC21BE@molure.int-evry.fr> Subject: Re: [Sip] Question about entities SIP Date: Tue, 6 May 2003 20:48:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h46Bqu814618 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Hassan, I got some of you want. #1 SIP free server and simple test ua. (vocal) http://www.vovida.org/applications/downloads/vocal/ #2 light weight SIP Stack (osip) http://www.gnu.org/software/osip/ #3 linux sip phone (using osip) http://www.linphone.org I hope these will help you. Regards, Surym shp ----- Original Message ----- From: "Hassan CHOUMAR" To: Sent: Tuesday, May 06, 2003 6:21 PM Subject: [Sip] Question about entities SIP > Hello all > Anybody can help me to find information to buy the entities of SIP or > to download them free on the Internet. > Thank you in advance > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Tue May 6 08:09:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16546 for ; Tue, 6 May 2003 08:09:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46CHiX17036 for sip-archive@odin.ietf.org; Tue, 6 May 2003 08:17:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46CHP817009; Tue, 6 May 2003 08:17:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46CGZ816978 for ; Tue, 6 May 2003 08:16:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16428 for ; Tue, 6 May 2003 08:07:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D1GB-0005RB-00 for sip@ietf.org; Tue, 06 May 2003 08:09:28 -0400 Received: from u25.gpu114.samsung.co.kr ([203.254.224.25] helo=mailout2.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19D1G6-0005QM-00 for sip@ietf.org; Tue, 06 May 2003 08:09:22 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HEG00601SDNBL@mailout2.samsung.com> for sip@ietf.org; Tue, 06 May 2003 21:08:11 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HEG00HV1SDMSF@mailout2.samsung.com> for sip@ietf.org; Tue, 06 May 2003 21:08:10 +0900 (KST) Received: from RANJITKUMAR ([107.108.7.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HEG008T2SDKY0@mmp1.samsung.com> for sip@ietf.org; Tue, 06 May 2003 21:08:10 +0900 (KST) Date: Tue, 06 May 2003 17:34:47 +0530 From: Ranjit Avasarala Subject: RE: [Sip] Question about entities SIP In-reply-to: <20030506101545.2441FC21BE@molure.int-evry.fr> To: "'Hassan CHOUMAR'" , sip@ietf.org Reply-to: ranjitk@samsung.com Message-id: <005801c313c7$b1353620$e9076c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT U can refer http://www.sipcentre.com Regards Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Hassan CHOUMAR Sent: Tuesday, May 06, 2003 2:52 PM To: sip@ietf.org Subject: [Sip] Question about entities SIP Hello all Anybody can help me to find information to buy the entities of SIP or to download them free on the Internet. Thank you in advance _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 mailnull@www1.ietf.org Tue May 6 14:40:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02528 for ; Tue, 6 May 2003 14:40:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46ImrK17433 for sip-archive@odin.ietf.org; Tue, 6 May 2003 14:48:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46ImK817401; Tue, 6 May 2003 14:48:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46IjB817294 for ; Tue, 6 May 2003 14:45:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02474 for ; Tue, 6 May 2003 14:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7KM-0001Hg-00 for sip@ietf.org; Tue, 06 May 2003 14:38:10 -0400 Received: from [194.185.97.41] (helo=gsp02-c08d1.vodafone.it) by ietf-mx with esmtp (Exim 4.12) id 19D7KL-0001HW-00 for sip@ietf.org; Tue, 06 May 2003 14:38:10 -0400 Received: from loretosapc (127.0.0.1) by gsp02-c08d1.vodafone.it (NPlex 5.1.046) id 3E8C1E6D00004034; Tue, 6 May 2003 20:38:15 +0200 X-CNS-Auth: Message-ID: <000901c313ff$1658ea60$a3680b3e@loretosapc> From: "sal" To: "Shane McCormack" Cc: References: Subject: Re: [Sip] SIP INVITE request mapping to call object Date: Tue, 6 May 2003 20:41:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I Shane, why don't use directly Java Call Control ? two years ago I helped a guy in his degree thesis, we developed a SIP client over JCC... in those days we didn't implement NOTIFY... but I think should not be difficulto to do... But your thesis is not on SIP over SCTP ? maybe you don't remember we had several discussions some months ago (more than a year ago... if I don't wrong) Sal ----- Original Message ----- From: "Shane McCormack" To: Sent: Thursday, May 01, 2003 11:36 AM Subject: [Sip] SIP INVITE request mapping to call object > Hi all, > > I am currently working on my thesis which involves me creating a simplified > generic java API layer above SIP and parlay for easier service development. > This involves the creation of call objects similar to Java Call Control, and > Parlay. > > When mapping an incoming INVITE (or incoming requests such as a NOTIFY for > presence for other similar objects), some mapping has to be performed. My > question is would you associate a call object with a request callid or > dialog? or both. So that when some routing operation is performed by the > client application using my API the correct incoming INVITE is referenced in > the underlying SIP stack when the call object is passed back to be routed or > proxied. > > I am actually using SIP servlets for this implementation so SIP stack is not > correct term to use. > > Regards > > Shane McCormack > > Research Assistant, > TSSG, Confederation House, > Waterford Business Park, Cork Road, > Waterford, Co. Waterford. > > Phone: +353 51 302927 Fax: +353 51 302901 > Mobile: +353 87 9955505 > http://www.tssg.org > MSN: mccormackshane@hotmail.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 mailnull@www1.ietf.org Tue May 6 18:09:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11419 for ; Tue, 6 May 2003 18:09:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46MI8n02418 for sip-archive@odin.ietf.org; Tue, 6 May 2003 18:18:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46M8B801963; Tue, 6 May 2003 18:08:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46M2m800810 for ; Tue, 6 May 2003 18:02:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10373; Tue, 6 May 2003 17:53:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAPW-0002sc-00; Tue, 06 May 2003 17:55:42 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19DAPV-0002sZ-00; Tue, 06 May 2003 17:55:41 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 6 May 2003 16:51:42 UT Subject: RE: [Sip] Question about entities SIP To: Cc: "'Hassan CHOUMAR'" , sip@ietf.org, sip-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: "Vishal Phirke" Date: Tue, 6 May 2003 17:54:58 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 05/06/2003 05:52:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , and lot more here..... http://www.ict.tuwien.ac.at/darilion/bookmarks-sip-rtp-ua.html ./vishal Ranjit Avasarala , com> Sent by: cc: 05/06/2003 08:04 AM Please respond to ranjitk U can refer http://www.sipcentre.com Regards Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Hassan CHOUMAR Sent: Tuesday, May 06, 2003 2:52 PM To: sip@ietf.org Subject: [Sip] Question about entities SIP Hello all Anybody can help me to find information to buy the entities of SIP or to download them free on the Internet. Thank you in advance _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 mailnull@www1.ietf.org Wed May 7 05:26:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21968 for ; Wed, 7 May 2003 05:26:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h479Z4P29950 for sip-archive@odin.ietf.org; Wed, 7 May 2003 05:35:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h479YW829908; Wed, 7 May 2003 05:34:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h479V0829718 for ; Wed, 7 May 2003 05:31:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21874 for ; Wed, 7 May 2003 05:21:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DL9I-0006rH-00 for sip@ietf.org; Wed, 07 May 2003 05:23:40 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19DL9H-0006r0-00 for sip@ietf.org; Wed, 07 May 2003 05:23:39 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HEI00901FBM8O@siemenscomms.co.uk> for sip@ietf.org; Wed, 07 May 2003 10:21:44 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HEI00942F7W71@siemenscomms.co.uk> for sip@ietf.org; Wed, 07 May 2003 10:19:08 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 07 May 2003 10:19:42 +0100 Content-return: allowed Date: Wed, 07 May 2003 10:19:55 +0100 From: "Elwell, John" To: "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sip] UPDATE and P-Asserted-ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT In RFC3325 section 9.1 it indicates that P-Asserted-ID is not allowed in UPDATE. Does anyone know the reason for this? A useful application would be to indicate a changed asserted identity when a change of party occurs in a legacy network (e.g., due to transfer). If not allowed in UPDATE, a re-INVITE would need to be used, but this introduces an extra message. John Elwell (john.elwell@siemens.com) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 7 11:07:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05087 for ; Wed, 7 May 2003 11:07:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47FGEc25070 for sip-archive@odin.ietf.org; Wed, 7 May 2003 11:16:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47FEh824973; Wed, 7 May 2003 11:14:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47F49823603 for ; Wed, 7 May 2003 11:04:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04777 for ; Wed, 7 May 2003 10:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQLa-00026S-00 for sip@ietf.org; Wed, 07 May 2003 10:56:42 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19DQLa-00026A-00 for sip@ietf.org; Wed, 07 May 2003 10:56:42 -0400 Received: from unity.cisco.com (evvbu-exchange-100tx.cisco.com [64.101.140.74]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with SMTP id h47Ev27H028660; Wed, 7 May 2003 10:57:03 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] UPDATE and P-Asserted-ID Date: Wed, 7 May 2003 09:57:02 -0500 Message-ID: Thread-Topic: [Sip] UPDATE and P-Asserted-ID Thread-Index: AcMUfP4oLfLbpefiQHWicozGFdW5IQAKzGYg From: "Henry Chen" To: "Elwell, John" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47F49823604 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agreed and sometimes Update is better than re-Invite if we need to avoid mid-dialog media session changes. Thanks, Henry > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, May 07, 2003 4:20 AM > To: 'sip@ietf.org' > Subject: [Sip] UPDATE and P-Asserted-ID > > > In RFC3325 section 9.1 it indicates that P-Asserted-ID is not > allowed in > UPDATE. Does anyone know the reason for this? A useful > application would be > to indicate a changed asserted identity when a change of > party occurs in a > legacy network (e.g., due to transfer). If not allowed in UPDATE, a > re-INVITE would need to be used, but this introduces an extra message. > > John Elwell (john.elwell@siemens.com) > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 7 14:15:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10910 for ; Wed, 7 May 2003 14:15:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47IOr509110 for sip-archive@odin.ietf.org; Wed, 7 May 2003 14:24:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47INo809007; Wed, 7 May 2003 14:23:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47IHp808593 for ; Wed, 7 May 2003 14:17:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10652 for ; Wed, 7 May 2003 14:08:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTMy-0003RV-00 for sip@ietf.org; Wed, 07 May 2003 14:10:20 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19DTMx-0003Qj-00 for sip@ietf.org; Wed, 07 May 2003 14:10:19 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47IAfX12232 for ; Wed, 7 May 2003 14:10:41 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 19:10:40 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00877ADB5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Elwell, John" , "'sip@ietf.org'" Subject: RE: [Sip] UPDATE and P-Asserted-ID Date: Wed, 7 May 2003 19:10:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I believe the thinking when the document was developed was essentially to allow it in methods that either initiated a dialog, or were sent outside of a dialog. There was therefore no intent to cover reINVITE at that time, although I do not think it was explicitly excluded in the RFC. I am not sure how the BYE got added in respect of this, maybe someone else can clarify. The NOTIFY is there in respect of a NOTIFY that confirms a SUBSCRIBE dialog. This would allow the exchange of identities between the end users under these circumstances. From what you are indicating, it looks like you would want to extend the above to cover target refresh requests. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 07 May 2003 10:20 > To: 'sip@ietf.org' > Subject: [Sip] UPDATE and P-Asserted-ID > > > In RFC3325 section 9.1 it indicates that P-Asserted-ID is not > allowed in > UPDATE. Does anyone know the reason for this? A useful > application would be > to indicate a changed asserted identity when a change of > party occurs in a > legacy network (e.g., due to transfer). If not allowed in UPDATE, a > re-INVITE would need to be used, but this introduces an extra message. > > John Elwell (john.elwell@siemens.com) > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 7 16:25:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16305 for ; Wed, 7 May 2003 16:25:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47KYFK19835 for sip-archive@odin.ietf.org; Wed, 7 May 2003 16:34:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47KQp819344; Wed, 7 May 2003 16:26:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47KOk819271 for ; Wed, 7 May 2003 16:24:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15979 for ; Wed, 7 May 2003 16:15:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DVLl-0004ND-00 for sip@ietf.org; Wed, 07 May 2003 16:17:13 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19DVLk-0004N9-00 for sip@ietf.org; Wed, 07 May 2003 16:17:12 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h47KI48E001140; Wed, 7 May 2003 16:18:06 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] UPDATE and P-Asserted-ID Date: Wed, 7 May 2003 16:22:09 -0400 Message-ID: <002001c314d6$56888410$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In RFC3325 section 9.1 it indicates that > P-Asserted-ID is not allowed in UPDATE. Thanks for pointing it out; I had never noticed it. > Does anyone know the reason for this? > A useful application would be to indicate a > changed asserted identity when a change of > party occurs in a legacy network (e.g., due > to transfer). If not allowed in UPDATE, a > re-INVITE would need to be used, but this > introduces an extra message. Another useful application is to allow the display-name to be updated prior to answer. Without such ability, a B2BUA (or pstn gateway device) would need to delay sending INVITE while waiting to obtain display-name from the pstn network or a remote database. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 8 01:21:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00994 for ; Thu, 8 May 2003 01:21:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h485UN928783 for sip-archive@odin.ietf.org; Thu, 8 May 2003 01:30:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h485Tj828679; Thu, 8 May 2003 01:29:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h485Pa828564 for ; Thu, 8 May 2003 01:25:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00859 for ; Thu, 8 May 2003 01:15:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ddmx-0007mU-00 for sip@ietf.org; Thu, 08 May 2003 01:17:51 -0400 Received: from shardagate.mahindrabt.com ([203.124.158.2]) by ietf-mx with esmtp (Exim 4.12) id 19Ddmv-0007mR-00 for sip@ietf.org; Thu, 08 May 2003 01:17:49 -0400 Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h485IWZQ010767 for ; Thu, 8 May 2003 10:48:38 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 08 May 2003 10:33:53 +0530 Date: Thu, 08 May 2003 10:33:53 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: ashishn@mahindrabt.com Received: from dscp00212 ([10.5.3.103]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id KAA03898; Thu, 8 May 2003 10:47:58 +0530 From: "Ashish Naik" To: "Santharam, Arun [CC]" , "Sip@Ietf. Org" Subject: RE: [Sip] Session Mobility in SIP Date: Thu, 8 May 2003 10:52:32 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C3154F.ED2E4CA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <28B9108644E492469B911D587AABC97C0169534D@PKDWB01C.ad.sprint.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C3154F.ED2E4CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ok. Is there any specific document on IETF and 3GPP that can explain how it is being addressed ? Ragards, Ashish Naik CoE Mobile Computing ----------------------------------- Phone 4018100 Ext 3070 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Santharam, Arun [CC] Sent: Wednesday, April 09, 2003 9:42 PM To: Ashish Naik; Sip@Ietf. Org Subject: RE: [Sip] Session Mobility in SIP Ashish, Please find comments inline. Thank you arun -----Original Message----- From: Ashish Naik [mailto:ashishn@mahindrabt.com] Sent: Wednesday, April 09, 2003 4:01 AM To: Sip@Ietf. Org Subject: [Sip] Session Mobility in SIP How is SIP going to address session mobility ? Is there any initiative taken up for this ? > This has been addressed in 3GPP standards. Please refer to the 3GPP All IP architecture specifications. SIP is said to be a better alternative than Mobile IP. Can I have some latest development document references ? > SIP is not going to replace Mobile IP. It is going to leverage Mobile IP for session management in 3G wireless networks. Regards, Ashish Naik ------------------- CoE Mobile Computing Phone: 4018100 Ext 3070 ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_002F_01C3154F.ED2E4CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ok. Is=20 there any specific document on IETF and 3GPP that can explain how it is = being=20 addressed  ?
 
 
Ragards,
Ashish=20 Naik
CoE = Mobile=20 Computing
-----------------------------------
Phone = 4018100 Ext=20 3070
 
-----Original Message-----
From: = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of Santharam, Arun=20 [CC]
Sent: Wednesday, April 09, 2003 9:42 PM
To: = Ashish=20 Naik; Sip@Ietf. Org
Subject: RE: [Sip] Session Mobility in=20 SIP

Ashish,

 

Please find = comments=20 inline.

 

Thank=20 you

arun

 

-----Original=20 Message-----
From: = Ashish=20 Naik [mailto:ashishn@mahindrabt.com]
Sent: Wednesday, April 09,=20 2003 4:01=20 AM
To: Sip@Ietf. Org
Subject: [Sip] Session Mobility = in=20 SIP

 

How is SIP going to = address=20 session mobility ? Is there any initiative taken up for this ?=20

 

> This = has been=20 addressed in 3GPP standards. Please refer to the 3GPP All IP = architecture=20 specifications.

 

SIP is said to be a = better=20 alternative than Mobile IP. Can I have some latest development = document=20 references ?

 

 

> =  SIP is not=20 going to replace Mobile IP. It is going to leverage Mobile IP for = session=20 management in 3G wireless networks.

 

 

Regards,
Ashish=20 Naik
-------------------
CoE Mobile Computing
Phone: 4018100 = Ext 3070=20

 


***************************= ******************************
Disclaimer

This=20 message (including any attachments) contains
confidential = information=20 intended for a specific
individual and purpose, and is protected = by law.=20
If you are not the intended recipient, you should
delete this = message=20 and are hereby notified that
any disclosure, copying, or = distribution of=20 this
message, or the taking of any action based on it,
is = strictly=20 = prohibited.

******************************************************= ***
Visit=20 us at http://www.mahindrabt.com


*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_002F_01C3154F.ED2E4CA0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 8 04:22:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15775 for ; Thu, 8 May 2003 04:22:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h488VQ420404 for sip-archive@odin.ietf.org; Thu, 8 May 2003 04:31:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h488V3820376; Thu, 8 May 2003 04:31:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h488T1820266 for ; Thu, 8 May 2003 04:29:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15716 for ; Thu, 8 May 2003 04:19:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DgeO-00012g-00 for sip@ietf.org; Thu, 08 May 2003 04:21:12 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19DgeN-00012G-00 for sip@ietf.org; Thu, 08 May 2003 04:21:12 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HEK00901771SK@siemenscomms.co.uk> for sip@ietf.org; Thu, 08 May 2003 09:21:01 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HEK009AM76XMA@siemenscomms.co.uk>; Thu, 08 May 2003 09:20:57 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 08 May 2003 09:21:31 +0100 Content-return: allowed Date: Thu, 08 May 2003 09:21:53 +0100 From: "Elwell, John" Subject: RE: [Sip] UPDATE and P-Asserted-ID To: "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Keith, Thanks for your response. However, I do not wish to cover target refresh. As I understand from section 12 of RFC3261, local and remote targets are derived from Contact headers. The scenario I have in mind is where something happens behind a gateway. However, the gateway remains the same and therefore it does not need to generate a new Contact header. John (john.elwell@siemens.com) > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 07 May 2003 19:11 > To: Elwell, John; 'sip@ietf.org' > Subject: RE: [Sip] UPDATE and P-Asserted-ID > > > I believe the thinking when the document was developed was > essentially to allow it in methods that either initiated a > dialog, or were sent outside of a dialog. There was therefore > no intent to cover reINVITE at that time, although I do not > think it was explicitly excluded in the RFC. I am not sure > how the BYE got added in respect of this, maybe someone else > can clarify. The NOTIFY is there in respect of a NOTIFY that > confirms a SUBSCRIBE dialog. > > This would allow the exchange of identities between the end > users under these circumstances. > > From what you are indicating, it looks like you would want to > extend the above to cover target refresh requests. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 07 May 2003 10:20 > > To: 'sip@ietf.org' > > Subject: [Sip] UPDATE and P-Asserted-ID > > > > > > In RFC3325 section 9.1 it indicates that P-Asserted-ID is not > > allowed in > > UPDATE. Does anyone know the reason for this? A useful > > application would be > > to indicate a changed asserted identity when a change of > > party occurs in a > > legacy network (e.g., due to transfer). If not allowed in UPDATE, a > > re-INVITE would need to be used, but this introduces an > extra message. > > > > John Elwell (john.elwell@siemens.com) > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 8 09:43:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22399 for ; Thu, 8 May 2003 09:43:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Dr2G13170 for sip-archive@odin.ietf.org; Thu, 8 May 2003 09:53:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48DqR813132; Thu, 8 May 2003 09:52:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Do1812968 for ; Thu, 8 May 2003 09:50:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22301 for ; Thu, 8 May 2003 09:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dlev-0002vh-00 for sip@ietf.org; Thu, 08 May 2003 09:42:05 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Dleu-0002vD-00 for sip@ietf.org; Thu, 08 May 2003 09:42:04 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48DgRa05811 for ; Thu, 8 May 2003 09:42:27 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 May 2003 14:42:26 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED16@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Ashish Naik'" , "Santharam, Arun [CC]" , "Sip@Ietf. Org" Subject: RE: [Sip] Session Mobility in SIP Date: Thu, 8 May 2003 14:42:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31567.A87B74C6" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C31567.A87B74C6 Content-Type: text/plain; charset="iso-8859-1" Your best starting point to see the architecture is 3GPP TS 23.228, with reference to 3GPP TS 23.002 to see how these entities fit together into the entire 3GPP architecture. The SIP protocol application is covered in 3GPP TS 24.229 with example flows in 3GPP TS 24.228. These documents may be found at: ftp://ftp.3gpp.org/Specs/latest/Rel-5/ 3GPP uses these specifications over GPRS to provide mobility. There is a parallel set of 3GPP2 specifications, substantially of common text, that uses the same architecture over mobile IP, instead of GPRS. These documents are currently in 3GPP2 comment and review. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com -----Original Message----- From: Ashish Naik [mailto:ashishn@mahindrabt.com] Sent: 08 May 2003 06:23 To: Santharam, Arun [CC]; Sip@Ietf. Org Subject: RE: [Sip] Session Mobility in SIP ok. Is there any specific document on IETF and 3GPP that can explain how it is being addressed ? Ragards, Ashish Naik CoE Mobile Computing ----------------------------------- Phone 4018100 Ext 3070 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Santharam, Arun [CC] Sent: Wednesday, April 09, 2003 9:42 PM To: Ashish Naik; Sip@Ietf. Org Subject: RE: [Sip] Session Mobility in SIP Ashish, Please find comments inline. Thank you arun -----Original Message----- From: Ashish Naik [mailto:ashishn@mahindrabt.com] Sent: Wednesday, April 09, 2003 4:01 AM To: Sip@Ietf. Org Subject: [Sip] Session Mobility in SIP How is SIP going to address session mobility ? Is there any initiative taken up for this ? > This has been addressed in 3GPP standards. Please refer to the 3GPP All IP architecture specifications. SIP is said to be a better alternative than Mobile IP. Can I have some latest development document references ? > SIP is not going to replace Mobile IP. It is going to leverage Mobile IP for session management in 3G wireless networks. Regards, Ashish Naik ------------------- CoE Mobile Computing Phone: 4018100 Ext 3070 ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------_=_NextPart_001_01C31567.A87B74C6 Content-Type: text/html; charset="iso-8859-1"
Your best starting point to see the architecture is 3GPP TS 23.228, with reference to 3GPP TS 23.002 to see how these entities fit together into the entire 3GPP architecture.
 
The SIP protocol application is covered in 3GPP TS 24.229 with example flows in 3GPP TS 24.228.
 
These documents may be found at:
 
 
3GPP uses these specifications over GPRS to provide mobility.
 
There is a parallel set of 3GPP2 specifications, substantially of common text, that uses the same architecture over mobile IP, instead of GPRS. These documents are currently in 3GPP2 comment and review.
 
regards
 
Keith
 
 
 

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

-----Original Message-----
From: Ashish Naik [mailto:ashishn@mahindrabt.com]
Sent: 08 May 2003 06:23
To: Santharam, Arun [CC]; Sip@Ietf. Org
Subject: RE: [Sip] Session Mobility in SIP

ok. Is there any specific document on IETF and 3GPP that can explain how it is being addressed  ?
 
 
Ragards,
Ashish Naik
CoE Mobile Computing
-----------------------------------
Phone 4018100 Ext 3070
 
-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Santharam, Arun [CC]
Sent: Wednesday, April 09, 2003 9:42 PM
To: Ashish Naik; Sip@Ietf. Org
Subject: RE: [Sip] Session Mobility in SIP

Ashish,

 

Please find comments inline.

 

Thank you

arun

 

-----Original Message-----
From: Ashish Naik [mailto:ashishn@mahindrabt.com]
Sent: Wednesday, April 09, 2003 4:01 AM
To: Sip@Ietf. Org
Subject: [Sip] Session Mobility in SIP

 

How is SIP going to address session mobility ? Is there any initiative taken up for this ?

 

> This has been addressed in 3GPP standards. Please refer to the 3GPP All IP architecture specifications.

 

SIP is said to be a better alternative than Mobile IP. Can I have some latest development document references ?

 

 

>  SIP is not going to replace Mobile IP. It is going to leverage Mobile IP for session management in 3G wireless networks.

 

 

Regards,
Ashish Naik
-------------------
CoE Mobile Computing
Phone: 4018100 Ext 3070

 


*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com


*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------_=_NextPart_001_01C31567.A87B74C6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 9 04:49:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09618 for ; Fri, 9 May 2003 04:49:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h498xiS16404 for sip-archive@odin.ietf.org; Fri, 9 May 2003 04:59:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h498wh816374; Fri, 9 May 2003 04:58:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h498m7815963 for ; Fri, 9 May 2003 04:48:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09413 for ; Fri, 9 May 2003 04:37:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E3Pv-0002gb-00 for sip@ietf.org; Fri, 09 May 2003 04:39:47 -0400 Received: from mirlo-sdit.dit.upm.es ([138.4.5.18] helo=mirlo.dit.upm.es) by ietf-mx with esmtp (Exim 4.12) id 19E3Pr-0002gS-00 for sip@ietf.org; Fri, 09 May 2003 04:39:43 -0400 Received: from Perdiz (perdiz [138.4.50.3]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id IAA29940 for ; Fri, 9 May 2003 08:40:28 GMT From: =?Windows-1252?Q?Manuel_Moreno_Mart=EDn?= To: "Sip" Date: Fri, 9 May 2003 10:38:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-MIME-Autoconverted: from 8bit to quoted-printable by mirlo.dit.upm.es id IAA29940 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h498m7815964 Subject: [Sip] question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Please I want to clarify me in relation to the following affirmation that appears in the page 125 of RFC 3261 "The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other hand, requests of other methods are expected to complete rapidly. Because of the non-INVITE transaction's reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests." Then, "The long delays expected for sending a response argue for a three-way handshake " only for this the "three-way handshake"??? Aren´t there others reasons?? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 9 05:09:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09994 for ; Fri, 9 May 2003 05:09:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h499JZ818248 for sip-archive@odin.ietf.org; Fri, 9 May 2003 05:19:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h499JG818223; Fri, 9 May 2003 05:19:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h473Wk824513 for ; Tue, 6 May 2003 23:32:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18927 for ; Tue, 6 May 2003 23:23:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DFYj-0004jy-00 for sip@ietf.org; Tue, 06 May 2003 23:25:33 -0400 Received: from [207.44.196.29] (helo=bharatmail.com) by ietf-mx with esmtp (Exim 4.12) id 19DFYj-0004jv-00 for sip@ietf.org; Tue, 06 May 2003 23:25:33 -0400 Received: from server1.bharatmart.com (ensim.rackshack.net [207.44.196.29]) by bharatmail.com (8.11.6/8.11.6) with ESMTP id h4764pV06153 for sip@ietf.org; Wed, 7 May 2003 01:04:51 -0500 Message-Id: <200305070604.h4764pV06153@bharatmail.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: murali To: sip@ietf.org Date: Wed May 7 08:56:23 2003 Content-Transfer-Encoding: binary Subject: [Sip] Multiple header presence Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: binary Hi, In section 7.3.1 of RFC 3261 it says "The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy-Authenticate, and Proxy-Authorization header fields. Multiple header field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row." Could any on tell me the possibility wherein we can receive multiple headers of the above types?? Thanks & Regards, Murali ------- Murali Voleti, #503,Maheswari complex, Masab Tank, Hyderabad Tele:(040) 6502272 ext:211 _____________________________________________________________ Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.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 mailnull@www1.ietf.org Fri May 9 05:23:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10306 for ; Fri, 9 May 2003 05:23:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h499XB919056 for sip-archive@odin.ietf.org; Fri, 9 May 2003 05:33:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h499Wp818992; Fri, 9 May 2003 05:32:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h499Tx818789 for ; Fri, 9 May 2003 05:29:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10214 for ; Fri, 9 May 2003 05:19:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E44R-0002uU-00 for sip@ietf.org; Fri, 09 May 2003 05:21:39 -0400 Received: from [61.144.161.2] (helo=mta0) by ietf-mx with esmtp (Exim 4.12) id 19E44P-0002uG-00 for sip@ietf.org; Fri, 09 May 2003 05:21:38 -0400 Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HEM00J2R4FTHY@mta0.huawei.com> for sip@ietf.org; Fri, 09 May 2003 17:16:47 +0800 (CST) Date: Fri, 09 May 2003 14:48:03 +0530 From: "Nataraju A.B." Subject: Re: [Sip] question To: =?Windows-1252?Q?Manuel_Moreno_Mart=EDn?= , Sip Message-id: <008101c3160b$e653aa80$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_cAS96TCBhkkvCq8t0aqfrQ)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_cAS96TCBhkkvCq8t0aqfrQ) Content-type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable The coments inline. Regards, -Nataraju A.B. ----- Original Message -----=20 From: Manuel Moreno Mart=EDn=20 To: Sip=20 Sent: Friday, May 09, 2003 2:08 PM Subject: [Sip] question Please I want to clarify me in relation to the following affirmation that appears in the page 125 of RFC 3261 "The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is = required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other hand, requests of other methods are expected to complete rapidly. Because of the non-INVITE transaction's reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests." Then, "The long delays expected for sending a response argue for a three-way handshake " only for this the "three-way handshake"??? [Nataraju A.B.] The other reasons are : we can always expect the user = intervension need much more time than automatic response. the other = tranactions normally does not need the human intervension.=20 Then need for 3-way handshake could be because the 200 response = constitutes the 2nd half part the dilaog component(To-tag). where as for = the mid-dialog transactions 2-way handshake is enough (3-way handshake = not required, because teh dlg is already established) Aren=B4t there others reasons?? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --Boundary_(ID_cAS96TCBhkkvCq8t0aqfrQ) Content-type: text/html; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable
The coments inline.
 
Regards,
-Nataraju A.B.
----- Original Message -----
From:=20 Manuel=20 Moreno Mart=EDn
To: Sip
Sent: Friday, May 09, 2003 2:08 = PM
Subject: [Sip] question


Please

I want to clarify me in relation to the = following=20 affirmation that
appears in the page 125 of RFC = 3261


"The INVITE=20 transaction is different from those of other methods
   = because=20 of its extended duration.  Normally, human input is=20 required
   in order to respond to an INVITE.  The = long=20 delays expected for
   sending a response argue for a = three-way=20 handshake.  On the other
   hand, requests of other = methods=20 are expected to complete rapidly.
   Because of the = non-INVITE=20 transaction's reliance on a two-way
   handshake, TUs = SHOULD=20 respond immediately to non-INVITE requests."

Then,

"The = long=20 delays expected for
   sending a response argue for a = three-way=20 handshake "

only for this the "three-way handshake"???
[Nataraju A.B.] The other reasons are : we can = always expect=20 the user intervension need much more time than automatic response. the = other=20 tranactions normally does not need the human intervension. =
 
Then need for 3-way handshake could be because the = 200=20 response constitutes the 2nd half part the dilaog component(To-tag). = where as=20 for the mid-dialog transactions 2-way handshake is enough (3-way = handshake not=20 required, because teh dlg is already established)

Aren=B4t there others=20 reasons??

Thank=20 = you

Manuel

_______________________________________________<= BR>Sip=20 mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip
--Boundary_(ID_cAS96TCBhkkvCq8t0aqfrQ)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 9 05:44:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10898 for ; Fri, 9 May 2003 05:44:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h499sLZ21507 for sip-archive@odin.ietf.org; Fri, 9 May 2003 05:54:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h499rQ821455; Fri, 9 May 2003 05:53:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h499q8821417 for ; Fri, 9 May 2003 05:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10841 for ; Fri, 9 May 2003 05:41:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E4Pq-00035V-00 for sip@ietf.org; Fri, 09 May 2003 05:43:47 -0400 Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx with esmtp (Exim 4.12) id 19E4Pq-00035J-00 for sip@ietf.org; Fri, 09 May 2003 05:43:46 -0400 Received: from iowa.cselt.it (iowa.cselt.it [163.162.4.49]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HEM001FJ4B659@dns2.cselt.it> for sip@ietf.org; Fri, 09 May 2003 11:13:54 +0200 (MEST) Received: from iowa.cselt.it ([163.162.4.49]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 09 May 2003 11:29:06 +0200 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 09 May 2003 11:29:06 +0200 Date: Fri, 09 May 2003 11:29:05 +0200 From: Goix Walter To: sip@ietf.org Message-id: <9620749A0C40FB49B72994B11B077C5D9FEE29@EXC2K01A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Importance: normal Priority: normal Thread-Topic: Media Server info notification Thread-Index: AcMWDWrtxZ0KjmfOS9uezguT4M8uHw== content-class: urn:content-classes:message X-OriginalArrivalTime: 09 May 2003 09:29:06.0234 (UTC) FILETIME=[6FC911A0:01C3160D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h499q8821418 Subject: [Sip] Media Server info notification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Is there any recent standard work on the use of SIP by media servers/IVR to send out params/collect digits/... to some other SIP entity ? I know there are many proprietary implementations but I'm not aware about a common agreement that solves this issue. Any INFO/Info-Type or Event package solution? Any suggestion appreciated. Thanks in advance. Regards, Walter Goix ________________________ Laurent-Walter Goix Telecom Italia S.p.A. Telecom Italia Lab - StarSIP Services Innovation - Intelligent Services and Platforms (SI/P) Via Reiss Romoli 274 I-10148 Torino (Italy) Tel. +39 011 228 5046 Fax +39 011 228 5069 E-mail mailto:laurentwalter.goix@telecomitalia.it ________________________ Visit us @ http://starsip.telecomitalialab.com ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 9 06:35:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11941 for ; Fri, 9 May 2003 06:35:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49AjNI26291 for sip-archive@odin.ietf.org; Fri, 9 May 2003 06:45:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Aj4826278; Fri, 9 May 2003 06:45:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Ai0826179 for ; Fri, 9 May 2003 06:44:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11888 for ; Fri, 9 May 2003 06:33:34 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E5E1-0003NN-00 for sip@ietf.org; Fri, 09 May 2003 06:35:37 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19E5E0-0003NK-00 for sip@ietf.org; Fri, 09 May 2003 06:35:36 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h49AaT700540 for ; Fri, 9 May 2003 13:36:29 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 9 May 2003 13:36:28 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 9 May 2003 13:36:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Multiple header presence Date: Fri, 9 May 2003 13:36:27 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE75AE@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Multiple header presence Thread-Index: AcMWC9AI/dRrDbL2TFSUcr1gIb5mZQACtd2w To: , X-OriginalArrivalTime: 09 May 2003 10:36:28.0178 (UTC) FILETIME=[D8F8C720:01C31616] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49Ai0826180 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Forked request. The proxy that forked will collect all the challenges into one response and forward upstream that response. Regards, Hisham > -----Original Message----- > From: ext murali [mailto:muraliv@bharatmail.com] > Sent: Wednesday, May 07, 2003 11:56 AM > To: sip@ietf.org > Subject: [Sip] Multiple header presence > > > Hi, > > In section 7.3.1 of RFC 3261 it says > > "The exceptions to this rule are the WWW-Authenticate, > Authorization, Proxy-Authenticate, and Proxy-Authorization > header fields. Multiple header field rows with these names > MAY be present in a message, but since their grammar does not > follow the general form listed in Section 7.3, they MUST > NOT be combined into a single header field row." > > Could any on tell me the possibility wherein we can receive > multiple headers of the above types?? > > Thanks & Regards, > Murali > > ------- > Murali Voleti, > #503,Maheswari complex, > Masab Tank, > Hyderabad > Tele:(040) 6502272 ext:211 > > _____________________________________________________________ > Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.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 mailnull@www1.ietf.org Fri May 9 07:57:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13177 for ; Fri, 9 May 2003 07:57:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49C7r032604 for sip-archive@odin.ietf.org; Fri, 9 May 2003 08:07:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49C7X832591; Fri, 9 May 2003 08:07:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49C13831500 for ; Fri, 9 May 2003 08:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13124 for ; Fri, 9 May 2003 07:50:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E6QZ-0003kl-00 for sip@ietf.org; Fri, 09 May 2003 07:52:39 -0400 Received: from [61.144.161.2] (helo=mta0) by ietf-mx with esmtp (Exim 4.12) id 19E6QY-0003kZ-00 for sip@ietf.org; Fri, 09 May 2003 07:52:39 -0400 Received: from p70008 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HEM00JC6BLMLK@mta0.huawei.com> for sip@ietf.org; Fri, 09 May 2003 19:51:24 +0800 (CST) Date: Fri, 09 May 2003 19:55:05 +0800 From: Prasanna Venkatesh Subject: RE: [Sip] Multiple header presence In-reply-to: <200305070604.h4764pV06153@bharatmail.com> To: murali , sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT There are 3 possibilities Possibility A: If the message traverses through 2 proxies, with both of them requiring authentication this may happen. Possibility B: This can also happen when the proxies merge forked responses. For e.g. |--B1 A--P |--B2 If both B1 and B2 challenge, then the 401 will carry two WWW-Authenticate headers. Possibility C: However, I am not sure about the third possibility where a single entity governing two realms, inserts two Authenticate headers or an entity capable of supporting more than one authentication scheme (for e.g. Basic & Digest ) inserts more than one Authenticate headers. Can somebody tell if this is allowed as per RFC-2617 or RFC-3261 Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of murali Sent: Friday, May 09, 2003 5:24 PM To: sip@ietf.org Subject: [Sip] Multiple header presence Hi, In section 7.3.1 of RFC 3261 it says "The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy-Authenticate, and Proxy-Authorization header fields. Multiple header field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row." Could any on tell me the possibility wherein we can receive multiple headers of the above types?? Thanks & Regards, Murali ------- Murali Voleti, #503,Maheswari complex, Masab Tank, Hyderabad Tele:(040) 6502272 ext:211 _____________________________________________________________ Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.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 mailnull@www1.ietf.org Fri May 9 07:58:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13214 for ; Fri, 9 May 2003 07:58:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49C8Kq32633 for sip-archive@odin.ietf.org; Fri, 9 May 2003 08:08:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49C7M832277; Fri, 9 May 2003 08:07:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49C11831494 for ; Fri, 9 May 2003 08:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13121 for ; Fri, 9 May 2003 07:50:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E6QX-0003kg-00 for sip@ietf.org; Fri, 09 May 2003 07:52:37 -0400 Received: from [61.144.161.2] (helo=mta0) by ietf-mx with esmtp (Exim 4.12) id 19E6QU-0003kZ-00 for sip@ietf.org; Fri, 09 May 2003 07:52:35 -0400 Received: from p70008 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HEM00JC6BLMLK@mta0.huawei.com> for sip@ietf.org; Fri, 09 May 2003 19:51:23 +0800 (CST) Date: Fri, 09 May 2003 19:55:04 +0800 From: Prasanna Venkatesh Subject: RE: [Sip] question In-reply-to: <008101c3160b$e653aa80$5d02120a@in.huawei.com> To: "Nataraju A.B." , =?Windows-1252?Q?Manuel_Moreno_Mart=EDn?= , Sip Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_qqoMCkGv6SmWeXpWASmVqg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_qqoMCkGv6SmWeXpWASmVqg) Content-type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE The three way handshake is also required as the 200 for the INVITE me= ssage (as of 3261) requires to carry the media information. If there is no acknowledgement for the 200, then the callee terminal has to depend o= n other mechanisms like media sensing to remove the media binding what it has= done. Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Na= taraju A.B. Sent: Friday, May 09, 2003 5:18 PM To: Manuel Moreno Mart=EDn; Sip Subject: Re: [Sip] question The coments inline. Regards, -Nataraju A.B. ----- Original Message ----- From: Manuel Moreno Mart=EDn To: Sip Sent: Friday, May 09, 2003 2:08 PM Subject: [Sip] question Please I want to clarify me in relation to the following affirmation tha= t appears in the page 125 of RFC 3261 "The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is re= quired in order to respond to an INVITE. The long delays expected fo= r sending a response argue for a three-way handshake. On the ot= her hand, requests of other methods are expected to complete rapid= ly. Because of the non-INVITE transaction's reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE reques= ts." Then, "The long delays expected for sending a response argue for a three-way handshake " only for this the "three-way handshake"??? [Nataraju A.B.] The other reasons are : we can always expect the = user intervension need much more time than automatic response. the other tranactions normally does not need the human intervension. Then need for 3-way handshake could be because the 200 response constitutes the 2nd half part the dilaog component(To-tag). where as = for the mid-dialog transactions 2-way handshake is enough (3-way handshake no= t required, because teh dlg is already established) Aren=B4t there others reasons?? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of s= ip --Boundary_(ID_qqoMCkGv6SmWeXpWASmVqg) Content-type: text/html; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable
The three way = handshake is also=20 required as the 200 for the INVITE message (as of 3261) requires to = carry the=20 media information.  If there is no acknowledgement for the 200, = then the=20 callee terminal has to depend on other mechanisms like media sensing to = remove=20 the media binding what it has done.
Cheers,
Prasanna
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Nataraju = A.B.
Sent:=20 Friday, May 09, 2003 5:18 PM
To: Manuel Moreno Mart=EDn;=20 Sip
Subject: Re: [Sip] question

The coments inline.
 
Regards,
-Nataraju = A.B.
----- Original Message -----
From:=20 Manuel=20 Moreno Mart=EDn
To: Sip
Sent: Friday, May 09, 2003 = 2:08=20 PM
Subject: [Sip] question


Please

I want to clarify me in relation to the = following=20 affirmation that
appears in the page 125 of RFC = 3261


"The=20 INVITE transaction is different from those of other = methods
  =20 because of its extended duration.  Normally, human input is=20 required
   in order to respond to an INVITE.  The = long=20 delays expected for
   sending a response argue for a = three-way=20 handshake.  On the other
   hand, requests of = other=20 methods are expected to complete rapidly.
   Because of = the=20 non-INVITE transaction's reliance on a two-way
   = handshake,=20 TUs SHOULD respond immediately to non-INVITE=20 requests."

Then,

"The long delays expected = for
  =20 sending a response argue for a three-way handshake "

only for = this=20 the "three-way handshake"???
[Nataraju A.B.] The other reasons are : we can = always=20 expect the user intervension need much more time than automatic = response.=20 the other tranactions normally does not need the human intervension. =
 
Then need for 3-way handshake could be because = the 200=20 response constitutes the 2nd half part the dilaog component(To-tag). = where=20 as for the mid-dialog transactions 2-way handshake is enough (3-way=20 handshake not required, because teh dlg is already = established)

Aren=B4t there=20 others reasons??

Thank=20 = you

Manuel

_______________________________________________<= BR>Sip=20 mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip
--Boundary_(ID_qqoMCkGv6SmWeXpWASmVqg)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 9 14:28:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26154 for ; Fri, 9 May 2003 14:28:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49IcdV01195 for sip-archive@odin.ietf.org; Fri, 9 May 2003 14:38:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Ibk801123; Fri, 9 May 2003 14:37:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Iai832675 for ; Fri, 9 May 2003 14:36:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26054 for ; Fri, 9 May 2003 14:26:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECbM-0006TM-00 for sip@ietf.org; Fri, 09 May 2003 14:28:12 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19ECbL-0006TD-00 for sip@ietf.org; Fri, 09 May 2003 14:28:11 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h49ISZct007806; Fri, 9 May 2003 11:28:36 -0700 (PDT) Received: from [128.107.170.122] ([128.107.170.122]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADZ89344; Fri, 9 May 2003 11:28:34 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 09 May 2003 11:28:32 -0700 Subject: Re: [Sip] Media Server info notification From: Cullen Jennings To: Goix Walter , sip-ietf Message-ID: In-Reply-To: <9620749A0C40FB49B72994B11B077C5D9FEE29@EXC2K01A.cselt.it> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Have a look at the app-interaction stuff and KPML. On 5/9/03 2:29 AM, "Goix Walter" wrote: > Is there any recent standard work on the use of SIP by media servers/IVR to > send out params/collect digits/... to some other SIP entity ? > > I know there are many proprietary implementations but I'm not aware about a > common agreement that solves this issue. Any INFO/Info-Type or Event package > solution? > > Any suggestion appreciated. > Thanks in advance. > Regards, > > Walter Goix > > ________________________ > Laurent-Walter Goix > Telecom Italia S.p.A. > Telecom Italia Lab - StarSIP > Services Innovation - Intelligent Services and Platforms (SI/P) > Via Reiss Romoli 274 > I-10148 Torino (Italy) > Tel. +39 011 228 5046 > Fax +39 011 228 5069 > E-mail mailto:laurentwalter.goix@telecomitalia.it > ________________________ > Visit us @ http://starsip.telecomitalialab.com > > > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by > replying to MailAdmin@tilab.com. Thank you > ==================================================================== > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Sun May 11 22:23:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17528 for ; Sun, 11 May 2003 22:23:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4C1nCq02819 for sip-archive@odin.ietf.org; Sun, 11 May 2003 21:49:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C1mDB02779; Sun, 11 May 2003 21:48:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C1hxB02663 for ; Sun, 11 May 2003 21:43:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17487 for ; Sun, 11 May 2003 22:18:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19F2vA-00044S-00 for sip@ietf.org; Sun, 11 May 2003 22:20:08 -0400 Received: from web12202.mail.yahoo.com ([216.136.173.86]) by ietf-mx with smtp (Exim 4.12) id 19F2vA-00044P-00 for sip@ietf.org; Sun, 11 May 2003 22:20:08 -0400 Message-ID: <20030512022109.25823.qmail@web12202.mail.yahoo.com> Received: from [193.95.31.32] by web12202.mail.yahoo.com via HTTP; Mon, 12 May 2003 04:21:09 CEST Date: Mon, 12 May 2003 04:21:09 +0200 (CEST) From: =?iso-8859-1?q?hajer=20ferjani?= To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] integration of sip and cops Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi all, anybody knows if there's some work on the integration of sip and cops protocols accordingly to the QoS architectures : IntServ and DiffServ. thanks for any help. regards. hajer. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.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 mailnull@www1.ietf.org Mon May 12 07:17:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08179 for ; Mon, 12 May 2003 07:17:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CAgov16959 for sip-archive@odin.ietf.org; Mon, 12 May 2003 06:42:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CAgMB16943; Mon, 12 May 2003 06:42:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CAebB16899 for ; Mon, 12 May 2003 06:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08143 for ; Mon, 12 May 2003 07:14:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FBIJ-0006tJ-00 for sip@ietf.org; Mon, 12 May 2003 07:16:35 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19FBII-0006tG-00 for sip@ietf.org; Mon, 12 May 2003 07:16:34 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA94190 for ; Mon, 12 May 2003 13:17:57 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma093991; Mon, 12 May 03 13:17:23 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Mon, 12 May 2003 13:17:59 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 12 May 2003 13:17:46 +0200 From: "A vWijk" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4CAebB16900 Subject: [Sip] Duration to re-register at registrar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I am wondering one thing. How long will it take for a UA to re-register at a registrar? E.g when changing contact information or caller preferences parameters. Thanks /A Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 12 08:06:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09671 for ; Mon, 12 May 2003 08:06:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CBW4u19911 for sip-archive@odin.ietf.org; Mon, 12 May 2003 07:32:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CBVgB19893; Mon, 12 May 2003 07:31:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CBUWB19804 for ; Mon, 12 May 2003 07:30:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09646 for ; Mon, 12 May 2003 08:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FC4b-00079Y-00 for sip@ietf.org; Mon, 12 May 2003 08:06:29 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 19FC4a-00079U-00 for sip@ietf.org; Mon, 12 May 2003 08:06:28 -0400 X-Envelope-Sender-Is: zaifeng.chen@BISC.SIEMENS.COM.CN (at relayer david.siemens.com.cn) Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.6/8.11.6) with ESMTP id h4CC7U414177 for ; Mon, 12 May 2003 20:07:33 +0800 (CST) Received: from pekw096e.cn001.siemens.net ([140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h4CC7JA17784 for ; Mon, 12 May 2003 20:07:19 +0800 (CST) Received: by pekw096e.cn001.siemens.net with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 20:07:18 +0800 Message-ID: <23BCA2174A77D111A52D00A0C967A6E20420168B@HP5> From: "Chen Zaifeng,BISC TD DEW5(BJ)" To: "'sip@ietf.org'" Date: Mon, 12 May 2003 16:51:06 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP B2BUA vs Proxy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all: I have the following questions about SIP B2BUA vs SIP proxy: 1. For service support is B2BUA better than SIP proxy? 2. Is B2BUA suitable to be used as routing entity in the following SIP/SIPT network planning schemas? -Hiberarchy structure like PSTN, which has hiberarchied proxies/routing entities. Some one believe that B2BUA can be used to substitute call stateful proxy at the edge of such a SIP/SIPT network -Flat structure, which has peered routing entities but hiberarched routing database. In this case some one believe that B2BUA is even more suitable as routing entity Thanks! Sincerely yours, Chen Zaifeng -------------------------------------------------------------------------- Beijing International Switching System Corporation Ltd. TD/DEW No. 14 Jiu Xian Qiao Road Beijing 100016, P. R. China Tel: +86-10-8457 1921 Fax: +86-10-6436 7732 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 From mailnull@www1.ietf.org Mon May 12 19:14:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08212 for ; Mon, 12 May 2003 19:14:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CMe5X09887 for sip-archive@odin.ietf.org; Mon, 12 May 2003 18:40:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CMdTB09792; Mon, 12 May 2003 18:39:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CMZKB08818 for ; Mon, 12 May 2003 18:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08113 for ; Mon, 12 May 2003 19:09:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FMRi-0005QG-00 for sip@ietf.org; Mon, 12 May 2003 19:11:02 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19FMRi-0005Q9-00 for sip@ietf.org; Mon, 12 May 2003 19:11:02 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4CNBWjF014167; Mon, 12 May 2003 16:11:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHA30543; Mon, 12 May 2003 16:05:16 -0700 (PDT) Date: Mon, 12 May 2003 16:11:36 -0700 Subject: Re: [Sip] UPDATE and P-Asserted-ID Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Drage, Keith (Keith)'" , "'sip@ietf.org'" To: "Elwell, John" From: Rohan Mahy In-Reply-To: Message-Id: <149B0336-84CF-11D7-8E16-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, I believe you still should generate a new Contact header, even if you are only changing the display name. thanks, -rohan On Thursday, May 8, 2003, at 01:21 AM, Elwell, John wrote: > Keith, > > Thanks for your response. However, I do not wish to cover target > refresh. As > I understand from section 12 of RFC3261, local and remote targets are > derived from Contact headers. The scenario I have in mind is where > something > happens behind a gateway. However, the gateway remains the same and > therefore it does not need to generate a new Contact header. > > John (john.elwell@siemens.com) > >> -----Original Message----- >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >> Sent: 07 May 2003 19:11 >> To: Elwell, John; 'sip@ietf.org' >> Subject: RE: [Sip] UPDATE and P-Asserted-ID >> >> >> I believe the thinking when the document was developed was >> essentially to allow it in methods that either initiated a >> dialog, or were sent outside of a dialog. There was therefore >> no intent to cover reINVITE at that time, although I do not >> think it was explicitly excluded in the RFC. I am not sure >> how the BYE got added in respect of this, maybe someone else >> can clarify. The NOTIFY is there in respect of a NOTIFY that >> confirms a SUBSCRIBE dialog. >> >> This would allow the exchange of identities between the end >> users under these circumstances. >> >> From what you are indicating, it looks like you would want to >> extend the above to cover target refresh requests. >> >> Keith >> >> Keith Drage >> Lucent Technologies >> Tel: +44 1793 776249 >> Email: drage@lucent.com >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens.com] >>> Sent: 07 May 2003 10:20 >>> To: 'sip@ietf.org' >>> Subject: [Sip] UPDATE and P-Asserted-ID >>> >>> >>> In RFC3325 section 9.1 it indicates that P-Asserted-ID is not >>> allowed in >>> UPDATE. Does anyone know the reason for this? A useful >>> application would be >>> to indicate a changed asserted identity when a change of >>> party occurs in a >>> legacy network (e.g., due to transfer). If not allowed in UPDATE, a >>> re-INVITE would need to be used, but this introduces an >> extra message. >>> >>> John Elwell (john.elwell@siemens.com) >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 12 19:20:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08334 for ; Mon, 12 May 2003 19:20:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CMk5K10163 for sip-archive@odin.ietf.org; Mon, 12 May 2003 18:46:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CMjbB10134; Mon, 12 May 2003 18:45:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CMc2B09763 for ; Mon, 12 May 2003 18:38:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08178 for ; Mon, 12 May 2003 19:11:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FMUE-0005Rm-00 for sip@ietf.org; Mon, 12 May 2003 19:13:38 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19FMUD-0005Rd-00 for sip@ietf.org; Mon, 12 May 2003 19:13:37 -0400 Received: from softarmor.com ([63.206.46.200]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4CNDu6o028397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 12 May 2003 18:14:08 -0500 Message-ID: <3EC02A9C.2020409@softarmor.com> Date: Mon, 12 May 2003 18:13:32 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: A vWijk CC: sip@ietf.org Subject: Re: [Sip] Duration to re-register at registrar References: In-Reply-To: X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A vWijk wrote: > I am wondering one thing. > How long will it take for a UA to re-register at a registrar? > E.g when changing contact information or caller preferences parameters. > would network RTT + 10 to 100ms sound appropriate? Or, in the event of an HTTP-style authentication on the request, 2*RTT + 20-200ms. Of course some registrars with more complex data storage models (such as LDAP) might take a little longer. Or perhaps I'm not guessing the question that you're really asking. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 12 19:22:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08393 for ; Mon, 12 May 2003 19:22:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CMm0q10232 for sip-archive@odin.ietf.org; Mon, 12 May 2003 18:48:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CMlcB10213; Mon, 12 May 2003 18:47:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CMdYB09794 for ; Mon, 12 May 2003 18:39:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08187 for ; Mon, 12 May 2003 19:13:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FMVp-0005SO-00 for sip@ietf.org; Mon, 12 May 2003 19:15:17 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19FMVo-0005Rx-00 for sip@ietf.org; Mon, 12 May 2003 19:15:16 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4CNFeND019249; Mon, 12 May 2003 16:15:42 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHA31070; Mon, 12 May 2003 16:09:29 -0700 (PDT) Date: Mon, 12 May 2003 16:15:52 -0700 Subject: Re: [Sip] Media Server info notification Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Goix Walter , sip-ietf To: Cullen Jennings From: Rohan Mahy In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit specifically: http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-01.txt http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app- interact-reqs-03.txt http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info- 00.txt http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app- interaction-framework-00.txt On Friday, May 9, 2003, at 11:28 AM, Cullen Jennings wrote: > > > Have a look at the app-interaction stuff and KPML. > > On 5/9/03 2:29 AM, "Goix Walter" wrote: > >> Is there any recent standard work on the use of SIP by media >> servers/IVR to >> send out params/collect digits/... to some other SIP entity ? >> >> I know there are many proprietary implementations but I'm not aware >> about a >> common agreement that solves this issue. Any INFO/Info-Type or Event >> package >> solution? >> >> Any suggestion appreciated. >> Thanks in advance. >> Regards, >> >> Walter Goix >> >> ________________________ >> Laurent-Walter Goix >> Telecom Italia S.p.A. >> Telecom Italia Lab - StarSIP >> Services Innovation - Intelligent Services and Platforms (SI/P) >> Via Reiss Romoli 274 >> I-10148 Torino (Italy) >> Tel. +39 011 228 5046 >> Fax +39 011 228 5069 >> E-mail mailto:laurentwalter.goix@telecomitalia.it >> ________________________ >> Visit us @ http://starsip.telecomitalialab.com >> >> >> >> ==================================================================== >> CONFIDENTIALITY NOTICE >> This message and its attachments are addressed solely to the persons >> above and may contain confidential information. If you have received >> the message in error, be informed that any use of the content hereof >> is prohibited. Please return it immediately to the sender and delete >> the message. Should you have any questions, please contact us by >> replying to MailAdmin@tilab.com. Thank you >> ==================================================================== >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@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 mailnull@www1.ietf.org Mon May 12 22:57:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12211 for ; Mon, 12 May 2003 22:57:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4D2Nk123766 for sip-archive@odin.ietf.org; Mon, 12 May 2003 22:23:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D2MhB23728; Mon, 12 May 2003 22:22:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D2HEB23573 for ; Mon, 12 May 2003 22:17:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12126 for ; Mon, 12 May 2003 22:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FPuO-0006YC-00 for sip@ietf.org; Mon, 12 May 2003 22:52:52 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 19FPuN-0006Xa-00 for sip@ietf.org; Mon, 12 May 2003 22:52:51 -0400 X-Envelope-Sender-Is: zaifeng.chen@BISC.SIEMENS.COM.CN (at relayer david.siemens.com.cn) Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.6/8.11.6) with ESMTP id h4D2r8412389; Tue, 13 May 2003 10:53:08 +0800 (CST) Received: from pekw096e.cn001.siemens.net ([140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h4D2qvA29746; Tue, 13 May 2003 10:52:58 +0800 (CST) Received: by pekw096e.cn001.siemens.net with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 10:52:56 +0800 Message-ID: <23BCA2174A77D111A52D00A0C967A6E20420168C@HP5> From: "Chen Zaifeng,BISC TD DEW5(BJ)" To: "'Arjun Roychowdhury'" Cc: "'sip@ietf.org'" Subject: ??: [Sip] SIP B2BUA vs Proxy Date: Tue, 13 May 2003 09:52:01 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4D2HEB23574 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Really appreciate your answer, dear Mr.Arjun. So according with your description may I draw the conclusion that B2BUA is mainly used for service control and should not substitute proxy as routing entity in a SIP network? Thanks! -----ԭʼÓʼþ----- ·¢¼þÈË: Arjun Roychowdhury [mailto:aroychow@hns.com] ·¢ËÍʱ¼ä: Monday, May 12, 2003 10:24 PM ÊÕ¼þÈË: Chen Zaifeng,BISC TD DEW5(BJ) ³­ËÍ: sip-implementors@cs.columbia.edu Ö÷Ìâ: Re: [Sip] SIP B2BUA vs Proxy Moving to implementors.. Inline, prefixed by ARC> 1. For service support is B2BUA better than SIP proxy? Depends on what kind of service. There are many that do not require a B2B at all and can be done by a pure proxy along with CPL, for example. (Example of such services include hunt groups, call fwd, etc. etc.) It also depends on the kind of capabilities you can expect from your participating end points. For example, in the SIP model, services such a transfer can be directly hosted on the endpoints by using REFER mechanism. However, it is possible in many deployments one cannot assume intelligent endpoints nor support for REFER and in that case, such services need to be done centrally. In a nutshell, what you plan to use as the 'service manager' depends on: a) What is the nature of service (routing based pre-call service, mid-call service etc) b) What is the network you are deploying into (assumptions on 'intelligence' of nodes) c) Scalability reqts of your network 2. Is B2BUA suitable to be used as routing entity in the following SIP/SIPT network planning schemas? -Hiberarchy structure like PSTN, which has hiberarchied proxies/routing entities. Some one believe that B2BUA can be used to substitute call stateful proxy at the edge of such a SIP/SIPT network -Flat structure, which has peered routing entities but hiberarched routing database. In this case some one believe that B2BUA is even more suitable as routing entity Again, if I just go by your requirement of the above, I dont believe a B2B is required only for this. If your question is, 'Even if I need a pure proxy ,can I achieve it by a B2B' the answer would be yes - but you need to decide why - by looking at the overall picture of your network which you would know best. For example, does your server need to kick-in mid call and perform some services which need signalling control to be performed by your server ? If not, you can do without a B2B. Even if required, can you assume that your network can support endpoints being REFERed to a b2b for mid-call services that require it ? If so, you dont need to be a B2B all the time. And so on... Also do note, a B2B has implied complexities as well, wrt e-e encryption, looping etc. You need to be aware of the same. And then, do read through previous archives, where you will come across interesting 'hybrids' such as 'transparent proxy' , 'B2B proxy' and so forth. In short, many implementors have combined the functionality of a proxy and a B2B and actually switch between these modes internally depending on the service required. Some do it by being a pure B2B and some do it by playing 'dialog id' tricks and switching between proxy and B2B (for those who cannot afford to B2B all calls all the time). Needless to say, the implementors need to be aware of the perils of doing the same and judge for themselves between the devil (above mentioned hacks) and the deep blue sea.. (not believing a world exists today that is not pure SIP ;-) Id suggest you read the following: http://www.softarmor.com/sipping/drafts/draft-ietf-sipping-service-examples-04.txt http://www.softarmor.com/sipping/drafts/draft-ietf-sipping-3pcc-03.txt http://www.ietf.org/rfc/rfc2824.txt (CPL requirements) http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-06.txt http://www1.cs.columbia.edu/sip/talks.html (some interesting papers on implementing certain services with SIP) A lot of services and how to do them are encapsulated in the above. There are more drafts for your perusal too. So basically, you need to decide. regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 13 09:28:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11343 for ; Tue, 13 May 2003 09:28:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DCsx421548 for sip-archive@odin.ietf.org; Tue, 13 May 2003 08:54:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DCsFB21496; Tue, 13 May 2003 08:54:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C71UB00555 for ; Mon, 12 May 2003 03:01:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04230 for ; Mon, 12 May 2003 03:35:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19F7sK-0005n2-00 for sip@ietf.org; Mon, 12 May 2003 03:37:32 -0400 Received: from vmailb.mclink.it ([195.110.128.107] helo=vmail.mclink.it) by ietf-mx with esmtp (Exim 4.12) id 19F7sK-0005my-00 for sip@ietf.org; Mon, 12 May 2003 03:37:32 -0400 Received: from mac (net155-146.mclink.it [195.110.155.146]) by vmail.mclink.it (8.12.6p2/8.11.3) with SMTP id h4C7cLVt049957; Mon, 12 May 2003 09:38:23 +0200 (CEST) (envelope-from d.papalilo@pointercom.it) Message-ID: <002801c31859$70d6b0e0$e774f40a@mac> From: "Donald Papalilo" To: "hajer ferjani" , Cc: "Luca Veltri" , "Stefano Salsano" References: <20030512022109.25823.qmail@web12202.mail.yahoo.com> Subject: Re: [Sip] integration of sip and cops Date: Mon, 12 May 2003 09:37:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by vmail.mclink.it id h4C7cLVt049957 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4C71VB00556 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi , here are some reference works: http://www.ietf.org/internet-drafts/draft-veltri-sip-qsip-01.txt http://www.coritel.it/projects/qsip/papers.htm Regards, Donald ----- Original Message ----- From: "hajer ferjani" To: Sent: Monday, May 12, 2003 4:21 AM Subject: [Sip] integration of sip and cops > hi all, > anybody knows if there's some work on the integration > of sip and cops protocols accordingly to the QoS > architectures : IntServ and DiffServ. > thanks for any help. > regards. > > hajer. > > > > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.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 mailnull@www1.ietf.org Tue May 13 09:50:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12049 for ; Tue, 13 May 2003 09:50:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DDGQl23600 for sip-archive@odin.ietf.org; Tue, 13 May 2003 09:16:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDAIB23262; Tue, 13 May 2003 09:10:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DClpB21036 for ; Tue, 13 May 2003 08:47:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10990 for ; Tue, 13 May 2003 09:21:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FZkR-0003of-00 for sip@ietf.org; Tue, 13 May 2003 09:23:15 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19FZkQ-0003oG-00 for sip@ietf.org; Tue, 13 May 2003 09:23:14 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HET00501UIKNH@siemenscomms.co.uk> for sip@ietf.org; Tue, 13 May 2003 14:23:09 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HET005I1UID9S@siemenscomms.co.uk>; Tue, 13 May 2003 14:23:01 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 13 May 2003 14:23:36 +0100 Content-return: allowed Date: Tue, 13 May 2003 14:23:57 +0100 From: "Elwell, John" Subject: RE: [Sip] UPDATE and P-Asserted-ID To: "'Rohan Mahy'" Cc: "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Rohan, The qsig2sip draft is silent on the subject of the contact header. So too is the ISUP-SIP draft (except on the subject of contact headers in 3xx response). It is not clear to me that a contact header should necessarily reflect the identity of the remote party in the legacy network. Therefore there may be no need to change the contact header when transfer occurs in the legacy network. Consider the following case. An INVITE request leaves the SIP network at an egress gateway to QSIG. The gateway receives a QSIG ALERTING message and sends back a 180 response containing a contact header. It would be possible for this contact header to reflect the identity of the party to whom the QSIG SETUP message was directed or, except where prevented by privacy, the identity of the party actually being alerted (can be different because of forwarding). Now, suppose after alerting but before answer the call is forwarded, so that the party who answers is not the party identified in the contact header in the 180 response. What should go in the contact header of the 200 response: the same value that was in the 180 contact header; or a different value reflecting the identity of the answering party? It is not clear to me whether the contact header is allowed to or should change in this situation. Because if is not always feasible, because of privacy, forwarding etc. for the contact header issued by a gateway always to reflect the identity of the remote party in the legacy network, I see the contact header primarily as a means of identifying the gateway, rather than the remote party. That is why the qsig2sip draft is silent on this issue - the choice of contact header is an implementation matter for the gateway. Regards, John > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 13 May 2003 00:12 > To: Elwell, John > Cc: 'Drage, Keith (Keith)'; 'sip@ietf.org' > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > John, > > I believe you still should generate a new Contact header, even if you > are only changing the display name. > > thanks, > -rohan > > On Thursday, May 8, 2003, at 01:21 AM, Elwell, John wrote: > > > Keith, > > > > Thanks for your response. However, I do not wish to cover target > > refresh. As > > I understand from section 12 of RFC3261, local and remote > targets are > > derived from Contact headers. The scenario I have in mind is where > > something > > happens behind a gateway. However, the gateway remains the same and > > therefore it does not need to generate a new Contact header. > > > > John (john.elwell@siemens.com) > > > >> -----Original Message----- > >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >> Sent: 07 May 2003 19:11 > >> To: Elwell, John; 'sip@ietf.org' > >> Subject: RE: [Sip] UPDATE and P-Asserted-ID > >> > >> > >> I believe the thinking when the document was developed was > >> essentially to allow it in methods that either initiated a > >> dialog, or were sent outside of a dialog. There was therefore > >> no intent to cover reINVITE at that time, although I do not > >> think it was explicitly excluded in the RFC. I am not sure > >> how the BYE got added in respect of this, maybe someone else > >> can clarify. The NOTIFY is there in respect of a NOTIFY that > >> confirms a SUBSCRIBE dialog. > >> > >> This would allow the exchange of identities between the end > >> users under these circumstances. > >> > >> From what you are indicating, it looks like you would want to > >> extend the above to cover target refresh requests. > >> > >> Keith > >> > >> Keith Drage > >> Lucent Technologies > >> Tel: +44 1793 776249 > >> Email: drage@lucent.com > >> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>> Sent: 07 May 2003 10:20 > >>> To: 'sip@ietf.org' > >>> Subject: [Sip] UPDATE and P-Asserted-ID > >>> > >>> > >>> In RFC3325 section 9.1 it indicates that P-Asserted-ID is not > >>> allowed in > >>> UPDATE. Does anyone know the reason for this? A useful > >>> application would be > >>> to indicate a changed asserted identity when a change of > >>> party occurs in a > >>> legacy network (e.g., due to transfer). If not allowed in > UPDATE, a > >>> re-INVITE would need to be used, but this introduces an > >> extra message. > >>> > >>> John Elwell (john.elwell@siemens.com) > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the > application of sip > >>> > >> > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 13 18:21:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02159 for ; Tue, 13 May 2003 18:21:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DLlpp02343 for sip-archive@odin.ietf.org; Tue, 13 May 2003 17:47:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DLktB02280; Tue, 13 May 2003 17:46:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DLTJB00429 for ; Tue, 13 May 2003 17:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00521 for ; Tue, 13 May 2003 18:02:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fhsu-0000B2-00 for sip@ietf.org; Tue, 13 May 2003 18:04:32 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19Fhst-0000Ai-00 for sip@ietf.org; Tue, 13 May 2003 18:04:31 -0400 Received: from cisco.com (sjc-vpn4-528.cisco.com [10.21.82.16]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4DM55Nb002692; Tue, 13 May 2003 15:05:05 -0700 (PDT) Message-ID: <3EC16C10.FA724BE0@cisco.com> Date: Tue, 13 May 2003 18:05:04 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hajer ferjani CC: sip@ietf.org Subject: Re: [Sip] integration of sip and cops References: <20030512022109.25823.qmail@web12202.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-2.cisco.com id h4DM55Nb002692 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4DLTJB00430 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit You may want to take a look at RFC 3313. -- Flemming hajer ferjani wrote: > hi all, > anybody knows if there's some work on the integration > of sip and cops protocols accordingly to the QoS > architectures : IntServ and DiffServ. > thanks for any help. > regards. > > hajer. > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.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 mailnull@www1.ietf.org Tue May 13 20:39:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05331 for ; Tue, 13 May 2003 20:39:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E06D911492 for sip-archive@odin.ietf.org; Tue, 13 May 2003 20:06:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E05kB11478; Tue, 13 May 2003 20:05:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E04rB11436 for ; Tue, 13 May 2003 20:04:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05287 for ; Tue, 13 May 2003 20:38:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FkJP-00016R-00 for sip@ietf.org; Tue, 13 May 2003 20:40:03 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19FkJO-000162-00 for sip@ietf.org; Tue, 13 May 2003 20:40:02 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4E0dZ3j011864; Tue, 13 May 2003 17:39:35 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHB55975; Tue, 13 May 2003 17:33:14 -0700 (PDT) Date: Tue, 13 May 2003 17:39:48 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rohan@cisco.com, "'Dean Willis'" , Gonzalo.Camarillo@ericsson.com, jon.peterson@neustar.biz To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <9131FA75-85A4-11D7-8E16-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for auth-id body Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Everyone, I would like to begin Working Group Last Call on http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-01.txt WGLC will end on Friday, June 13, 2003. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 13 21:09:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05901 for ; Tue, 13 May 2003 21:09:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E0Zg113806 for sip-archive@odin.ietf.org; Tue, 13 May 2003 20:35:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E0ZLB13766; Tue, 13 May 2003 20:35:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E0YuB13725 for ; Tue, 13 May 2003 20:34:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05847 for ; Tue, 13 May 2003 21:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FkmT-0001HP-00 for sip@ietf.org; Tue, 13 May 2003 21:10:05 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19FkmS-0001HF-00 for sip@ietf.org; Tue, 13 May 2003 21:10:04 -0400 Received: from txdwillis ([63.206.46.200]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E1AY6n006987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 13 May 2003 20:10:37 -0500 From: "Dean Willis" To: Cc: Date: Tue, 13 May 2003 20:10:08 -0500 Message-ID: <000c01c319b5$958b5fa0$06f30a0a@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4E0YuB13726 Subject: [Sip] Service route discovery draft revised Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Bernie and I revised the Service Route Discovery draft to align with the current policy on example domain-name usage as requested by the AD. I also added a small clarifier to the applicability statement as recently requested on-list. This clarifier is "The service route constructed by the registrar is the same for all contacts associated with a single address-of-record. This mechanism does not provide for contact-specific service routes." The draft has been submitted to internet-drafts, and in the interim is available from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-scvrtdisco-04.html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-scvrtdisco-04.txt http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-scvrtdisco-04.xml Note that this draft is in state "IESG Evalution -- AD Followup" according to the Draft Tracker. Barring having done something stupid in the processing of the changes (and given the Blessing of the AD), I believe we're ready to proceed with this draft. If I understand the process correctly, AD/IESG review the changes as requested, and if acceptable the doc goes to the RFC editor. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 14 11:30:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21844 for ; Wed, 14 May 2003 11:30:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4EEuew22197 for sip-archive@odin.ietf.org; Wed, 14 May 2003 10:56:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EEu8B22168; Wed, 14 May 2003 10:56:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EEsbB22085 for ; Wed, 14 May 2003 10:54:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21705 for ; Wed, 14 May 2003 11:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FyC7-0006kH-00 for sip@ietf.org; Wed, 14 May 2003 11:29:27 -0400 Received: from mail2.webmessenger.it ([193.70.193.55] helo=mail1c.webmessenger.it) by ietf-mx with esmtp (Exim 4.12) id 19FyC7-0006kA-00 for sip@ietf.org; Wed, 14 May 2003 11:29:27 -0400 Received: from CORI14 (193.205.164.86) by mail1c.webmessenger.it (6.7.016) (authenticated as nunzio.gaito@email.it) id 3EBA1DD700311FBF for sip@ietf.org; Wed, 14 May 2003 17:29:58 +0200 Message-ID: <005801c31a2d$897ce4e0$56a4cdc1@CORI14> From: "Nunzio Gaito" To: "SIP Mailing" Date: Wed, 14 May 2003 17:28:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C31A3E.4A5DC660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] prova Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C31A3E.4A5DC660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0055_01C31A3E.4A5DC660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0055_01C31A3E.4A5DC660-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 14 21:47:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12328 for ; Wed, 14 May 2003 21:47:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4F1Ehv03505 for sip-archive@odin.ietf.org; Wed, 14 May 2003 21:14:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1EEB03490; Wed, 14 May 2003 21:14:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1BmB03364 for ; Wed, 14 May 2003 21:11:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12268 for ; Wed, 14 May 2003 21:44:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G7pC-0002wW-00 for sip@ietf.org; Wed, 14 May 2003 21:46:26 -0400 Received: from mail3.hosting.bora.net ([211.40.221.16]) by ietf-mx with smtp (Exim 4.12) id 19G7pA-0002wR-00 for sip@ietf.org; Wed, 14 May 2003 21:46:24 -0400 Received: (qmail 6805 invoked from network); 15 May 2003 01:46:56 -0000 Received: from unknown (HELO thomas2000svr) (211.239.8.224) by mail3.hosting.bora.net with SMTP; 15 May 2003 01:46:56 -0000 From: "???? ???" To: Date: Thu, 15 May 2003 10:46:58 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C31ACF.4EE9BF40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: [Sip] Push-To-Talk with SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C31ACF.4EE9BF40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCk5va2lhLCBTaWVtZW5zIGFuZCBFcmljc3NvbiBoYXZlIGFubm91bmNlZCB0aGF0 IHRoZXkgYXJlIGRldmVsb3BpbmcgYSBwdXNoLXRvLXRhbGsgYXBwbGljYXRpb24gZm9yIEdTTSBu ZXR3b3JrcyB3aXRoIEdQUlMgYW5kIGZvciBmdXR1cmUgM0cgbmV0d29ya3MuIFRoZXkgd2FudCB0 byB1c2UgU0lQIGZvciBzaWduYWxpbmcgYnV0IEkgY291bGRuJ3QgZmluZCBhbnkgbW9yZSBkZXRh aWxlZCBpbmZvcm1hdGlvbi4NCg0KRG9lcyBzb21lb25lIG9mIHlvdSBrbm93IHNvbWUgZGV0YWls IGFib3V0IHRoZSBQVFQgc2lnbmFsaW5nIHdpdGggU0lQPw0KRG8gdGhleSBjYXJlIGFib3V0IGFy Yml0cmF0aW9uIGlmIHR3byBwZW9wbGUgd2FudCB0byB0YWxrIHRvIHRoZSBzYW1lIGdyb3VwIGF0 IHRoZSBzYW1lIHRpbWU/IEFyZSB0aGVyZSBzb21lIGRyYWZ0cyBvciBkaXNjdXNzaW9ucyBhYm91 dCB0aGlzIHRvcGljcz8NCg0KcmVnYXJkcywNCnRob21hcyBsZWUuDQoNCg0KICAgICANCiAgICAg ICAgICAgICAgVGhvbWFzIExlZVRlY2huaWNhbCBDb25zdWx0YW50UG9seXBpeCBJbnN0aXR1dGUg b2YgVGVjaG5vbG9neTFGIFN1bmdkbyBWZW50dXJlIFRvd2VyLCAxNjUtMiBTYW1zdW5nLWRvbmcs S2FuZ25hbS1rdSwgU2VvdWwgMTM1LTg4MSwgS29yZWFUZWwgOiArODItMi01NTItMzUxMSAoZXh0 LiA1MTEpICBGYXggOiArODItMi01NTItMzUxME1vYmlsZSA6ICs4Mi0xNi0yNzEtNTUwN0UtbWFp bCA6IHRob21hcy5sZWVAcG9seXBpeC5jb21VcmwgOiB3d3cucG9seXBpeC5jb20gIA0KICAgICAN CiAgICAgDQoNCg0K ------=_NextPart_000_003A_01C31ACF.4EE9BF40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTE3MCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxTUEFO IGNsYXNzPTIzNTAwNDAwMS0xNTA1MjAwMz48Rk9OVCBzaXplPTI+SGVsbG8sPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjM1MDA0MDAxLTE1MDUyMDAzPjxGT05UIHNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yMzUwMDQwMDEt MTUwNTIwMDM+PEZPTlQgc2l6ZT0yPk5va2lhLCBTaWVtZW5zIGFuZCBFcmljc3NvbiANCmhhdmUg YW5ub3VuY2VkIHRoYXQgdGhleSBhcmUgZGV2ZWxvcGluZyBhIHB1c2gtdG8tdGFsayBhcHBsaWNh dGlvbiBmb3IgR1NNIA0KbmV0d29ya3Mgd2l0aCBHUFJTIGFuZCBmb3IgZnV0dXJlIDNHIG5ldHdv cmtzLiBUaGV5IHdhbnQgdG8gdXNlIFNJUCBmb3IgDQpzaWduYWxpbmcgYnV0IEkgY291bGRuJ3Qg ZmluZCBhbnkgbW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0K PERJVj48U1BBTiBjbGFzcz0yMzUwMDQwMDEtMTUwNTIwMDM+PEZPTlQgc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTIzNTAwNDAwMS0xNTA1MjAwMz48 Rk9OVCBzaXplPTI+RG9lcyBzb21lb25lIG9mIHlvdSBrbm93IHNvbWUgDQpkZXRhaWwgYWJvdXQg dGhlIFBUVCBzaWduYWxpbmcgd2l0aCBTSVA/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9MjM1MDA0MDAxLTE1MDUyMDAzPjxGT05UIHNpemU9Mj5EbyB0aGV5IGNhcmUgYWJv dXQgYXJiaXRyYXRpb24gDQppZiB0d28gcGVvcGxlIHdhbnQgdG8gdGFsayB0byB0aGUgc2FtZSBn cm91cCBhdCB0aGUgc2FtZSB0aW1lPyBBcmUgdGhlcmUgc29tZSANCmRyYWZ0cyBvciBkaXNjdXNz aW9ucyBhYm91dCB0aGlzIHRvcGljcz88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz0yMzUwMDQwMDEtMTUwNTIwMDM+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTIzNTAwNDAwMS0xNTA1MjAwMz48Rk9OVCBzaXplPTI+ cmVnYXJkcyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yMzUwMDQwMDEt MTUwNTIwMDM+PEZPTlQgc2l6ZT0yPnRob21hcyBsZWUuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgd2lk dGg9MzY1IGJvcmRlcj0wPg0KICA8VEJPRFk+DQogIDxUUj4NCiAgICA8VEQ+PElNRyBoZWlnaHQ9 NTIgYWx0PSIiIA0KICAgICAgc3JjPSJodHRwOi8vYXF1YXJpbmcuaGlob21lLmNvbS9pbWFnZXMv aXJpczJfMDEuZ2lmIiB3aWR0aD0zMTE+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREPg0KICAg ICAgPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD0iMTAwJSIgYm9yZGVy PTA+DQogICAgICAgIDxUQk9EWT4NCiAgICAgICAgPFRSPg0KICAgICAgICAgIDxURCB3aWR0aD0i NCUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgPFREIHdpZHRoPSI5NiUiPjxQUkU+PEJSPjxCPlRo b21hcyBMZWU8L0I+PFA+PEJSPlRlY2huaWNhbCBDb25zdWx0YW50PEJSPlBvbHlwaXggSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3k8QlI+PEJSPjxCUj4xRiBTdW5nZG8gVmVudHVyZSBUb3dlciwgMTY1 LTIgU2Ftc3VuZy1kb25nLDxCUj5LYW5nbmFtLWt1LCBTZW91bCAxMzUtODgxLCBLb3JlYTxCUj5U ZWwgOiArODItMi01NTItMzUxMSAoZXh0LiA1MTEpJm5ic3A7IDxBIGhyZWY9Imh0dHA6Ly93d3cu cG9seXBpeC5jb20vb2N4L2xvYWRpbmcuYXNwP2NhbGxudW09MDEyNTExIj48SU1HIGhlaWdodD0y MCBzcmM9Imh0dHA6Ly93d3cucG9seXBpeC5jb20vaW1hZ2VzL2tvcmVhbi9waG9uZS5naWYiIHdp ZHRoPTIwIGFsaWduPWFic01pZGRsZSBib3JkZXI9MD48L0E+PEJSPkZheCA6ICs4Mi0yLTU1Mi0z NTEwPEJSPk1vYmlsZSA6ICs4Mi0xNi0yNzEtNTUwNzxCUj5FLW1haWwgOiA8QSBocmVmPSJtYWls dG86dGhvbWFzLmxlZUBwb2x5cGl4LmNvbSI+dGhvbWFzLmxlZUBwb2x5cGl4LmNvbTwvQT48QlI+ VXJsIDogPEEgaHJlZj0iaHR0cDovL3d3dy5wb2x5cGl4LmNvbS8iPnd3dy5wb2x5cGl4LmNvbTwv QT4gPC9QPjwvUFJFPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PElNRyANCiAgICAgIGhlaWdo dD0xNSBhbHQ9IiIgc3JjPSJodHRwOi8vYXF1YXJpbmcuaGlob21lLmNvbS9pbWFnZXMvaXJpczJf MDMuZ2lmIiANCiAgICAgIHdpZHRoPTMxMT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQ+PC9U RD48L1RSPjwvVEJPRFk+PC9UQUJMRT4NCjxESVY+PEZPTlQgZmFjZT0nIiYjNDQ0MDQ7JiM0NzU0 ODsiJyBzaXplPTI+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_003A_01C31ACF.4EE9BF40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 15 07:23:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03944 for ; Thu, 15 May 2003 07:23:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4FAooW20984 for sip-archive@odin.ietf.org; Thu, 15 May 2003 06:50:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FAoNB20951; Thu, 15 May 2003 06:50:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FAlrB20770 for ; Thu, 15 May 2003 06:47:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03835; Thu, 15 May 2003 07:20:23 -0400 (EDT) Message-Id: <200305151120.HAA03835@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 15 May 2003 07:20:23 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-scvrtdisco-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 : Session Initiation Protocol Extension Header Field fo Service Route Discovery During Registration Author(s) : D. Willis, B. Hoeneisen Filename : draft-ietf-sip-scvrtdisco-04.txt Pages : 18 Date : 2003-5-14 This document defines a SIP extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-scvrtdisco-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-scvrtdisco-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-scvrtdisco-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: <2003-5-14154228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-scvrtdisco-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-scvrtdisco-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-14154228.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 15 13:13:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15514 for ; Thu, 15 May 2003 13:13:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4FGeIf17145 for sip-archive@odin.ietf.org; Thu, 15 May 2003 12:40:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FGdbB17062; Thu, 15 May 2003 12:39:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FGbrB17002 for ; Thu, 15 May 2003 12:37:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15438 for ; Thu, 15 May 2003 13:10:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GMH6-0000rO-00 for sip@ietf.org; Thu, 15 May 2003 13:12:12 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19GMH5-0000rF-00 for sip@ietf.org; Thu, 15 May 2003 13:12:11 -0400 Received: from txdwillis ([63.206.46.200]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FHCg6o023722 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 15 May 2003 12:12:49 -0500 From: "Dean Willis" To: "'???? ???'" , Subject: RE: [Sip] Push-To-Talk with SIP Date: Thu, 15 May 2003 12:12:34 -0500 Message-ID: <001b01c31b05$351b8bd0$06f30a0a@txdwillis> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C31ADB.4C4583D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C31ADB.4C4583D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Rumor (I overheard people talking about it in a bar near a 3GPP meeting last night) has it that there have been proposals to pursue this specification work in OMA (www.openmobilealliance.org). Of course, we can't really verify such rumors due to the closed IPR policy of the OMA. I CAN say that I've been encouraging OMA to open up. -- Dean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of ???? ??? Sent: Wednesday, May 14, 2003 8:47 PM To: sip@ietf.org Subject: [Sip] Push-To-Talk with SIP Hello, Nokia, Siemens and Ericsson have announced that they are developing a push-to-talk application for GSM networks with GPRS and for future 3G networks. They want to use SIP for signaling but I couldn't find any more detailed information. Does someone of you know some detail about the PTT signaling with SIP? Do they care about arbitration if two people want to talk to the same group at the same time? Are there some drafts or discussions about this topics? regards, thomas lee. ------=_NextPart_000_001C_01C31ADB.4C4583D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Rumor=20 (I overheard people talking about it in a bar near a 3GPP meeting last = night)=20 has it that there have been proposals to pursue this specification work = in OMA=20 (www.openmobilealliance.org= ). Of=20 course, we can't really verify such rumors due to the closed IPR = policy of=20 the OMA.
 
I CAN=20 say that I've been encouraging OMA to open up.
 
--
Dean
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = ????=20 ???
Sent: Wednesday, May 14, 2003 8:47 PM
To:=20 sip@ietf.org
Subject: [Sip] Push-To-Talk with=20 SIP

Hello,
 
Nokia, Siemens = and Ericsson=20 have announced that they are developing a push-to-talk application for = GSM=20 networks with GPRS and for future 3G networks. They want to use SIP = for=20 signaling but I couldn't find any more detailed=20 information.
 
Does someone of = you know some=20 detail about the PTT signaling with SIP?
Do they care = about=20 arbitration if two people want to talk to the same group at the same = time? Are=20 there some drafts or discussions about this = topics?
 
regards,
thomas=20 lee.
 
 
------=_NextPart_000_001C_01C31ADB.4C4583D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 16 05:08:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17124 for ; Fri, 16 May 2003 05:08:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G8ZjD24137 for sip-archive@odin.ietf.org; Fri, 16 May 2003 04:35:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8ZKB24082; Fri, 16 May 2003 04:35:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DFSxB03321 for ; Tue, 13 May 2003 11:28:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18199; Tue, 13 May 2003 12:02:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FcGK-0005Qv-00; Tue, 13 May 2003 12:04:20 -0400 Received: from tssg.wit.ie ([193.1.185.11] helo=mail.tssg.org) by ietf-mx with esmtp (Exim 4.12) id 19FcGI-0005Qq-00; Tue, 13 May 2003 12:04:18 -0400 Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 0C3131809A; Tue, 13 May 2003 17:05:54 +0100 (IST) From: "Shane McCormack" To: "Sipping@Ietf. Org" , "Sip@Ietf. Org" Date: Tue, 13 May 2003 17:09:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C31972.75B44360" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] PIDF format for spatial location Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C31972.75B44360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have mailed the list before on this subject but I am still looking for a bit more clarification on this subject. I need to retreive spatial location in pidf format for work I am doing on my thesis. I know that work is being done in the Geopriv working group on a format for sending such information. Just as a matter of doing things correctly could somebody with any knowledge help me in by telling me the additional headers necessary, and any other thoughts so i can put the correct information in my implementation and my thesis. Thank you Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.com ------=_NextPart_000_001F_01C31972.75B44360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have mailed=20 the list before on this subject but I am still looking for a bit=20 more clarification on this subject. I need to retreive spatial = location in=20 pidf format for work I am doing on my thesis.
I know = that work is=20 being done in the Geopriv working group on a format for sending such=20 information. Just as a matter of doing things correctly could somebody = with any=20 knowledge help me in
by = telling me the=20 additional headers necessary, and any other thoughts so i can put the = correct=20 information in my implementation and my thesis.
 
Thank=20 you
 

Shane=20 McCormack

Research = Assistant,
TSSG, = Confederation=20 House, =
Waterford = Business=20 Park, Cork Road,=20
Waterford, Co.=20 Waterford.

Phone:=20 +353 51 302927     Fax: +353 51 302901=20
Mobile:=20 +353 87 9955505=20
http://www.tssg.org =
MSN:=20 mccormackshane@hotmail.com= =20

 

 
------=_NextPart_000_001F_01C31972.75B44360-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 16 05:08:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17126 for ; Fri, 16 May 2003 05:08:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G8Zkt24152 for sip-archive@odin.ietf.org; Fri, 16 May 2003 04:35:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8ZTB24105; Fri, 16 May 2003 04:35:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EF8EB23812 for ; Wed, 14 May 2003 11:08:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22471 for ; Wed, 14 May 2003 11:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FyPI-0006tQ-00 for sip@ietf.org; Wed, 14 May 2003 11:43:04 -0400 Received: from tssg.wit.ie ([193.1.185.11] helo=mail.tssg.org) by ietf-mx with esmtp (Exim 4.12) id 19FyPH-0006tD-00 for sip@ietf.org; Wed, 14 May 2003 11:43:04 -0400 Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 6337B1809A for ; Wed, 14 May 2003 16:44:47 +0100 (IST) From: "Shane McCormack" To: "Sip@Ietf. Org" Date: Wed, 14 May 2003 16:48:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01C31A38.ADE89EE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] SIP and PAM Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C31A38.ADE89EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Just wondering if there is any thought on using SIP with the PAM specification. I know SIMPLE is obviously similar and better when using SIP but PAM brings alot more with it than just presence. PAM as you know allows for the retreival, from some sort of database system, of a users preferences, lists of assigned agents, personal information etc. Can SIP provide these sort of information retreival without implementing some sort of PAM interface or is it a viable implementation to couple SIP/SIMPLE with PAM. Regards Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.com ------=_NextPart_000_0091_01C31A38.ADE89EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20
Just = wondering if=20 there is any thought on using SIP with the PAM specification. I know = SIMPLE is=20 obviously similar and better when using SIP but PAM brings alot more = with it=20 than just presence. PAM as you know allows for the retreival, from some = sort of=20 database system, of a users preferences, lists of assigned agents, = personal=20 information etc. Can SIP provide these sort of information retreival = without=20 implementing some sort of PAM interface or is it a viable implementation = to=20 couple SIP/SIMPLE with PAM.
 
Regards
Shane=20 McCormack

Research = Assistant,
TSSG, = Confederation=20 House, =
Waterford = Business=20 Park, Cork Road,=20
Waterford, Co.=20 Waterford.

Phone:=20 +353 51 302927     Fax: +353 51 302901=20
Mobile:=20 +353 87 9955505=20
http://www.tssg.org =
MSN:=20 mccormackshane@hotmail.com= =20

 

 
------=_NextPart_000_0091_01C31A38.ADE89EE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 16 05:08:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17128 for ; Fri, 16 May 2003 05:08:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G8Zm724165 for sip-archive@odin.ietf.org; Fri, 16 May 2003 04:35:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8ZWB24124; Fri, 16 May 2003 04:35:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FCYmB28877 for ; Thu, 15 May 2003 08:34:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07871 for ; Thu, 15 May 2003 09:07:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GITv-00078Y-00 for sip@ietf.org; Thu, 15 May 2003 09:09:11 -0400 Received: from trantor.eads-dsn.com ([194.117.220.38]) by ietf-mx with esmtp (Exim 4.12) id 19GITu-00078N-00 for sip@ietf.org; Thu, 15 May 2003 09:09:10 -0400 Received: by trantor.eads-dsn.com; id PAA27614; Thu, 15 May 2003 15:09:00 +0200 (MET DST) Message-Id: <200305151309.PAA27614@trantor.eads-dsn.com> From: "Mauvielle, Cedric" To: "'sip@ietf.org'" Date: Thu, 15 May 2003 15:08:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4FCYmB28878 Subject: [Sip] SIP/H323 Gateways products Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello I want to know if some SIP/H323 software Gateways are available. We are looking for partners and so we need name of compagnies which can work with us. So, if you know some, can you send me informations about : - price - technical overview (communications max, OS,...) - if we can customize some paramaters (H323 ports for example) - if we can test your system Regards, Cédric M. -------------------------------------- EADS Defence and Security Network Rue Jean Pierre Timbaud Montigny le Bretonneux 78063 Saint Quentin en Yvelines Cedex France poste : +33 (0) 1-34-60-75-88 cedric.mauvielle@eads-telecom.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 mailnull@www1.ietf.org Fri May 16 09:08:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21775 for ; Fri, 16 May 2003 09:08:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GCZmE06488 for sip-archive@odin.ietf.org; Fri, 16 May 2003 08:35:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GCXjB06413; Fri, 16 May 2003 08:33:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GCVNB06297 for ; Fri, 16 May 2003 08:31:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21451 for ; Fri, 16 May 2003 09:03:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Getg-0006QI-00 for sip@ietf.org; Fri, 16 May 2003 09:05:16 -0400 Received: from iere.net.avaya.com ([198.152.12.101]) by ietf-mx with esmtp (Exim 4.12) id 19Gete-0006QF-00 for sip@ietf.org; Fri, 16 May 2003 09:05:14 -0400 Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h4GD3Ds20737 for ; Fri, 16 May 2003 09:03:13 -0400 (EDT) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h4GD3Dk20731 for ; Fri, 16 May 2003 09:03:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] SIP and PAM Date: Fri, 16 May 2003 09:06:17 -0400 Message-ID: <122C500C0A99244C831988096A4F0D5501BB6AF5@nj7460avexu1.global.avaya.com> Thread-Topic: [Sip] SIP and PAM Thread-Index: AcMbj1JeiCFBWcX3Su6afoKp4GwOZAAGTiSQ From: "Goud, Venkat Ramana (Venkat) ** CTR **" To: Cc: "Shane McCormack" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4GCVZB06301 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Most of the interfaces of PAM deal with data manipulation and retrieval and there is no straightforward SIP mapping to these methods.You can implement few of the PAM interfaces using SIMPLE but not many - but you will be breaking semantics!. There was a plan in the PAM forum to describe ways of mapping between SIP and PAM but I dont know the details. Venkat -----Original Message----- From: Shane McCormack [mailto:smccormack@tssg.org] Sent: Wednesday, May 14, 2003 11:49 AM To: Sip@Ietf. Org Subject: [Sip] SIP and PAM Hi Just wondering if there is any thought on using SIP with the PAM specification. I know SIMPLE is obviously similar and better when using SIP but PAM brings alot more with it than just presence. PAM as you know allows for the retreival, from some sort of database system, of a users preferences, lists of assigned agents, personal information etc. Can SIP provide these sort of information retreival without implementing some sort of PAM interface or is it a viable implementation to couple SIP/SIMPLE with PAM. Regards Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.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 mailnull@www1.ietf.org Fri May 16 12:08:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00934 for ; Fri, 16 May 2003 12:08:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GFZx220747 for sip-archive@odin.ietf.org; Fri, 16 May 2003 11:35:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GFZRB20717; Fri, 16 May 2003 11:35:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GFS6B20341 for ; Fri, 16 May 2003 11:28:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00774 for ; Fri, 16 May 2003 12:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ghed-0000o9-00 for sip@ietf.org; Fri, 16 May 2003 12:01:55 -0400 Received: from lmg.affinity.com ([207.150.192.13] helo=lmg01.affinity.com) by ietf-mx with esmtp (Exim 4.12) id 19GheZ-0000o0-00 for sip@ietf.org; Fri, 16 May 2003 12:01:51 -0400 Received: from homepc2 ([67.72.108.87]) by lmg.ahnet.net with SMTP id <301787-7458> convert rfc822-to-quoted-printable; Fri, 16 May 2003 08:57:41 -0700 From: "Fred Robinson" To: "Mauvielle, Cedric" , Subject: RE: [Sip] SIP/H323 Gateways products Date: Fri, 16 May 2003 09:57:43 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200305151309.PAA27614@trantor.eads-dsn.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www1.ietf.org id h4GFS6B20342 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Cedric, Check out the SHOUTip product from NET.com for SIP-H323 conversion; http://www.net.com/products/voice_packet/ Fred Robinson 2855 Rock Creek Circle #131 Superior, CO 80027 fred.robinson@sipfusion.com office: 720.304.8707 mobile: 303.881.7590 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Mauvielle, Cedric Sent: Thursday, May 15, 2003 7:08 AM To: 'sip@ietf.org' Subject: [Sip] SIP/H323 Gateways products Hello I want to know if some SIP/H323 software Gateways are available. We are looking for partners and so we need name of compagnies which can work with us. So, if you know some, can you send me informations about : - price - technical overview (communications max, OS,...) - if we can customize some paramaters (H323 ports for example) - if we can test your system Regards, Cédric M. -------------------------------------- EADS Defence and Security Network Rue Jean Pierre Timbaud Montigny le Bretonneux 78063 Saint Quentin en Yvelines Cedex France poste : +33 (0) 1-34-60-75-88 cedric.mauvielle@eads-telecom.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 mailnull@www1.ietf.org Mon May 19 00:49:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25372 for ; Mon, 19 May 2003 00:49:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4J4I3V00445 for sip-archive@odin.ietf.org; Mon, 19 May 2003 00:18:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J4GpB00408; Mon, 19 May 2003 00:16:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J48OB32628 for ; Mon, 19 May 2003 00:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25213; Mon, 19 May 2003 00:39:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HcSG-0007AU-00; Mon, 19 May 2003 00:40:56 -0400 Received: from f81.law12.hotmail.com ([64.4.19.81] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19HcSF-00079v-00; Mon, 19 May 2003 00:40:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 18 May 2003 21:41:42 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Mon, 19 May 2003 04:41:41 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: drage@lucent.com, ashishn@mahindrabt.com, asanth01@sprintspectrum.com, sip@ietf.org Cc: sipping@ietf.org Date: Mon, 19 May 2003 04:41:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 May 2003 04:41:42.0365 (UTC) FILETIME=[F1C4F8D0:01C31DC0] Subject: [Sip] SIP mobility in WLAN Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, Where can I get call-flows for SIP session management in a wireless LAN (802.11)? 3GPP only addresses the issues for cellular networks. Or are they too trivial to be addressed specially? I am specially interested in situations of handoffs (in this case, the IP changes as soon as the host shifts from the zone around one hotspot to another). Should SIP bother at all to detect IP changes or should the control be completely outside SIP? I mean should it be some other module that has the responsibility of informing the SIP stack in the mobile host about the IP changes, so that the host may then send a re-INVITE with a new SDP but the call still remains active? regards Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 ----Original Message Follows---- From: "Drage, Keith (Keith)" To: "'Ashish Naik'" , "Santharam, Arun [CC]" , "Sip@Ietf. Org" Subject: RE: [Sip] Session Mobility in SIP Date: Thu, 8 May 2003 14:42:24 +0100 Your best starting point to see the architecture is 3GPP TS 23.228, with reference to 3GPP TS 23.002 to see how these entities fit together into the entire 3GPP architecture. The SIP protocol application is covered in 3GPP TS 24.229 with example flows in 3GPP TS 24.228. These documents may be found at: ftp://ftp.3gpp.org/Specs/latest/Rel-5/ 3GPP uses these specifications over GPRS to provide mobility. There is a parallel set of 3GPP2 specifications, substantially of common text, that uses the same architecture over mobile IP, instead of GPRS. These documents are currently in 3GPP2 comment and review. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com -----Original Message----- From: Ashish Naik [mailto:ashishn@mahindrabt.com] Sent: 08 May 2003 06:23 To: Santharam, Arun [CC]; Sip@Ietf. Org Subject: RE: [Sip] Session Mobility in SIP ok. Is there any specific document on IETF and 3GPP that can explain how it is being addressed ? Ragards, Ashish Naik CoE Mobile Computing ----------------------------------- Phone 4018100 Ext 3070 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Santharam, Arun [CC] Sent: Wednesday, April 09, 2003 9:42 PM To: Ashish Naik; Sip@Ietf. Org Subject: RE: [Sip] Session Mobility in SIP Ashish, Please find comments inline. Thank you arun -----Original Message----- From: Ashish Naik [mailto:ashishn@mahindrabt.com] Sent: Wednesday, April 09, 2003 4:01 AM To: Sip@Ietf. Org Subject: [Sip] Session Mobility in SIP How is SIP going to address session mobility ? Is there any initiative taken up for this ? > This has been addressed in 3GPP standards. Please refer to the 3GPP All IP architecture specifications. SIP is said to be a better alternative than Mobile IP. Can I have some latest development document references ? > SIP is not going to replace Mobile IP. It is going to leverage Mobile IP for session management in 3G wireless networks. Regards, Ashish Naik ------------------- CoE Mobile Computing Phone: 4018100 Ext 3070 ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _________________________________________________________________ Mobile, masti, magic! Cool ringtones & logos. http://www.msn.co.in/mobile/ Get noticed _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 19 04:08:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11503 for ; Mon, 19 May 2003 04:08:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4J7bfi25649 for sip-archive@odin.ietf.org; Mon, 19 May 2003 03:37:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7bEB25198; Mon, 19 May 2003 03:37:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7U0B24730 for ; Mon, 19 May 2003 03:30:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11312 for ; Mon, 19 May 2003 04:00:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HfbI-0000u5-00 for sip@ietf.org; Mon, 19 May 2003 04:02:28 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19HfbH-0000u2-00 for sip@ietf.org; Mon, 19 May 2003 04:02:27 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J83Bdh014235; Mon, 19 May 2003 04:03:11 -0400 (EDT) Message-ID: <3EC88FBB.1080107@dynamicsoft.com> Date: Mon, 19 May 2003 04:03:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" CC: "'Rohan Mahy'" , "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Subject: Re: [Sip] UPDATE and P-Asserted-ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree that Contact is not the right place to identify the user. Rather, it is a form of identification for a device. There is really a bigger issue here, which is the scope of the information that can be updated by a target refresh request (of which UPDATE is one). RFC 3261 refers only to specific pieces of the state of a dialog which can be updated (cseq, contact headers). There are other pieces of state held for the lifetime of the dialog, such as the UA capabilities (from the Supported header field), methods allowed (Allow header field), and so on. Can these be updated by a target refresh request? RFC 3261 is silent on this point, and I think the question is similar to whether an implementation would even update the P-Asserted-ID header field in a re-INVITE (forgetting UPDATE even). Our thinking was really that this information was static, and therefore would be set by the initial INVITE and not changed afterwards, although the spec never explicitly states this. The issue here is that folks believe P-Asserted-ID is NOT static (i.e., because of a call transfer), and therefore would need to change. I believe there are actually a few cases where it would change, such as various 3pcc cases too. So, considering the general problem, there are a few solutions: 1. Each header field that conveys dialog-associated state would indicate whether or not that state is updated by a target refresh request. 2. We specify a blanket rule for all such headers that their state is updated by a target refresh request (absence of a header would imply no update). 3. We specify a blanket rule for all such headers that their state is never updated by a target refresh request. 4. We specify a default rule for all such headers, but allow individual headers to override it. In the interests of simplicity I would tend to lean towards (2). The best place for this, of course, is rfc 3261, in which case we should treat this as a bug against the spec. -Jonathan R. Elwell, John wrote: > Rohan, > > The qsig2sip draft is silent on the subject of the contact header. So too is > the ISUP-SIP draft (except on the subject of contact headers in 3xx > response). It is not clear to me that a contact header should necessarily > reflect the identity of the remote party in the legacy network. Therefore > there may be no need to change the contact header when transfer occurs in > the legacy network. > > Consider the following case. An INVITE request leaves the SIP network at an > egress gateway to QSIG. The gateway receives a QSIG ALERTING message and > sends back a 180 response containing a contact header. It would be possible > for this contact header to reflect the identity of the party to whom the > QSIG SETUP message was directed or, except where prevented by privacy, the > identity of the party actually being alerted (can be different because of > forwarding). Now, suppose after alerting but before answer the call is > forwarded, so that the party who answers is not the party identified in the > contact header in the 180 response. What should go in the contact header of > the 200 response: the same value that was in the 180 contact header; or a > different value reflecting the identity of the answering party? It is not > clear to me whether the contact header is allowed to or should change in > this situation. > > Because if is not always feasible, because of privacy, forwarding etc. for > the contact header issued by a gateway always to reflect the identity of the > remote party in the legacy network, I see the contact header primarily as a > means of identifying the gateway, rather than the remote party. That is why > the qsig2sip draft is silent on this issue - the choice of contact header is > an implementation matter for the gateway. > > Regards, > > John > > >>-----Original Message----- >>From: Rohan Mahy [mailto:rohan@cisco.com] >>Sent: 13 May 2003 00:12 >>To: Elwell, John >>Cc: 'Drage, Keith (Keith)'; 'sip@ietf.org' >>Subject: Re: [Sip] UPDATE and P-Asserted-ID >> >> >>John, >> >>I believe you still should generate a new Contact header, even if you >>are only changing the display name. >> >>thanks, >>-rohan >> >>On Thursday, May 8, 2003, at 01:21 AM, Elwell, John wrote: >> >> >>>Keith, >>> >>>Thanks for your response. However, I do not wish to cover target >>>refresh. As >>>I understand from section 12 of RFC3261, local and remote >> >>targets are >> >>>derived from Contact headers. The scenario I have in mind is where >>>something >>>happens behind a gateway. However, the gateway remains the same and >>>therefore it does not need to generate a new Contact header. >>> >>>John (john.elwell@siemens.com) >>> >>> >>>>-----Original Message----- >>>>From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>>Sent: 07 May 2003 19:11 >>>>To: Elwell, John; 'sip@ietf.org' >>>>Subject: RE: [Sip] UPDATE and P-Asserted-ID >>>> >>>> >>>>I believe the thinking when the document was developed was >>>>essentially to allow it in methods that either initiated a >>>>dialog, or were sent outside of a dialog. There was therefore >>>>no intent to cover reINVITE at that time, although I do not >>>>think it was explicitly excluded in the RFC. I am not sure >>>>how the BYE got added in respect of this, maybe someone else >>>>can clarify. The NOTIFY is there in respect of a NOTIFY that >>>>confirms a SUBSCRIBE dialog. >>>> >>>>This would allow the exchange of identities between the end >>>>users under these circumstances. >>>> >>>>From what you are indicating, it looks like you would want to >>>>extend the above to cover target refresh requests. >>>> >>>>Keith >>>> >>>>Keith Drage >>>>Lucent Technologies >>>>Tel: +44 1793 776249 >>>>Email: drage@lucent.com >>>> >>>> >>>>>-----Original Message----- >>>>>From: Elwell, John [mailto:john.elwell@siemens.com] >>>>>Sent: 07 May 2003 10:20 >>>>>To: 'sip@ietf.org' >>>>>Subject: [Sip] UPDATE and P-Asserted-ID >>>>> >>>>> >>>>>In RFC3325 section 9.1 it indicates that P-Asserted-ID is not >>>>>allowed in >>>>>UPDATE. Does anyone know the reason for this? A useful >>>>>application would be >>>>>to indicate a changed asserted identity when a change of >>>>>party occurs in a >>>>>legacy network (e.g., due to transfer). If not allowed in >> >>UPDATE, a >> >>>>>re-INVITE would need to be used, but this introduces an >>>> >>>>extra message. >>>> >>>>>John Elwell (john.elwell@siemens.com) >>>>> >>>>> >>>>>_______________________________________________ >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>This list is for NEW development of the core SIP Protocol >>>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>Use sipping@ietf.org for new developments on the >> >>application of sip >> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 19 04:27:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12226 for ; Mon, 19 May 2003 04:27:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4J7tvI26943 for sip-archive@odin.ietf.org; Mon, 19 May 2003 03:55:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7tbB26911; Mon, 19 May 2003 03:55:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7oAB26658 for ; Mon, 19 May 2003 03:50:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11932 for ; Mon, 19 May 2003 04:20:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hfun-00014C-00 for sip@ietf.org; Mon, 19 May 2003 04:22:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Hfum-00012q-00 for sip@ietf.org; Mon, 19 May 2003 04:22:36 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J8NKdh014251; Mon, 19 May 2003 04:23:21 -0400 (EDT) Message-ID: <3EC89473.901@dynamicsoft.com> Date: Mon, 19 May 2003 04:23:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Sanjay Sinha , sip@ietf.org Subject: Re: [Sip] Question on RFC 3263 References: <3EADA6A1.5010302@cisco.com> <3EAE8F5D.C3C1FE84@lmf.ericsson.se> <3EAE95E3.5000906@cisco.com> <3EAFA36A.5492523C@lmf.ericsson.se> <3EAFD79D.7070302@cisco.com> <3EB165FB.90FDF134@lmf.ericsson.se> In-Reply-To: <3EB165FB.90FDF134@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > >>>>>> 1) Since ACK for 200 response indicates a new transaction >>>>>> and follows rules of sec. 4.2 to find out the ip address >>>>>> of next hop element to send ACK to, how does the client >>>>>> transaction detect failure for ACK and move to next >>>>>> record in the list if used with UDP and the next hop does >>>>>> not generate transport errors. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> [CHH] It is true that the remote server will not be able to >>>>> send eg a 503 response for an ACK, but if the failure >>>>> occurs on the transport level you will be notified >it the >>>>> same way as you would for any other request (ICMP errors >>>>> etc). These are sent independently on if the remote server >>>>> generates SIP responses or not. >>>>> >>>>> >>>>> >>>> >>>> [SS] But the client transport layer will not get ICMP errors >>>> if the first record from the list has crashed or has it's >>>> interface shutdown. >>>> >>>> >>> >>> [CHH] Well, if the ACK doesn't reach the server you will get >>> retransmits of the 200 OK (unless they are supposed to be sent >>> from the same interface which has crashed, of course).. >>> >> >> [SS] Right, but how does the client's transaction figure out that >> 200 retransmissions are because of Ack going to the wrong >> interface from the list vs. Ack being lost in the >> network/network delay and whether it should cycle to the next >> record or not. > > > [CHH] I guess you will have to use logic based on local policy to > decide when to "switch" from one address to another, if the 200 > responses don't stop coming, even if you send ACK... I think that this is a bad idea. I believe the answer is simpler - there is no timeout-based mechanism for detecting failure for ACK. Only ICMP or TCP connection problems will work. Thats just a limitation of the way ACK works. Relying on e2e messaging (like the 200 OK) to infer problems at a specific hop is not going to work. > > >>>>> 2) For PRACK, if the client transaction layer times out >>>>> waiting for 200 OK to PRACK before moving to the next >>>>> record, the server transaction may run out of 18x retries >>>>> waiting for PRACK and disconnect the call, if the next >>>>> record happens to be the one that sent 18x. Actually, before that even happens the client transaction will simply terminate at the UAC. See: http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-00.txt but in any case, the UAS shouldnt terminate the call just because the 18x never got a PRACK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 19 05:43:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13211 for ; Mon, 19 May 2003 05:43:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4J9CLu32615 for sip-archive@odin.ietf.org; Mon, 19 May 2003 05:12:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J98UB32495; Mon, 19 May 2003 05:08:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J90eB31398 for ; Mon, 19 May 2003 05:00:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13008 for ; Mon, 19 May 2003 05:31:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hh10-0001Lw-00 for sip@ietf.org; Mon, 19 May 2003 05:33:06 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19Hh10-0001Lo-00 for sip@ietf.org; Mon, 19 May 2003 05:33:06 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HF400H01NV8V3@siemenscomms.co.uk> for sip@ietf.org; Mon, 19 May 2003 10:33:10 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HF400HG1NV7P3@siemenscomms.co.uk>; Mon, 19 May 2003 10:33:07 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 19 May 2003 10:33:43 +0100 Content-return: allowed Date: Mon, 19 May 2003 10:34:04 +0100 From: "Elwell, John" Subject: RE: [Sip] UPDATE and P-Asserted-ID To: "'Jonathan Rosenberg'" Cc: "'Rohan Mahy'" , "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Jonathan, Thanks for your input. I too would prefer 2. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 19 May 2003 09:03 > To: Elwell, John > Cc: 'Rohan Mahy'; 'Drage, Keith (Keith)'; 'sip@ietf.org' > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > I agree that Contact is not the right place to identify the user. > Rather, it is a form of identification for a device. > > There is really a bigger issue here, which is the scope of the > information that can be updated by a target refresh request (of which > UPDATE is one). RFC 3261 refers only to specific pieces of the state > of a dialog which can be updated (cseq, contact headers). There are > other pieces of state held for the lifetime of the dialog, > such as the > UA capabilities (from the Supported header field), methods allowed > (Allow header field), and so on. Can these be updated by a target > refresh request? > > RFC 3261 is silent on this point, and I think the question is similar > to whether an implementation would even update the P-Asserted-ID > header field in a re-INVITE (forgetting UPDATE even). > > Our thinking was really that this information was static, and > therefore would be set by the initial INVITE and not changed > afterwards, although the spec never explicitly states this. The issue > here is that folks believe P-Asserted-ID is NOT static (i.e., because > of a call transfer), and therefore would need to change. I believe > there are actually a few cases where it would change, such as various > 3pcc cases too. > > So, considering the general problem, there are a few solutions: > > 1. Each header field that conveys dialog-associated state would > indicate whether or not that state is updated by a target > refresh request. > > 2. We specify a blanket rule for all such headers that their state is > updated by a target refresh request (absence of a header would imply > no update). > > 3. We specify a blanket rule for all such headers that their state is > never updated by a target refresh request. > > 4. We specify a default rule for all such headers, but allow > individual headers to override it. > > > In the interests of simplicity I would tend to lean towards (2). The > best place for this, of course, is rfc 3261, in which case we should > treat this as a bug against the spec. > > -Jonathan R. > > > Elwell, John wrote: > > Rohan, > > > > The qsig2sip draft is silent on the subject of the contact > header. So too is > > the ISUP-SIP draft (except on the subject of contact headers in 3xx > > response). It is not clear to me that a contact header > should necessarily > > reflect the identity of the remote party in the legacy > network. Therefore > > there may be no need to change the contact header when > transfer occurs in > > the legacy network. > > > > Consider the following case. An INVITE request leaves the > SIP network at an > > egress gateway to QSIG. The gateway receives a QSIG > ALERTING message and > > sends back a 180 response containing a contact header. It > would be possible > > for this contact header to reflect the identity of the > party to whom the > > QSIG SETUP message was directed or, except where prevented > by privacy, the > > identity of the party actually being alerted (can be > different because of > > forwarding). Now, suppose after alerting but before answer > the call is > > forwarded, so that the party who answers is not the party > identified in the > > contact header in the 180 response. What should go in the > contact header of > > the 200 response: the same value that was in the 180 > contact header; or a > > different value reflecting the identity of the answering > party? It is not > > clear to me whether the contact header is allowed to or > should change in > > this situation. > > > > Because if is not always feasible, because of privacy, > forwarding etc. for > > the contact header issued by a gateway always to reflect > the identity of the > > remote party in the legacy network, I see the contact > header primarily as a > > means of identifying the gateway, rather than the remote > party. That is why > > the qsig2sip draft is silent on this issue - the choice of > contact header is > > an implementation matter for the gateway. > > > > Regards, > > > > John > > > > > >>-----Original Message----- > >>From: Rohan Mahy [mailto:rohan@cisco.com] > >>Sent: 13 May 2003 00:12 > >>To: Elwell, John > >>Cc: 'Drage, Keith (Keith)'; 'sip@ietf.org' > >>Subject: Re: [Sip] UPDATE and P-Asserted-ID > >> > >> > >>John, > >> > >>I believe you still should generate a new Contact header, > even if you > >>are only changing the display name. > >> > >>thanks, > >>-rohan > >> > >>On Thursday, May 8, 2003, at 01:21 AM, Elwell, John wrote: > >> > >> > >>>Keith, > >>> > >>>Thanks for your response. However, I do not wish to cover target > >>>refresh. As > >>>I understand from section 12 of RFC3261, local and remote > >> > >>targets are > >> > >>>derived from Contact headers. The scenario I have in mind is where > >>>something > >>>happens behind a gateway. However, the gateway remains the same and > >>>therefore it does not need to generate a new Contact header. > >>> > >>>John (john.elwell@siemens.com) > >>> > >>> > >>>>-----Original Message----- > >>>>From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >>>>Sent: 07 May 2003 19:11 > >>>>To: Elwell, John; 'sip@ietf.org' > >>>>Subject: RE: [Sip] UPDATE and P-Asserted-ID > >>>> > >>>> > >>>>I believe the thinking when the document was developed was > >>>>essentially to allow it in methods that either initiated a > >>>>dialog, or were sent outside of a dialog. There was therefore > >>>>no intent to cover reINVITE at that time, although I do not > >>>>think it was explicitly excluded in the RFC. I am not sure > >>>>how the BYE got added in respect of this, maybe someone else > >>>>can clarify. The NOTIFY is there in respect of a NOTIFY that > >>>>confirms a SUBSCRIBE dialog. > >>>> > >>>>This would allow the exchange of identities between the end > >>>>users under these circumstances. > >>>> > >>>>From what you are indicating, it looks like you would want to > >>>>extend the above to cover target refresh requests. > >>>> > >>>>Keith > >>>> > >>>>Keith Drage > >>>>Lucent Technologies > >>>>Tel: +44 1793 776249 > >>>>Email: drage@lucent.com > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>>Sent: 07 May 2003 10:20 > >>>>>To: 'sip@ietf.org' > >>>>>Subject: [Sip] UPDATE and P-Asserted-ID > >>>>> > >>>>> > >>>>>In RFC3325 section 9.1 it indicates that P-Asserted-ID is not > >>>>>allowed in > >>>>>UPDATE. Does anyone know the reason for this? A useful > >>>>>application would be > >>>>>to indicate a changed asserted identity when a change of > >>>>>party occurs in a > >>>>>legacy network (e.g., due to transfer). If not allowed in > >> > >>UPDATE, a > >> > >>>>>re-INVITE would need to be used, but this introduces an > >>>> > >>>>extra message. > >>>> > >>>>>John Elwell (john.elwell@siemens.com) > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>This list is for NEW development of the core SIP Protocol > >>>>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>>Use sipping@ietf.org for new developments on the > >> > >>application of sip > >> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>Use sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 19 07:49:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17908 for ; Mon, 19 May 2003 07:49:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JBIM608635 for sip-archive@odin.ietf.org; Mon, 19 May 2003 07:18:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JBHfB08596; Mon, 19 May 2003 07:17:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JBBsB08448 for ; Mon, 19 May 2003 07:11:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17816 for ; Mon, 19 May 2003 07:42:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hj3x-0002ky-00 for sip@ietf.org; Mon, 19 May 2003 07:44:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Hj3w-0002kv-00 for sip@ietf.org; Mon, 19 May 2003 07:44:17 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4JBjWD23954 for ; Mon, 19 May 2003 14:45:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 19 May 2003 14:45:32 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 19 May 2003 14:45:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] UPDATE and P-Asserted-ID Date: Mon, 19 May 2003 14:45:31 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE760E@esebe019.ntc.nokia.com> Thread-Topic: [Sip] UPDATE and P-Asserted-ID Thread-Index: AcMd3tW/ivEMkFADQzyyKNPC6IymkgAHPz8A To: , Cc: , , X-OriginalArrivalTime: 19 May 2003 11:45:31.0739 (UTC) FILETIME=[26DB82B0:01C31DFC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JBBsB08449 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Option 2 is ok for me, but we have to soften the SHOULD requirement to add contact headers in requests within dialog (section 12.2) and that it SHOULD contain the same value as the previous request within dialog. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, May 19, 2003 11:03 AM > To: Elwell, John > Cc: 'Rohan Mahy'; 'Drage, Keith (Keith)'; 'sip@ietf.org' > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > I agree that Contact is not the right place to identify the user. > Rather, it is a form of identification for a device. > > There is really a bigger issue here, which is the scope of the > information that can be updated by a target refresh request (of which > UPDATE is one). RFC 3261 refers only to specific pieces of the state > of a dialog which can be updated (cseq, contact headers). There are > other pieces of state held for the lifetime of the dialog, > such as the > UA capabilities (from the Supported header field), methods allowed > (Allow header field), and so on. Can these be updated by a target > refresh request? > > RFC 3261 is silent on this point, and I think the question is similar > to whether an implementation would even update the P-Asserted-ID > header field in a re-INVITE (forgetting UPDATE even). > > Our thinking was really that this information was static, and > therefore would be set by the initial INVITE and not changed > afterwards, although the spec never explicitly states this. The issue > here is that folks believe P-Asserted-ID is NOT static (i.e., because > of a call transfer), and therefore would need to change. I believe > there are actually a few cases where it would change, such as various > 3pcc cases too. > > So, considering the general problem, there are a few solutions: > > 1. Each header field that conveys dialog-associated state would > indicate whether or not that state is updated by a target > refresh request. > > 2. We specify a blanket rule for all such headers that their state is > updated by a target refresh request (absence of a header would imply > no update). > > 3. We specify a blanket rule for all such headers that their state is > never updated by a target refresh request. > > 4. We specify a default rule for all such headers, but allow > individual headers to override it. > > > In the interests of simplicity I would tend to lean towards (2). The > best place for this, of course, is rfc 3261, in which case we should > treat this as a bug against the spec. > > -Jonathan R. > > > Elwell, John wrote: > > Rohan, > > > > The qsig2sip draft is silent on the subject of the contact > header. So too is > > the ISUP-SIP draft (except on the subject of contact headers in 3xx > > response). It is not clear to me that a contact header > should necessarily > > reflect the identity of the remote party in the legacy > network. Therefore > > there may be no need to change the contact header when > transfer occurs in > > the legacy network. > > > > Consider the following case. An INVITE request leaves the > SIP network at an > > egress gateway to QSIG. The gateway receives a QSIG > ALERTING message and > > sends back a 180 response containing a contact header. It > would be possible > > for this contact header to reflect the identity of the > party to whom the > > QSIG SETUP message was directed or, except where prevented > by privacy, the > > identity of the party actually being alerted (can be > different because of > > forwarding). Now, suppose after alerting but before answer > the call is > > forwarded, so that the party who answers is not the party > identified in the > > contact header in the 180 response. What should go in the > contact header of > > the 200 response: the same value that was in the 180 > contact header; or a > > different value reflecting the identity of the answering > party? It is not > > clear to me whether the contact header is allowed to or > should change in > > this situation. > > > > Because if is not always feasible, because of privacy, > forwarding etc. for > > the contact header issued by a gateway always to reflect > the identity of the > > remote party in the legacy network, I see the contact > header primarily as a > > means of identifying the gateway, rather than the remote > party. That is why > > the qsig2sip draft is silent on this issue - the choice of > contact header is > > an implementation matter for the gateway. > > > > Regards, > > > > John > > > > > >>-----Original Message----- > >>From: Rohan Mahy [mailto:rohan@cisco.com] > >>Sent: 13 May 2003 00:12 > >>To: Elwell, John > >>Cc: 'Drage, Keith (Keith)'; 'sip@ietf.org' > >>Subject: Re: [Sip] UPDATE and P-Asserted-ID > >> > >> > >>John, > >> > >>I believe you still should generate a new Contact header, > even if you > >>are only changing the display name. > >> > >>thanks, > >>-rohan > >> > >>On Thursday, May 8, 2003, at 01:21 AM, Elwell, John wrote: > >> > >> > >>>Keith, > >>> > >>>Thanks for your response. However, I do not wish to cover target > >>>refresh. As > >>>I understand from section 12 of RFC3261, local and remote > >> > >>targets are > >> > >>>derived from Contact headers. The scenario I have in mind is where > >>>something > >>>happens behind a gateway. However, the gateway remains the same and > >>>therefore it does not need to generate a new Contact header. > >>> > >>>John (john.elwell@siemens.com) > >>> > >>> > >>>>-----Original Message----- > >>>>From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >>>>Sent: 07 May 2003 19:11 > >>>>To: Elwell, John; 'sip@ietf.org' > >>>>Subject: RE: [Sip] UPDATE and P-Asserted-ID > >>>> > >>>> > >>>>I believe the thinking when the document was developed was > >>>>essentially to allow it in methods that either initiated a > >>>>dialog, or were sent outside of a dialog. There was therefore > >>>>no intent to cover reINVITE at that time, although I do not > >>>>think it was explicitly excluded in the RFC. I am not sure > >>>>how the BYE got added in respect of this, maybe someone else > >>>>can clarify. The NOTIFY is there in respect of a NOTIFY that > >>>>confirms a SUBSCRIBE dialog. > >>>> > >>>>This would allow the exchange of identities between the end > >>>>users under these circumstances. > >>>> > >>>>From what you are indicating, it looks like you would want to > >>>>extend the above to cover target refresh requests. > >>>> > >>>>Keith > >>>> > >>>>Keith Drage > >>>>Lucent Technologies > >>>>Tel: +44 1793 776249 > >>>>Email: drage@lucent.com > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>>Sent: 07 May 2003 10:20 > >>>>>To: 'sip@ietf.org' > >>>>>Subject: [Sip] UPDATE and P-Asserted-ID > >>>>> > >>>>> > >>>>>In RFC3325 section 9.1 it indicates that P-Asserted-ID is not > >>>>>allowed in > >>>>>UPDATE. Does anyone know the reason for this? A useful > >>>>>application would be > >>>>>to indicate a changed asserted identity when a change of > >>>>>party occurs in a > >>>>>legacy network (e.g., due to transfer). If not allowed in > >> > >>UPDATE, a > >> > >>>>>re-INVITE would need to be used, but this introduces an > >>>> > >>>>extra message. > >>>> > >>>>>John Elwell (john.elwell@siemens.com) > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>This list is for NEW development of the core SIP Protocol > >>>>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>>Use sipping@ietf.org for new developments on the > >> > >>application of sip > >> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>Use sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 19 11:02:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23769 for ; Mon, 19 May 2003 11:02:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JEV5023265 for sip-archive@odin.ietf.org; Mon, 19 May 2003 10:31:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JEUOB23218; Mon, 19 May 2003 10:30:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JES2B23119 for ; Mon, 19 May 2003 10:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23684 for ; Mon, 19 May 2003 10:58:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hm7S-0003zX-00 for sip@ietf.org; Mon, 19 May 2003 11:00:06 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=f1ee40-19.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19Hm7M-0003yu-00 for sip@ietf.org; Mon, 19 May 2003 11:00:00 -0400 Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id OAA24715; Mon, 19 May 2003 14:59:56 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 19 May 2003 08:59:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] UPDATE and P-Asserted-ID Date: Mon, 19 May 2003 08:57:13 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976C301E9@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sip] UPDATE and P-Asserted-ID Thread-Index: AcMd4hnhtpPmhinzSFCzVORIbJebKgANGPdg From: "Hearty, John" To: "Jonathan Rosenberg" , "Elwell, John" Cc: "Rohan Mahy" , "Drage, Keith (Keith)" , X-OriginalArrivalTime: 19 May 2003 14:59:54.0818 (UTC) FILETIME=[4E982220:01C31E17] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JESHB23125 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I'd be interested in seeing all "such headers" listed, and consider security implications carefully before covering them with a blanket rule. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, May 19, 2003 2:03 AM > To: Elwell, John > Cc: 'Rohan Mahy'; 'Drage, Keith (Keith)'; 'sip@ietf.org' > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > I agree that Contact is not the right place to identify the user. > Rather, it is a form of identification for a device. > > There is really a bigger issue here, which is the scope of the > information that can be updated by a target refresh request (of which > UPDATE is one). RFC 3261 refers only to specific pieces of the state > of a dialog which can be updated (cseq, contact headers). There are > other pieces of state held for the lifetime of the dialog, > such as the > UA capabilities (from the Supported header field), methods allowed > (Allow header field), and so on. Can these be updated by a target > refresh request? > > RFC 3261 is silent on this point, and I think the question is similar > to whether an implementation would even update the P-Asserted-ID > header field in a re-INVITE (forgetting UPDATE even). > > Our thinking was really that this information was static, and > therefore would be set by the initial INVITE and not changed > afterwards, although the spec never explicitly states this. The issue > here is that folks believe P-Asserted-ID is NOT static (i.e., because > of a call transfer), and therefore would need to change. I believe > there are actually a few cases where it would change, such as various > 3pcc cases too. > > So, considering the general problem, there are a few solutions: > > 1. Each header field that conveys dialog-associated state would > indicate whether or not that state is updated by a target > refresh request. > > 2. We specify a blanket rule for all such headers that their state is > updated by a target refresh request (absence of a header would imply > no update). > > 3. We specify a blanket rule for all such headers that their state is > never updated by a target refresh request. > > 4. We specify a default rule for all such headers, but allow > individual headers to override it. > > > In the interests of simplicity I would tend to lean towards (2). The > best place for this, of course, is rfc 3261, in which case we should > treat this as a bug against the spec. > > -Jonathan R. > > > Elwell, John wrote: > > Rohan, > > > > The qsig2sip draft is silent on the subject of the contact > header. So too is > > the ISUP-SIP draft (except on the subject of contact headers in 3xx > > response). It is not clear to me that a contact header > should necessarily > > reflect the identity of the remote party in the legacy > network. Therefore > > there may be no need to change the contact header when > transfer occurs in > > the legacy network. > > > > Consider the following case. An INVITE request leaves the > SIP network at an > > egress gateway to QSIG. The gateway receives a QSIG > ALERTING message and > > sends back a 180 response containing a contact header. It > would be possible > > for this contact header to reflect the identity of the > party to whom the > > QSIG SETUP message was directed or, except where prevented > by privacy, the > > identity of the party actually being alerted (can be > different because of > > forwarding). Now, suppose after alerting but before answer > the call is > > forwarded, so that the party who answers is not the party > identified in the > > contact header in the 180 response. What should go in the > contact header of > > the 200 response: the same value that was in the 180 > contact header; or a > > different value reflecting the identity of the answering > party? It is not > > clear to me whether the contact header is allowed to or > should change in > > this situation. > > > > Because if is not always feasible, because of privacy, > forwarding etc. for > > the contact header issued by a gateway always to reflect > the identity of the > > remote party in the legacy network, I see the contact > header primarily as a > > means of identifying the gateway, rather than the remote > party. That is why > > the qsig2sip draft is silent on this issue - the choice of > contact header is > > an implementation matter for the gateway. > > > > Regards, > > > > John > > > > > >>-----Original Message----- > >>From: Rohan Mahy [mailto:rohan@cisco.com] > >>Sent: 13 May 2003 00:12 > >>To: Elwell, John > >>Cc: 'Drage, Keith (Keith)'; 'sip@ietf.org' > >>Subject: Re: [Sip] UPDATE and P-Asserted-ID > >> > >> > >>John, > >> > >>I believe you still should generate a new Contact header, > even if you > >>are only changing the display name. > >> > >>thanks, > >>-rohan > >> > >>On Thursday, May 8, 2003, at 01:21 AM, Elwell, John wrote: > >> > >> > >>>Keith, > >>> > >>>Thanks for your response. However, I do not wish to cover target > >>>refresh. As > >>>I understand from section 12 of RFC3261, local and remote > >> > >>targets are > >> > >>>derived from Contact headers. The scenario I have in mind is where > >>>something > >>>happens behind a gateway. However, the gateway remains the same and > >>>therefore it does not need to generate a new Contact header. > >>> > >>>John (john.elwell@siemens.com) > >>> > >>> > >>>>-----Original Message----- > >>>>From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >>>>Sent: 07 May 2003 19:11 > >>>>To: Elwell, John; 'sip@ietf.org' > >>>>Subject: RE: [Sip] UPDATE and P-Asserted-ID > >>>> > >>>> > >>>>I believe the thinking when the document was developed was > >>>>essentially to allow it in methods that either initiated a > >>>>dialog, or were sent outside of a dialog. There was therefore > >>>>no intent to cover reINVITE at that time, although I do not > >>>>think it was explicitly excluded in the RFC. I am not sure > >>>>how the BYE got added in respect of this, maybe someone else > >>>>can clarify. The NOTIFY is there in respect of a NOTIFY that > >>>>confirms a SUBSCRIBE dialog. > >>>> > >>>>This would allow the exchange of identities between the end > >>>>users under these circumstances. > >>>> > >>>>From what you are indicating, it looks like you would want to > >>>>extend the above to cover target refresh requests. > >>>> > >>>>Keith > >>>> > >>>>Keith Drage > >>>>Lucent Technologies > >>>>Tel: +44 1793 776249 > >>>>Email: drage@lucent.com > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>>Sent: 07 May 2003 10:20 > >>>>>To: 'sip@ietf.org' > >>>>>Subject: [Sip] UPDATE and P-Asserted-ID > >>>>> > >>>>> > >>>>>In RFC3325 section 9.1 it indicates that P-Asserted-ID is not > >>>>>allowed in > >>>>>UPDATE. Does anyone know the reason for this? A useful > >>>>>application would be > >>>>>to indicate a changed asserted identity when a change of > >>>>>party occurs in a > >>>>>legacy network (e.g., due to transfer). If not allowed in > >> > >>UPDATE, a > >> > >>>>>re-INVITE would need to be used, but this introduces an > >>>> > >>>>extra message. > >>>> > >>>>>John Elwell (john.elwell@siemens.com) > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>This list is for NEW development of the core SIP Protocol > >>>>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>>Use sipping@ietf.org for new developments on the > >> > >>application of sip > >> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>Use sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 19 14:36:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00017 for ; Mon, 19 May 2003 14:36:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JI5Dw06398 for sip-archive@odin.ietf.org; Mon, 19 May 2003 14:05:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JI4eB06334; Mon, 19 May 2003 14:04:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JI1lB06239 for ; Mon, 19 May 2003 14:01:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29866; Mon, 19 May 2003 14:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HpSU-0005Zs-00; Mon, 19 May 2003 14:34:02 -0400 Received: from smtpgw6.sprintspectrum.com ([207.40.188.14]) by ietf-mx with esmtp (Exim 4.12) id 19HpSO-0005Zn-00; Mon, 19 May 2003 14:33:56 -0400 Received: from smtpgw8.it.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h4JIYg4x011125; Mon, 19 May 2003 13:34:42 -0500 (CDT) Received: from PKDWG02A.ad.sprint.com (PKDWG02A.corp.sprint.com [10.185.12.80]) by smtpgw8.it.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4JIYgQ07516; Mon, 19 May 2003 13:34:42 -0500 (CDT) Received: from PKDWB01C.ad.sprint.com ([10.185.12.21]) by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 May 2003 13:34:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 2003 13:34:33 -0500 Message-ID: <28B9108644E492469B911D587AABC97C023DEB80@PKDWB01C.ad.sprint.com> Thread-Topic: SIP mobility in WLAN Thread-Index: AcMdwPQXxStz+QMGSTyaItcsGcp5lAAc8ETQ From: "Santharam, Arun [NTWK SVCS]" To: "Rajarshi Chakraborty" , , , Cc: X-OriginalArrivalTime: 19 May 2003 18:34:38.0897 (UTC) FILETIME=[4E1A9210:01C31E35] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JI23B06253 Subject: [Sip] RE: SIP mobility in WLAN Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit If we follow the SIP implementation on Mobile IP then the SIP stack should not have to bother about the mobility aspect. The SIP stack should be notified of IP changes/handoff information (if relevant for the SIP stack) by the underlying stack. This may prompt a SIP registration and subsequent call flows. My 2 cents ... arun > -----Original Message----- > From: Rajarshi Chakraborty [mailto:rajarshi_chakraborty@hotmail.com] > Sent: Sunday, May 18, 2003 11:42 PM > To: drage@lucent.com; ashishn@mahindrabt.com; Santharam, Arun > [NTWK SVCS]; sip@ietf.org > Cc: sipping@ietf.org > Subject: SIP mobility in WLAN > > > Hi, > > Where can I get call-flows for SIP session management in a > wireless LAN > (802.11)? 3GPP only addresses the issues for cellular > networks. Or are they > too trivial to be addressed specially? I am specially interested in > situations of handoffs (in this case, the IP changes as soon > as the host > shifts from the zone around one hotspot to another). Should > SIP bother at > all to detect IP changes or should the control be completely > outside SIP? I > mean should it be some other module that has the > responsibility of informing > the SIP stack in the mobile host about the IP changes, so > that the host may > then send a re-INVITE with a new SDP but the call still > remains active? > > regards > Rajarshi > > > Rajarshi Chakraborty > B-196, IIT Campus, > Kharagpur, > West Bengal, India > PIN-721302 > > > > > > ----Original Message Follows---- > From: "Drage, Keith (Keith)" > To: "'Ashish Naik'" , "Santharam, > Arun [CC]" > , "Sip@Ietf. Org" > Subject: RE: [Sip] Session Mobility in SIP > Date: Thu, 8 May 2003 14:42:24 +0100 > > Your best starting point to see the architecture is 3GPP TS > 23.228, with > reference to 3GPP TS 23.002 to see how these entities fit > together into the > entire 3GPP architecture. > > The SIP protocol application is covered in 3GPP TS 24.229 > with example flows > in 3GPP TS 24.228. > > These documents may be found at: > > ftp://ftp.3gpp.org/Specs/latest/Rel-5/ > > > 3GPP uses these specifications over GPRS to provide mobility. > > There is a parallel set of 3GPP2 specifications, > substantially of common > text, that uses the same architecture over mobile IP, instead > of GPRS. These > documents are currently in 3GPP2 comment and review. > > regards > > Keith > > > > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > -----Original Message----- > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > Sent: 08 May 2003 06:23 > To: Santharam, Arun [CC]; Sip@Ietf. Org > Subject: RE: [Sip] Session Mobility in SIP > > > ok. Is there any specific document on IETF and 3GPP that can > explain how it > is being addressed ? > > > Ragards, > Ashish Naik > CoE Mobile Computing > ----------------------------------- > Phone 4018100 Ext 3070 > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Santharam, > Arun [CC] > Sent: Wednesday, April 09, 2003 9:42 PM > To: Ashish Naik; Sip@Ietf. Org > Subject: RE: [Sip] Session Mobility in SIP > > > > Ashish, > > > > Please find comments inline. > > > > Thank you > > arun > > > > -----Original Message----- > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > Sent: Wednesday, April 09, 2003 4:01 AM > To: Sip@Ietf. Org > Subject: [Sip] Session Mobility in SIP > > > > How is SIP going to address session mobility ? Is there any > initiative taken > up for this ? > > > > > This has been addressed in 3GPP standards. Please refer to > the 3GPP All > IP architecture specifications. > > > > SIP is said to be a better alternative than Mobile IP. Can I > have some > latest development document references ? > > > > > > > SIP is not going to replace Mobile IP. It is going to > leverage Mobile IP > for session management in 3G wireless networks. > > > > > > Regards, > Ashish Naik > ------------------- > CoE Mobile Computing > Phone: 4018100 Ext 3070 > > > > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > > > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > _________________________________________________________________ > Mobile, masti, magic! Cool ringtones & logos. > http://www.msn.co.in/mobile/ > Get noticed > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 19 14:53:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00782 for ; Mon, 19 May 2003 14:53:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JIN0808000 for sip-archive@odin.ietf.org; Mon, 19 May 2003 14:23:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JIMLB07965; Mon, 19 May 2003 14:22:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JILOB07933 for ; Mon, 19 May 2003 14:21:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00676; Mon, 19 May 2003 14:51:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HplT-0005lJ-00; Mon, 19 May 2003 14:53:39 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19HplN-0005l6-00; Mon, 19 May 2003 14:53:33 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4JIrrx5004438; Mon, 19 May 2003 11:53:53 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEH18338; Mon, 19 May 2003 11:53:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06598; Mon, 19 May 2003 11:53:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16073.10303.881278.809327@thomasm-u1.cisco.com> Date: Mon, 19 May 2003 11:53:51 -0700 (PDT) To: "Santharam, Arun [NTWK SVCS]" Cc: "Rajarshi Chakraborty" , , , , Subject: [Sip] RE: SIP mobility in WLAN In-Reply-To: <28B9108644E492469B911D587AABC97C023DEB80@PKDWB01C.ad.sprint.com> References: <28B9108644E492469B911D587AABC97C023DEB80@PKDWB01C.ad.sprint.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Santharam, Arun [NTWK SVCS] writes: > > If we follow the SIP implementation on Mobile IP then the SIP stack > should not have to bother about the mobility aspect. The SIP stack > should be notified of IP changes/handoff information (if relevant for > the SIP stack) by the underlying stack. This may prompt a SIP > registration and subsequent call flows. I think it's a little bit more complicated than this. As with most things, it often makes sense to have logic at many different layers depending on the actual situation you find yourself in. For example, since there isn't route optimization for IPv4, a reinvite with the new correct CoA would rid yourself of the dog-leg through the home agent. But it might complicate QoS reservations and/or treatment, etc. Which is a round about way of saying "it depends". 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 mailnull@www1.ietf.org Mon May 19 16:21:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04843 for ; Mon, 19 May 2003 16:21:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JJoGO14099 for sip-archive@odin.ietf.org; Mon, 19 May 2003 15:50:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JJnOB14072; Mon, 19 May 2003 15:49:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JJkwB13968 for ; Mon, 19 May 2003 15:46:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04786 for ; Mon, 19 May 2003 16:17:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hr6F-0006GF-00 for sip@ietf.org; Mon, 19 May 2003 16:19:11 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19Hr69-0006Ft-00 for sip@ietf.org; Mon, 19 May 2003 16:19:05 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4JKIPBP016693; Mon, 19 May 2003 13:18:29 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEH27866; Mon, 19 May 2003 13:17:49 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA06726; Mon, 19 May 2003 13:17:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16073.15341.51523.612757@thomasm-u1.cisco.com> Date: Mon, 19 May 2003 13:17:49 -0700 (PDT) To: Jonathan Rosenberg Cc: "Elwell, John" , "'Rohan Mahy'" , "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Subject: Re: [Sip] UPDATE and P-Asserted-ID In-Reply-To: <3EC88FBB.1080107@dynamicsoft.com> References: <3EC88FBB.1080107@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > 1. Each header field that conveys dialog-associated state would > indicate whether or not that state is updated by a target refresh request. > > 2. We specify a blanket rule for all such headers that their state is > updated by a target refresh request (absence of a header would imply > no update). > > 3. We specify a blanket rule for all such headers that their state is > never updated by a target refresh request. > > 4. We specify a default rule for all such headers, but allow > individual headers to override it. > > > In the interests of simplicity I would tend to lean towards (2). The > best place for this, of course, is rfc 3261, in which case we should > treat this as a bug against the spec. This seems quite reasonable to me as well -- special casing "initial" from subsequent dialog seems pretty fraught. The only reason that I can think of why you might want to do that is when the state assembly/teardown of a mid-session change was so onerous and/or ambiguous to other state that it was prudent to set up the state once and leave it be. It doesn't seem to me that that's the case here, but I'm hardly an expert. 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 mailnull@www1.ietf.org Tue May 20 13:47:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22779 for ; Tue, 20 May 2003 13:47:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KHDU619615 for sip-archive@odin.ietf.org; Tue, 20 May 2003 13:13:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHCXB19494; Tue, 20 May 2003 13:12:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KH85B19264 for ; Tue, 20 May 2003 13:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22547 for ; Tue, 20 May 2003 13:41:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IB5b-00079D-00 for sip@ietf.org; Tue, 20 May 2003 13:39:51 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19IB5a-000798-00 for sip@ietf.org; Tue, 20 May 2003 13:39:50 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 20 May 2003 10:40:45 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 20 May 2003 10:40:45 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD02883051@mailserver.sylantro.com> From: "Fred O'Leary" To: sip@ietf.org cc: "Dev Goyal" Date: Tue, 20 May 2003 10:40:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12D4B71729739-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Out of sequence datagrams Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Please refer to the snippet from "12.2.2 UAS Behavior" of RFC3261 .... If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order .... Because the ordering of UDP datagrams isn't guarenteed, it is possible for the above to occur. For example NOTIFY with CSEQ 2 is received after the BYE with CSeq 3. Since, from the application perpective, the dialog has ended, there appears no way the NOTIFY can be processed by the UAS. Any ideas much appreciated. Fred O'Leary MTS Sylantro Systems Corp. (408)626-3040 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 20 15:13:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26422 for ; Tue, 20 May 2003 15:13:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KIdeV26299 for sip-archive@odin.ietf.org; Tue, 20 May 2003 14:39:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KIcUB26236; Tue, 20 May 2003 14:38:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KIYMB25215 for ; Tue, 20 May 2003 14:34:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25777 for ; Tue, 20 May 2003 15:07:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ICR4-0007k8-00 for sip@ietf.org; Tue, 20 May 2003 15:06:06 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19ICR3-0007k5-00 for sip@ietf.org; Tue, 20 May 2003 15:06:05 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h4KJ7OhP045317; Tue, 20 May 2003 15:07:25 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Out of sequence datagrams Date: Tue, 20 May 2003 15:11:45 -0400 Message-ID: <000601c31f03$a81fb8c0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD02883051@mailserver.sylantro.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Please refer to the snippet from > "12.2.2 UAS Behavior" of RFC3261 > > .... > If the remote sequence number is empty, > it MUST be set to the value of the sequence > number in the CSeq header field value in > the request. > If the remote sequence number was not empty, > but the sequence number of the request is lower > than the remote sequence number, the request > is out of order > .... > > Because the ordering of UDP datagrams isn't > guarenteed, it is possible for the above to occur. > For example NOTIFY with CSEQ 2 is received after > the BYE with CSeq 3. Since, from the application > perpective, the dialog has ended, there appears no > way the NOTIFY can be processed by the UAS. If order is important, requests should be queued until the prior request has been acknowledged. However concerning your BYE and NOTIFY example, the BYE only terminates the call associated with the dialog. The BYE does not necessarily terminate subscriptions associated with the dialog. Thus if the NOTIFY relates to the implicit subscription caused by a REFER, the notifies can continue to be sent after the BYE has released the call associated with the dialog. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 20 16:06:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28505 for ; Tue, 20 May 2003 16:06:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KJWuU29571 for sip-archive@odin.ietf.org; Tue, 20 May 2003 15:32:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KJWUB29520; Tue, 20 May 2003 15:32:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KJT5B29353 for ; Tue, 20 May 2003 15:29:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28420 for ; Tue, 20 May 2003 16:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IDI0-0000Kg-00 for sip@ietf.org; Tue, 20 May 2003 16:00:48 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19IDHz-0000KK-00 for sip@ietf.org; Tue, 20 May 2003 16:00:47 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4KK1MeS001005; Tue, 20 May 2003 13:01:22 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHH50932; Tue, 20 May 2003 12:54:00 -0700 (PDT) Date: Tue, 20 May 2003 13:01:47 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Dean Willis'" , jon.peterson@neustar.biz, Gonzalo.Camarillo@ericsson.com, "'Robert Sparks'" , rohan@cisco.com, "'Adam Roach'" To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for event-list extension Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Everyone, The SIMPLE Working Group already issued a last call for this, but the SIP Working Group has been asked to issue a short working group last call for this extension as well, since it contains an option-tag (the tokens used in the Require and Supported headers). So, I would like to begin an abbreviated last call in SIP for: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-03.txt This WGLC ends June 6, 2003 thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 20 17:20:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00811 for ; Tue, 20 May 2003 17:20:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KKkvl02513 for sip-archive@odin.ietf.org; Tue, 20 May 2003 16:46:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KKkCB02461; Tue, 20 May 2003 16:46:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KKiCB02386 for ; Tue, 20 May 2003 16:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00705 for ; Tue, 20 May 2003 17:17:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IESf-0000mS-00 for sip@ietf.org; Tue, 20 May 2003 17:15:53 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19IESe-0000lw-00 for sip@ietf.org; Tue, 20 May 2003 17:15:52 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 20 May 2003 14:16:17 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 20 May 2003 14:16:17 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD0288315E@mailserver.sylantro.com> From: "Fred O'Leary" To: brett@broadsoft.com, sip@ietf.org Subject: RE: [Sip] Out of sequence datagrams Date: Tue, 20 May 2003 14:16:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12D444AB35433-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is what suspected. Yes the NOTIFY is a result of the implicit SUBSCRIPTION caused by the REFER. So from an implementation perspective, what is/should be the CSEQ relationship between NOTIFY CSEQ and the INVITE dialog? (If there is none, the UAS would need to differentiate NOTIFY CSEQ's from the INVITE/BYE even though the call identifers are the same.) -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: Tuesday, May 20, 2003 12:12 PM To: sip@ietf.org Subject: RE: [Sip] Out of sequence datagrams > Please refer to the snippet from > "12.2.2 UAS Behavior" of RFC3261 > > .... > If the remote sequence number is empty, > it MUST be set to the value of the sequence > number in the CSeq header field value in > the request. > If the remote sequence number was not empty, > but the sequence number of the request is lower > than the remote sequence number, the request > is out of order > .... > > Because the ordering of UDP datagrams isn't > guarenteed, it is possible for the above to occur. > For example NOTIFY with CSEQ 2 is received after > the BYE with CSeq 3. Since, from the application > perpective, the dialog has ended, there appears no > way the NOTIFY can be processed by the UAS. If order is important, requests should be queued until the prior request has been acknowledged. However concerning your BYE and NOTIFY example, the BYE only terminates the call associated with the dialog. The BYE does not necessarily terminate subscriptions associated with the dialog. Thus if the NOTIFY relates to the implicit subscription caused by a REFER, the notifies can continue to be sent after the BYE has released the call associated with the dialog. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 mailnull@www1.ietf.org Tue May 20 18:56:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04747 for ; Tue, 20 May 2003 18:56:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KMMag10695 for sip-archive@odin.ietf.org; Tue, 20 May 2003 18:22:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KMM1B10658; Tue, 20 May 2003 18:22:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KMKSB10587 for ; Tue, 20 May 2003 18:20:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04638 for ; Tue, 20 May 2003 18:53:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IFxn-0001XE-00 for sip@ietf.org; Tue, 20 May 2003 18:52:07 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19IFxn-0001XB-00 for sip@ietf.org; Tue, 20 May 2003 18:52:07 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h4KMrRkK061476; Tue, 20 May 2003 18:53:27 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Out of sequence datagrams Date: Tue, 20 May 2003 18:57:48 -0400 Message-ID: <000e01c31f23$3cb11320$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD0288315E@mailserver.sylantro.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > This is what suspected. Yes the NOTIFY is > a result of the implicit SUBSCRIPTION caused > by the REFER. So from an implementation > perspective, what is/should be the CSEQ relationship > between NOTIFY CSEQ and the INVITE dialog? They subscription and call share the same dialog. Thus the cseq must continue to increment upon each sent request. Your prior example of a NOTIFY with cseq value 2 being received after a BYE with cseq value 3 could produce several results. If the UAS does not care about refer related notifies after processing a BYE, it could return a 481 to avoid a resend or future notifies. It the notify contained a subscription-state of terminated, the UAS could return a 200, 481, or 500. If the 500 is returned, the UAC might not actually bump the cseq and resend the request; thus it might lead to a delay in subscription cleanup on the referrer. If the UAS does still care about the notifies and subscription-state is not terminated, it should return a 500 response to inform the UAC that it was received out of order. Since the 500 isn't only used for incorrectly order cseq, adding a retry-after header with a small value communicates that the UAS would like the UAC to try again if needed. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 21 01:29:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12712 for ; Wed, 21 May 2003 01:29:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L4tgL03511 for sip-archive@odin.ietf.org; Wed, 21 May 2003 00:55:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L4tCB03497; Wed, 21 May 2003 00:55:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GCpCB08010 for ; Fri, 16 May 2003 08:51:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22906 for ; Fri, 16 May 2003 09:23:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GfCq-0006sk-00 for sip@ietf.org; Fri, 16 May 2003 09:25:04 -0400 Received: from [203.94.249.22] (helo=alice.acmet.com) by ietf-mx with esmtp (Exim 4.12) id 19GfCn-0006sh-00 for sip@ietf.org; Fri, 16 May 2003 09:25:02 -0400 Received: from sumitarora ([192.168.0.140]) by alice.acmet.com (8.11.3/8.11.3) with ESMTP id h4GDWJw25927 for ; Fri, 16 May 2003 19:02:19 +0530 From: "Sumit Arora , Noida" To: Date: Fri, 16 May 2003 18:56:33 +0530 Message-ID: <000801c31bae$c4d48f70$8c00a8c0@sumitarora> 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.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Doubt in Sec-8.2 ,rfc-3261(SIP) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear sir, I am having doubt on these lines from rfc-3261 , Sec-8.2, UAS behavior " Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed." Is this above MUST and MUST not requirement , Talking about the state machine in Section - 17.2 Server Transaction. Kindly reply. Thanx -Sumit Arora - _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 21 07:50:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15352 for ; Wed, 21 May 2003 07:50:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LBH5o08199 for sip-archive@odin.ietf.org; Wed, 21 May 2003 07:17:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LBEqB08139; Wed, 21 May 2003 07:14:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LBBGB07986 for ; Wed, 21 May 2003 07:11:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15240 for ; Wed, 21 May 2003 07:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IRzS-00055s-00 for sip@ietf.org; Wed, 21 May 2003 07:42:38 -0400 Received: from mirlo.dit.upm.es ([138.4.5.18]) by ietf-mx with esmtp (Exim 4.12) id 19IRzN-00055p-00 for sip@ietf.org; Wed, 21 May 2003 07:42:33 -0400 Received: from faisn (faisan [138.4.50.4]) by mirlo.dit.upm.es (8.8.5/8.7.3) with ESMTP id LAA09562 for ; Wed, 21 May 2003 11:43:58 GMT From: "Manuel Moreno" To: Date: Wed, 21 May 2003 13:44:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C31F9F.14A42A30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sip] question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_006F_01C31F9F.14A42A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, please: How is used SIP for applications of chats? How I can be informed on the matter? Thank you Manuel ------=_NextPart_000_006F_01C31F9F.14A42A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all, please:

 

How is used SIP for applications of = chats?

 

How I can be informed on the = matter?

 

Thank you

 

Manuel

------=_NextPart_000_006F_01C31F9F.14A42A30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 21 09:53:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21264 for ; Wed, 21 May 2003 09:53:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LDKj219516 for sip-archive@odin.ietf.org; Wed, 21 May 2003 09:20:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LDKHB19463; Wed, 21 May 2003 09:20:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LDITB19309 for ; Wed, 21 May 2003 09:18:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21189 for ; Wed, 21 May 2003 09:51:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ITyX-0006rv-00 for sip@ietf.org; Wed, 21 May 2003 09:49:49 -0400 Received: from f109.law15.hotmail.com ([64.4.23.109] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19ITyW-0006rF-00 for sip@ietf.org; Wed, 21 May 2003 09:49:48 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 May 2003 06:50:39 -0700 Received: from 212.143.185.30 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 21 May 2003 13:50:38 GMT X-Originating-IP: [212.143.185.30] X-Originating-Email: [james_s_ford@hotmail.com] From: "James Ford" To: sip@ietf.org Date: Wed, 21 May 2003 13:50:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 May 2003 13:50:39.0400 (UTC) FILETIME=[F6992A80:01C31F9F] Subject: [Sip] TCP timeout Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I was wondering how to handle TCP timeouts with SIP. If a connection is opened to a _non existing_ destination, the TCP stack (using non-blocking sockets and select) will only inform about an error after a TCP timeout (that can be considerably long on some systems). (Existing destination with no listening port usually facilitates ICMP and "tells" that there is no listener). My understanding is that SIP handles that by implementing invite timeout that is T1*64 (which is also quite long). Here are the issues I'm struggling with: 1 - Does SIP has any other mechanism to handle such scenarios (H323 facilitates a 4 seconds timeout on every outgoing call)? 2 - Doesn't this scenario compromises part of rfc3263 - locating sip servers, because the user is not likely to wait that long until a second server is reached. Thanks, James. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 21 10:56:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24176 for ; Wed, 21 May 2003 10:56:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LENdL24811 for sip-archive@odin.ietf.org; Wed, 21 May 2003 10:23:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LEN7B24736; Wed, 21 May 2003 10:23:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LECIB24167 for ; Wed, 21 May 2003 10:12:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23924 for ; Wed, 21 May 2003 10:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IUob-0007Iu-00 for sip@ietf.org; Wed, 21 May 2003 10:43:37 -0400 Received: from uni02du.unity.ncsu.edu ([152.1.13.102]) by ietf-mx with esmtp (Exim 4.12) id 19IUoa-0007Ir-00 for sip@ietf.org; Wed, 21 May 2003 10:43:37 -0400 Received: (from prsinha@localhost) by uni02du.unity.ncsu.edu (8.8.4/EC02Jan97) id KAA09782; Wed, 21 May 2003 10:44:58 -0400 (EDT) Date: Wed, 21 May 2003 10:44:58 -0400 (EDT) From: Prabhas Ranjan Sinha To: sip@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] WLAN & SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Is there any draft on SIP usage in WLAN arena ? Any help would be appreciated. Prabhas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed May 21 21:47:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15291 for ; Wed, 21 May 2003 21:47:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4M1EUU04638 for sip-archive@odin.ietf.org; Wed, 21 May 2003 21:14:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M1DaB04574; Wed, 21 May 2003 21:13:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M18PB04439 for ; Wed, 21 May 2003 21:08:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15159 for ; Wed, 21 May 2003 21:40:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19If3K-0004JZ-00 for sip@ietf.org; Wed, 21 May 2003 21:39:30 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19If3J-0004IM-00 for sip@ietf.org; Wed, 21 May 2003 21:39:29 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4M1eIJV002024; Wed, 21 May 2003 18:40:18 -0700 (PDT) Received: from [12.163.13.67] (sjc-vpn2-527.cisco.com [10.21.114.15]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEJ70824; Wed, 21 May 2003 18:40:17 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 21 May 2003 15:07:13 -0700 Subject: Re: [Sip] WGLC for auth-id body From: Cullen Jennings To: sip-ietf , Jon Peterson CC: Dean Willis , , Rohan Mahy Message-ID: In-Reply-To: <9131FA75-85A4-11D7-8E16-0003938AF740@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have a concern about SIP security (I've always wanted to start and email that way :-) If A sends a request to B and B puts an AIB in the response, I think the response AIB should have a To: B and not have a From: B. The reason is fairly simple - Imagine A is an attacker and is watching some call B is having with C. A wants to insert a message into this call flow - It knows the Call-ID and appropriate tags and such. A can guess a CSeq that will likely work. Now A sends a request to B with all this stuff and B sends A a signed AIB that A can now use to send to C and impersonate B. On the minor NITs level ... It would be nice to add some text on tags in To From and if they should be inserted or not and if they must match. Use a binary transfer encoding instead of base64 in all of the examples. I know this is a pain in the RFC but I think it is what we should use in SIP. Point out that detached signatures SHOULD be used. Clarify if the signature is computed over --------- Content-Type: ... Content-Disposition: ... From:... To:.... ------- Or over --------- From:... To:.... ------- The outer SIP message in example 3 does not have a Content-Length. I like the draft. On 5/13/03 5:39 PM, "Rohan Mahy" wrote: > Hello Everyone, > > I would like to begin Working Group Last Call on > > http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-01.txt > > WGLC will end on Friday, June 13, 2003. > > thanks, > -rohan > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 22 08:56:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11752 for ; Thu, 22 May 2003 08:56:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MCNRO02355 for sip-archive@odin.ietf.org; Thu, 22 May 2003 08:23:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCHTB01934; Thu, 22 May 2003 08:17:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCDRB01717 for ; Thu, 22 May 2003 08:13:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11560 for ; Thu, 22 May 2003 08:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IpQg-00012h-00 for sip@ietf.org; Thu, 22 May 2003 08:44:18 -0400 Received: from comsrv.com.dtu.dk ([192.38.77.2]) by ietf-mx with esmtp (Exim 4.12) id 19IpQf-00012e-00 for sip@ietf.org; Thu, 22 May 2003 08:44:17 -0400 Received: by comsrv.com.dtu.dk with Internet Mail Service (5.5.2650.21) id ; Thu, 22 May 2003 14:45:40 +0200 Message-ID: <0FAFFBDC8353D211B00A00104B0CDCBF01C9F697@comsrv.com.dtu.dk> From: =?iso-8859-1?Q?Jos=E9_Soler_Lucas?= To: "'sip@ietf.org'" Date: Thu, 22 May 2003 14:45:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32060.0BEA9CA0" Subject: [Sip] Doubt about SIP Specific Event Notification behaviour Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C32060.0BEA9CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, =20 trying to imagine a service based on the SUBSCRIBE - NOTIFY methods of = SIP described in RFC 3265 I have came across a doubt that I was not able to = find a respose to through the different documents I have checked. Could = anyone out there please give me any hint on the matter?: =20 Imagine I have a SIP client that subscribes to a certain event = happening in a server. The subscription is acepted and performs properly. After a = moment, while the subscription is still active, there is an internal problem in = the server that prevents further NOTIFYes towards the subscribing client. = The question is: =20 a) Does the server send a 5xx message towards the client? or b) Does the server send a NOTIFY with a "pending" status indicating a temporal suspension of the subscription? or c) Does the server send a NOTIFY with a "terminated" status forcing the = end of the subscription? d) Should the server send rather [5xx] followed by [NOTIFY(status=3Dpending/terminated)]?=20 =20 If the answer is (a), what should the behavior of the client then be, = to assume the subscription as terminated? =20 Thanks in advance for your help. Best regards, =20 jos=E9 --------------------------------------------=20 Jos=E9 Soler Lucas, M.Sc.Telecom.E.=20 PhD Student=20 Networks Competence Area=20 Research Center COM (Communications, Optics and Materials)=20 Technical University of Denmark=20 Building 343, DK 2800 Kgs. Lyngby, Denmark.=20 Phone: +45 45 25 38 08 (direct)=20 Fax: +45 45 93 65 81=20 E-mail: jsoler@com.dtu.dk=20 Web: http://www.com.dtu.dk/=20 ----=20 Cellular: +45 22 27 48 22=20 --------------------------------------------=20 =20 ------_=_NextPart_001_01C32060.0BEA9CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 everyone,
 
trying to imagine a=20 service based on the SUBSCRIBE - NOTIFY methods of SIP described in RFC = 3265 I=20 have came across a doubt that I was not able to find a respose to = through the=20 different documents I have checked. Could anyone out there please give = me any=20 hint on the matter?:
 
Imagine I have a SIP=20 client that subscribes to a certain event happening in a server. The=20 subscription is acepted and performs properly. After a moment, while = the=20 subscription is still active, there is an internal problem in the = server that=20 prevents further NOTIFYes towards the subscribing client. The question=20 is:
 
a) = Does the server=20 send a 5xx message towards the client? or
b) = Does the server=20 send a NOTIFY with a "pending" status indicating a temporal suspension = of the=20 subscription? or
c) = Does the server=20 send a NOTIFY with a "terminated" status forcing the end of the=20 subscription?
d) = Should the server=20 send rather [5xx] followed by=20 [NOTIFY(status=3Dpending/terminated)]? 
 
If = the answer is=20 (a), what should the behavior of the client then be, to assume the = subscription=20 as terminated?
 
Thanks in advance=20 for your help.
Best=20 regards,
 
jos=E9

-------------------------------------------- =
Jos=E9 Soler Lucas, = M.Sc.Telecom.E.
PhD Student
Networks Competence Area
Research Center COM (Communications, Optics and = Materials)=20
Technical University of = Denmark=20
Building 343, DK 2800 Kgs. = Lyngby,=20 Denmark.
Phone: +45 45 = 25 38 08=20 (direct)
Fax:   +45 45 93=20 65 81
E-mail:=20 jsoler@com.dtu.dk
Web: = http://www.com.dtu.dk/
----
Cellular: +45 22 27 48 22
-------------------------------------------- =



 
------_=_NextPart_001_01C32060.0BEA9CA0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 22 08:59:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11825 for ; Thu, 22 May 2003 08:59:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MCQNH02539 for sip-archive@odin.ietf.org; Thu, 22 May 2003 08:26:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCPKB02467; Thu, 22 May 2003 08:25:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCLpB02266 for ; Thu, 22 May 2003 08:21:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11722 for ; Thu, 22 May 2003 08:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IpYo-00015m-00 for sip@ietf.org; Thu, 22 May 2003 08:52:42 -0400 Received: from comsrv.com.dtu.dk ([192.38.77.2]) by ietf-mx with esmtp (Exim 4.12) id 19IpYn-00015i-00 for sip@ietf.org; Thu, 22 May 2003 08:52:41 -0400 Received: by comsrv.com.dtu.dk with Internet Mail Service (5.5.2650.21) id ; Thu, 22 May 2003 14:54:04 +0200 Message-ID: <0FAFFBDC8353D211B00A00104B0CDCBF01C9F699@comsrv.com.dtu.dk> From: =?iso-8859-1?Q?Jos=E9_Soler_Lucas?= To: "'sip@ietf.org'" Date: Thu, 22 May 2003 14:54:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32061.391D8BA0" Subject: [Sip] RE: Doubt about SIP Specific Event Notification behaviour Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C32061.391D8BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry. I made a wrong formulation of the question. It should be like = that: =20 "...internal problem in the server that prevents to have knowledge of = the events the client is interested on and so notify about them properly to = the client despite the event is happening. The question is...." =20 Thanks and sorry for the duplication, =20 jose -----Original Message----- From: Jos=E9 Soler Lucas=20 Sent: 22. maj 2003 14:46 To: 'sip@ietf.org' Subject: Doubt about SIP Specific Event Notification behaviour Hi everyone, =20 trying to imagine a service based on the SUBSCRIBE - NOTIFY methods of = SIP described in RFC 3265 I have came across a doubt that I was not able to = find a respose to through the different documents I have checked. Could = anyone out there please give me any hint on the matter?: =20 Imagine I have a SIP client that subscribes to a certain event = happening in a server. The subscription is acepted and performs properly. After a = moment, while the subscription is still active, there is an internal problem in = the server that prevents further NOTIFYes towards the subscribing client. = The question is: =20 a) Does the server send a 5xx message towards the client? or b) Does the server send a NOTIFY with a "pending" status indicating a temporal suspension of the subscription? or c) Does the server send a NOTIFY with a "terminated" status forcing the = end of the subscription? d) Should the server send rather [5xx] followed by [NOTIFY(status=3Dpending/terminated)]?=20 =20 If the answer is (a), what should the behavior of the client then be, = to assume the subscription as terminated? =20 Thanks in advance for your help. Best regards, =20 jos=E9 --------------------------------------------=20 Jos=E9 Soler Lucas, M.Sc.Telecom.E.=20 PhD Student=20 Networks Competence Area=20 Research Center COM (Communications, Optics and Materials)=20 Technical University of Denmark=20 Building 343, DK 2800 Kgs. Lyngby, Denmark.=20 Phone: +45 45 25 38 08 (direct)=20 Fax: +45 45 93 65 81=20 E-mail: jsoler@com.dtu.dk=20 Web: http://www.com.dtu.dk/=20 ----=20 Cellular: +45 22 27 48 22=20 --------------------------------------------=20 =20 ------_=_NextPart_001_01C32061.391D8BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Sorry. I made a wrong formulation of = the=20 question. It should be like that:
 
"...internal problem in the server that = prevents to=20 have knowledge of the events the client is interested on and so notify = about=20 them properly to the client despite the event is happening. The = question=20 is...."
 
Thanks=20 and sorry for the duplication,
 
jose
-----Original Message-----
From: Jos=E9 Soler = Lucas=20
Sent: 22. maj 2003 14:46
To:=20 'sip@ietf.org'
Subject: Doubt about SIP Specific Event = Notification=20 behaviour

Hi=20 everyone,
 
trying to imagine=20 a service based on the SUBSCRIBE - NOTIFY methods of SIP described in = RFC 3265=20 I have came across a doubt that I was not able to find a respose to = through=20 the different documents I have checked. Could anyone out there please = give me=20 any hint on the matter?:
 
Imagine I have a=20 SIP client that subscribes to a certain event happening in a server. = The=20 subscription is acepted and performs properly. After a moment, while = the=20 subscription is still active, there is an internal problem in the = server that=20 prevents further NOTIFYes towards the subscribing client. The = question=20 is:
 
a) = Does the server=20 send a 5xx message towards the client? or
b) = Does the server=20 send a NOTIFY with a "pending" status indicating a temporal = suspension of the=20 subscription? or
c) = Does the server=20 send a NOTIFY with a "terminated" status forcing the end of the=20 subscription?
d) = Should the=20 server send rather [5xx] followed by=20 [NOTIFY(status=3Dpending/terminated)]? 
 
If = the answer is=20 (a), what should the behavior of the client then be, to assume the=20 subscription as terminated?
 
Thanks in advance=20 for your help.
Best=20 regards,
 
jos=E9

-------------------------------------------- =
Jos=E9 Soler Lucas, = M.Sc.Telecom.E.
PhD Student
Networks Competence Area
Research Center COM (Communications, Optics and = Materials)=20
Technical University of = Denmark=20
Building 343, DK 2800 Kgs. = Lyngby,=20 Denmark.
Phone: +45 45 = 25 38 08=20 (direct)
Fax:   +45 45 93=20 65 81
E-mail:=20 jsoler@com.dtu.dk
Web: = http://www.com.dtu.dk/
----
Cellular: +45 22 27 48 22
-------------------------------------------- =



 
------_=_NextPart_001_01C32061.391D8BA0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu May 22 09:18:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12629 for ; Thu, 22 May 2003 09:18:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MCk4G04986 for sip-archive@odin.ietf.org; Thu, 22 May 2003 08:46:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCjXB04904; Thu, 22 May 2003 08:45:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCglB04626 for ; Thu, 22 May 2003 08:42:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12333 for ; Thu, 22 May 2003 09:15:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ipt3-0001Hc-00 for sip@ietf.org; Thu, 22 May 2003 09:13:37 -0400 Received: from taurus.polito.it ([130.192.1.8]) by ietf-mx with smtp (Exim 4.12) id 19Ipt2-0001Ge-00 for sip@ietf.org; Thu, 22 May 2003 09:13:36 -0400 Received: (qmail 6080 invoked from network); 22 May 2003 13:17:26 -0000 Received: from sl-srv0.polito.it (HELO vaio) (130.192.1.240) by 0 with SMTP; 22 May 2003 13:17:26 -0000 Message-ID: <002701c32063$dd0db4e0$f001c082@vaio> From: "Roberto Tealdi" To: , Subject: [SIP] Hierarchical Registration Date: Thu, 22 May 2003 15:12:45 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0021_01C32074.99469220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C32074.99469220 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0022_01C32074.99469220" ------=_NextPart_001_0022_01C32074.99469220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, I'm new on SIP, I have a question about registration procedures, = expecially the Hierarchical Registration described in Shulzrinne's = article "Application-Layer Mobility Using SIP". Suppose this scenario, there are 2 domains (Visited Network and Home = Network) and there is a SIP registrar proxy in each domain;=20 1) a user in the visited network wants to register himself at his home = network. UAC sends a REGISTER message; in this message the Contact = header is set with the current IP address of the UAC. The message has a = digital signature in order to provide integrity and authentication, such = digital signature include the following headers: To, From, Contact, = Date, C-Seq, Call-ID. 2) Suppose to implement the hierarchical registration as described in = some Schulzrinne's articles: the SIP outbound proxy in the visited = domain when receives this message has to change the Contact header = putting in it its own address, before forwarding the REGISTER message to = the user's home network. This is done in order to receive and inspect = (by the proxy in the visited network) all incoming messages for the user = visiting in. But if the Contact header is changed, the digital signature = is compromised. The UAC should know the "correct" Contact value before doing the digital = signature in his REGISTER messages. How can the proxy do to "inform" the UAC about this "correct" value? Are = there existing mechanism? Is possible to do it with 4xx messages? Note: the UAC signs his messages with his private key, the visited proxy = do not know this key. I was supposing that this would be a possible solution (see the = Scenario.txt attach): The Visited Proxy in the "4xx Contact Not Acceptable" notify the UAC the = correct value to put in the Contact header, and in the successive = REGISTER message the UAC fill the header with this new value. The = Visited Register does not need to made any changes in the REGISTER = message so the digital signature is still valid. It would be possible this solution or there are other mechanisms? Thank you very much for Your helps. Roby. ------=_NextPart_001_0022_01C32074.99469220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
I'm new on SIP, I have a question about = registration procedures, expecially the Hierarchical Registration = described in=20 Shulzrinne's article "Application-Layer Mobility Using = SIP".
 
Suppose this scenario, there are 2 = domains (Visited=20 Network and Home Network) and there is a SIP registrar proxy in each = domain;=20

1) a user in the visited network wants to register = himself  at=20 his home network. UAC sends a REGISTER message; in this message the = Contact=20 header is set with the current IP address of the UAC. The message has a = digital=20 signature in order to provide integrity and authentication, such = digital=20 signature include the following headers: To, From, Contact, Date, C-Seq, = Call-ID.

2) Suppose to implement the hierarchical registration as = described in some Schulzrinne's articles: the SIP outbound proxy in = the=20 visited domain when receives this message has to change the Contact = header=20 putting in it its own address, before forwarding the REGISTER = message to=20 the user's home network. This is done in order to receive and = inspect=20 (by the proxy in the visited network) all incoming messages for the = user=20 visiting in. But if the Contact header is changed, the digital signature = is=20 compromised.

The UAC should know the "correct" Contact value = before doing=20 the digital signature in his REGISTER messages.

How can the proxy = do to=20 "inform" the UAC about this "correct" value? Are there existing = mechanism? Is=20 possible to do it with 4xx messages?
 
Note: the UAC signs his messages with = his private=20 key, the visited proxy do not know this key.

I was supposing that = this=20 would be a possible solution (see the Scenario.txt attach):

The = Visited=20 Proxy in the "4xx Contact Not Acceptable" notify the UAC the = correct value=20 to put in the Contact header, and in the successive REGISTER message the = UAC=20 fill the header with this new value. The Visited Register does not need = to made=20 any changes in the REGISTER message so the digital signature is still=20 valid.
 
It would be = possible this=20 solution or there are other mechanisms?

Thank you very much for Your=20 helps.
Roby.
 ------=_NextPart_001_0022_01C32074.99469220-- ------=_NextPart_000_0021_01C32074.99469220 Content-Type: text/plain; name="Scenario.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Scenario.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable UAC Visited Registrar = Home Registrar | REGISTER | = | |--------------------------------------------->| = | | | = | | 4xx Contact Address Not Acceptable | = | |<---------------------------------------------| | =20 | | = | | REGISTER (with new Contact) | = | |--------------------------------------------->| = | | | = REGISTER | | = |----------------------------------------->| | | = | | | 200 = OK | | = |<-----------------------------------------| | 200 OK | = | |<---------------------------------------------| = | | | = | ------=_NextPart_000_0021_01C32074.99469220-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 23 13:48:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16737 for ; Fri, 23 May 2003 13:48:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHmGi12108 for sip-archive@odin.ietf.org; Fri, 23 May 2003 13:48:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHlQB11603; Fri, 23 May 2003 13:47:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4N9oqB01539 for ; Fri, 23 May 2003 05:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00814 for ; Fri, 23 May 2003 06:22:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19J9fn-0003nE-00 for sip@ietf.org; Fri, 23 May 2003 06:21:15 -0400 Received: from h21s128a211n47.user.nortelnetworks.com ([47.211.128.21] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19J9fm-0003mo-00 for sip@ietf.org; Fri, 23 May 2003 06:21:15 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NALeG20255; Fri, 23 May 2003 11:21:40 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 May 2003 11:21:26 +0100 Message-ID: From: "Mark Watson" To: "'Michael Thomas'" , Jonathan Rosenberg Cc: "Elwell, John" , "'Rohan Mahy'" , "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Subject: RE: [Sip] UPDATE and P-Asserted-ID Date: Fri, 23 May 2003 11:21:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32115.1108E010" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C32115.1108E010 Content-Type: text/plain; charset="iso-8859-1" Jonathan's approach seems reasonable, and since P-Asserted-Id just represents the identity of the originator of the *message* we could expect it to change during a dialog - I suppose there is a philosphical question that if the identity of the SIP UAS changes, does that mean it is now a logically different UAS and so a new dialog should be established ? even if it's the same physical device so that all the state needed to maintain a single dialog is still available ?? I guess this is the case when call forward/transfer happens downstream of a SIP->X gateway. Equally, were a device to de-register and re-register with a new Address Of Record, does this represent an 'identity change' for that UA ? Could it meaningfully update its identity in any ongoing dialogs ? I think there should be scope for individual headers to specify that their state cannot be updated mid-dialog. Not having looked through all the 'such headers' referred to by Jonathan (not even knowing what this list is!) we can't rule out that the meaning of a mid-dialog update for one of these might not be well-defined i.e. it has no sensible meaning or is ambiguous. In those cases we would need to rule out mid-dialog updates, or define the meaning of them for that header. ...Mark > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 19 May 2003 21:18 > To: Jonathan Rosenberg > Cc: Elwell, John; 'Rohan Mahy'; 'Drage, Keith (Keith)'; 'sip@ietf.org' > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > Jonathan Rosenberg writes: > > 1. Each header field that conveys dialog-associated state would > > indicate whether or not that state is updated by a target > refresh request. > > > > 2. We specify a blanket rule for all such headers that > their state is > > updated by a target refresh request (absence of a header > would imply > > no update). > > > > 3. We specify a blanket rule for all such headers that > their state is > > never updated by a target refresh request. > > > > 4. We specify a default rule for all such headers, but allow > > individual headers to override it. > > > > > > In the interests of simplicity I would tend to lean > towards (2). The > > best place for this, of course, is rfc 3261, in which case > we should > > treat this as a bug against the spec. > > This seems quite reasonable to me as well -- > special casing "initial" from subsequent dialog > seems pretty fraught. The only reason that I can > think of why you might want to do that is when the > state assembly/teardown of a mid-session change > was so onerous and/or ambiguous to other state > that it was prudent to set up the state once and > leave it be. It doesn't seem to me that that's the > case here, but I'm hardly an expert. > > 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 > ------_=_NextPart_001_01C32115.1108E010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] UPDATE and P-Asserted-ID

Jonathan's approach seems reasonable, and since = P-Asserted-Id just represents the identity of the originator of the = *message* we could expect it to change during a dialog - I suppose = there is a philosphical question that if the identity of the SIP UAS = changes, does that mean it is now a logically different UAS and so a = new dialog should be established ? even if it's the same physical = device so that all the state needed to maintain a single dialog is = still available ?? I guess this is the case when call forward/transfer = happens downstream of a SIP->X gateway.

Equally, were a device to de-register and re-register = with a new Address Of Record, does this represent an 'identity change' = for that UA ? Could it meaningfully update its identity in any ongoing = dialogs ?

I think there should be scope for individual headers = to specify that their state cannot be updated mid-dialog. Not having = looked through all the 'such headers' referred to by Jonathan (not even = knowing what this list is!) we can't rule out that the meaning of a = mid-dialog update for one of these might not be well-defined i.e. it = has no sensible meaning or is ambiguous. In those cases we would need = to rule out mid-dialog updates, or define the meaning of them for that = header.

...Mark



> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: 19 May 2003 21:18
> To: Jonathan Rosenberg
> Cc: Elwell, John; 'Rohan Mahy'; 'Drage, Keith = (Keith)'; 'sip@ietf.org'
> Subject: Re: [Sip] UPDATE and = P-Asserted-ID
>
>
> Jonathan Rosenberg writes:
>  > 1. Each header field that conveys = dialog-associated state would
>  > indicate whether or not that state = is updated by a target
> refresh request.
>  >
>  > 2. We specify a blanket rule for all = such headers that
> their state is
>  > updated by a target refresh request = (absence of a header
> would imply
>  > no update).
>  >
>  > 3. We specify a blanket rule for all = such headers that
> their state is
>  > never updated by a target refresh = request.
>  >
>  > 4. We specify a default rule for all = such headers, but allow
>  > individual headers to override = it.
>  >
>  >
>  > In the interests of simplicity I = would tend to lean
> towards (2). The
>  > best place for this, of course, is = rfc 3261, in which case
> we should
>  > treat this as a bug against the = spec.
>
> This seems quite reasonable to me as well = --
> special casing "initial" from = subsequent dialog
> seems pretty fraught. The only reason that I = can
> think of why you might want to do that is when = the
> state assembly/teardown of a mid-session = change
> was so onerous and/or ambiguous to other = state
> that it was prudent to set up the state once = and
> leave it be. It doesn't seem to me that that's = the
> case here, but I'm hardly an expert.
>
>        = 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
>

------_=_NextPart_001_01C32115.1108E010-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 26 04:24:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05758 for ; Mon, 26 May 2003 04:24:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4Q8OPq18914 for sip-archive@odin.ietf.org; Mon, 26 May 2003 04:24:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4Q8NcB18846; Mon, 26 May 2003 04:23:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4Q8HTB18655 for ; Mon, 26 May 2003 04:17:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05674 for ; Mon, 26 May 2003 04:17:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KD8l-0004XA-00 for sip@ietf.org; Mon, 26 May 2003 04:15:31 -0400 Received: from em.njupt.edu.cn ([202.119.230.11]) by ietf-mx with smtp (Exim 4.12) id 19KD8k-0004X7-00 for sip@ietf.org; Mon, 26 May 2003 04:15:30 -0400 Received: (qmail 15686 invoked by uid 1008); 26 May 2003 09:07:08 -0000 Message-ID: <20030526090708.15685.qmail@em.njupt.edu.cn> From: Y01317@njupt.edu.cn To: sip@ietf.org Date: Mon, 26 May 2003 09:07:08 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Notifier Privacy Mechanism puzzle Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I have a question about section 5.2 Notifier Privacy Mechanism in RFC3265 The mere act of returning a 200 or certain 4xx and 6xx responses to SUBSCRIBE requests may, under certain circumstances, create privacy concerns by revealing sensitive policy information. I do not unstand why it says a 4xx or 6xx response can reveal sensitive policy information, for example, the notifier send a 403 Forbidden or 401 Unauthorization , can this cause policy problem? I think no. If it can , anybody give me some explanations? Thanks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 26 09:03:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10690 for ; Mon, 26 May 2003 09:03:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4QD2Zq04525 for sip-archive@odin.ietf.org; Mon, 26 May 2003 09:02:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QD1dB04500; Mon, 26 May 2003 09:01:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QCxUB04365 for ; Mon, 26 May 2003 08:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10613 for ; Mon, 26 May 2003 08:59:27 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KHY3-0005yN-00 for sip@ietf.org; Mon, 26 May 2003 08:57:55 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19KHY2-0005yJ-00 for sip@ietf.org; Mon, 26 May 2003 08:57:54 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4QCxOL08628 for ; Mon, 26 May 2003 15:59:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 May 2003 15:59:24 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 15:59:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: RE: [Sip] Notifier Privacy Mechanism puzzle Date: Mon, 26 May 2003 15:59:20 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7653@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Notifier Privacy Mechanism puzzle Thread-Index: AcMjYLOQP81aXazPQHyloWdkfmE7uQAGHmWQ To: , X-OriginalArrivalTime: 26 May 2003 12:59:24.0637 (UTC) FILETIME=[A1F650D0:01C32386] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4QCxUB04366 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit You might not want watchers to know that you have rejected their subscription to your presence info. Sending a 4xx - 6xx to the subscription will reveal such information. Sending a 2xx followed by a NOTIFY with bogus info may not reveal that sensitive policy information. /Hisham > -----Original Message----- > From: ext Y01317@njupt.edu.cn [mailto:Y01317@njupt.edu.cn] > Sent: Monday, May 26, 2003 12:07 PM > To: sip@ietf.org > Subject: [Sip] Notifier Privacy Mechanism puzzle > > > Hi all, > > I have a question about section 5.2 Notifier Privacy > Mechanism in RFC3265 > > > > The mere act of returning a 200 or certain 4xx and 6xx responses to > SUBSCRIBE requests may, under certain circumstances, create privacy > concerns by revealing sensitive policy information. > > > > I do not unstand why it says a 4xx or 6xx response can > reveal sensitive > policy information, for example, the notifier send a 403 > Forbidden or 401 > Unauthorization , can this cause policy problem? I think no. > If it can , > anybody give me some explanations? > > Thanks. > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon May 26 22:49:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12002 for ; Mon, 26 May 2003 22:49:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4R2nUn26171 for sip-archive@odin.ietf.org; Mon, 26 May 2003 22:49:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R2mhB26144; Mon, 26 May 2003 22:48:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R2jAB26052 for ; Mon, 26 May 2003 22:45:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11923 for ; Mon, 26 May 2003 22:44:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KUQn-0006Rw-00 for sip@ietf.org; Mon, 26 May 2003 22:43:17 -0400 Received: from web20508.mail.yahoo.com ([216.136.226.143]) by ietf-mx with smtp (Exim 4.12) id 19KUQm-0006Rs-00 for sip@ietf.org; Mon, 26 May 2003 22:43:16 -0400 Message-ID: <20030527024449.29715.qmail@web20508.mail.yahoo.com> Received: from [210.126.196.181] by web20508.mail.yahoo.com via HTTP; Tue, 27 May 2003 03:44:49 BST Date: Tue, 27 May 2003 03:44:49 +0100 (BST) From: =?iso-8859-1?q?suresh=20t?= To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] problem with NAT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi all.. i got one doubt reg. NAT traversal of the SIP messages...pls clarify me ASAP... suppose if the user1 is using local Ip address and registers with the proxy with Ip address and port(the proxy registers the NATed IP and port(dynamic)). and suppose it is a chat like application, the user2 wants to connect user1 through some private protocol, which is using TCP, but after a long time... in this case, the translation table(NAT) in the Router of user1 is timed out and has been purged. then the user2 cannot access the user1's system. how can i solve the above problem..? ur suggestion is highly appreciated. thanks in advance suresh __________________________________________________ It's Samaritans' Week. Help Samaritans help others. Call 08709 000032 to give or donate online now at http://www.samaritans.org/support/donations.shtm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 00:47:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14627 for ; Tue, 27 May 2003 00:47:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4R4l3e00680 for sip-archive@odin.ietf.org; Tue, 27 May 2003 00:47:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R4kVB00639; Tue, 27 May 2003 00:46:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R4iJB00501 for ; Tue, 27 May 2003 00:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14445 for ; Tue, 27 May 2003 00:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KWI3-00077W-00 for sip@ietf.org; Tue, 27 May 2003 00:42:23 -0400 Received: from f32.sea2.hotmail.com ([207.68.165.32] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19KWI3-00077S-00 for sip@ietf.org; Tue, 27 May 2003 00:42:23 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 26 May 2003 21:43:26 -0700 Received: from 202.142.93.200 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 27 May 2003 04:43:25 GMT X-Originating-IP: [202.142.93.200] X-Originating-Email: [sujith_km@hotmail.com] From: "Sujith Kumar" To: sip@ietf.org Subject: Re: [Sip] problem with NAT Date: Tue, 27 May 2003 10:13:25 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 May 2003 04:43:26.0129 (UTC) FILETIME=[82EC1A10:01C3240A] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Suresh, The sip registration should have a time out and after the time out, the sip client needs to register again. The SIP register timeout should be less than (or equal) the Transition table entry time out. I hope, this will solve your problem,. Regds, Sujith >From: suresh t >To: sip@ietf.org >Subject: [Sip] problem with NAT >Date: Tue, 27 May 2003 03:44:49 +0100 (BST) > >hi all.. > >i got one doubt reg. NAT traversal of the SIP >messages...pls clarify me ASAP... > >suppose if the user1 is using local Ip address and >registers with the proxy with Ip address and port(the >proxy registers the NATed IP and port(dynamic)). > >and suppose it is a chat like application, the user2 >wants to connect user1 through some private protocol, >which is using TCP, but after a long time... > >in this case, the translation table(NAT) in the Router > >of user1 is timed out and has been purged. then the >user2 cannot access the user1's system. > >how can i solve the above problem..? > >ur suggestion is highly appreciated. > >thanks in advance >suresh > > > >__________________________________________________ >It's Samaritans' Week. Help Samaritans help others. >Call 08709 000032 to give or donate online now at >http://www.samaritans.org/support/donations.shtm >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Want free fuel? Get IOC Citibank card. http://server1.msn.co.in/msnleads/citibankcards/ioc.asp Drive your dreams! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 01:35:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15553 for ; Tue, 27 May 2003 01:35:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4R5Z0J03572 for sip-archive@odin.ietf.org; Tue, 27 May 2003 01:35:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R5YcB03553; Tue, 27 May 2003 01:34:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R5XOB03516 for ; Tue, 27 May 2003 01:33:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15529 for ; Tue, 27 May 2003 01:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KX3Y-0007RT-00 for sip@ietf.org; Tue, 27 May 2003 01:31:28 -0400 Received: from h68-147-4-22.cg.shawcable.net ([68.147.4.22] helo=wilde.ryker.org) by ietf-mx with esmtp (Exim 4.12) id 19KX3X-0007RP-00 for sip@ietf.org; Tue, 27 May 2003 01:31:28 -0400 Received: from wilde.ryker.org (localhost.ryker.org [127.0.0.1]) by wilde.ryker.org (8.12.9/8.12.4) with ESMTP id h4R5WTL0002031; Mon, 26 May 2003 23:32:29 -0600 Received: (from ryker@localhost) by wilde.ryker.org (8.12.9/8.12.9/Submit) id h4R5WSHS002030; Mon, 26 May 2003 23:32:28 -0600 X-Authentication-Warning: wilde.ryker.org: ryker set sender to ryker@ryker.org using -f Date: Mon, 26 May 2003 23:32:28 -0600 From: Ryan Kereliuk To: Sujith Kumar Cc: sip@ietf.org Subject: Re: [Sip] problem with NAT Message-ID: <20030527053228.GA1852@ryker.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , On Tue, May 27, 2003 at 10:13:25AM +0530, Sujith Kumar wrote: > > The sip registration should have a time out and after the time > out, the sip client needs to register again. The SIP register timeout > should be less than (or equal) the Transition table entry time out. > I hope, this will solve your problem,. Your comment is generally correct assuming a UA that uses UDP and supports both symmetric signalling and very short REGISTER expiry times (and once you add media into the picture it gets more complex). Interop experience shows that quite a few UAs don't support one or the other. The original poster asked about TCP, however. Unlike UDP, the NAT/PAT bindings for TCP can be (and often are) torn down when the TCP state machine reaches a final state. Unless you're using persistent and reusable connections you're going to run into trouble. Let me point out the ICE draft, draft-rosenberg-sipping-ice-00.html, which AFAIK is the latest attempt to reconcile SIP with the realities of NAT/PAT. I'm not sure what kind of traction it's getting but I think it will be quite a while before something like this is part of common SIP implementations. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 03:24:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01149 for ; Tue, 27 May 2003 03:24:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4R7O4324265 for sip-archive@odin.ietf.org; Tue, 27 May 2003 03:24:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R7NUB24231; Tue, 27 May 2003 03:23:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LFHLB29825 for ; Wed, 21 May 2003 11:17:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25747; Wed, 21 May 2003 11:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IVpW-0007nO-00; Wed, 21 May 2003 11:48:38 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19IVpW-0007n2-00; Wed, 21 May 2003 11:48:38 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HF800FDSULB3O@firewall.wcom.com>; Wed, 21 May 2003 15:48:48 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HF800B01UIF7L@pmismtp01.wcomnet.com>; Wed, 21 May 2003 15:48:47 +0000 (GMT) Received: from hsinnreich2 ([166.50.123.48]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HF800B10UK2D1@pmismtp01.wcomnet.com>; Wed, 21 May 2003 15:48:05 +0000 (GMT) Date: Wed, 21 May 2003 10:48:02 -0500 From: Henry Sinnreich In-reply-to: <28B9108644E492469B911D587AABC97C023DEB80@PKDWB01C.ad.sprint.com> To: "'Santharam, Arun [NTWK SVCS]'" , "'Rajarshi Chakraborty'" , drage@lucent.com, ashishn@mahindrabt.com, sip@ietf.org Cc: sipping@ietf.org Message-id: <001001c31fb0$5e437450$307b32a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] RE: [Sipping] RE: SIP mobility in WLAN Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > If we follow the SIP implementation on Mobile IP then the SIP > stack should not have to bother about the mobility aspect. The other alternative is to have application layer mobility for SIP as published in several papers at Columbia University and Telcordia. I don't believe you need mobile IP for all scenarios or that is the best option under all circumstances. The last word on this may not be over yet. Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Santharam, Arun [NTWK SVCS] > Sent: Monday, May 19, 2003 1:35 PM > To: Rajarshi Chakraborty; drage@lucent.com; > ashishn@mahindrabt.com; sip@ietf.org > Cc: sipping@ietf.org > Subject: [Sipping] RE: SIP mobility in WLAN > > > > If we follow the SIP implementation on Mobile IP then the SIP > stack should not have to bother about the mobility aspect. > The SIP stack should be notified of IP changes/handoff > information (if relevant for the SIP stack) by the underlying > stack. This may prompt a SIP registration and subsequent call flows. > > My 2 cents ... > arun > > > > -----Original Message----- > > From: Rajarshi Chakraborty [mailto:rajarshi_chakraborty@hotmail.com] > > Sent: Sunday, May 18, 2003 11:42 PM > > To: drage@lucent.com; ashishn@mahindrabt.com; Santharam, Arun > > [NTWK SVCS]; sip@ietf.org > > Cc: sipping@ietf.org > > Subject: SIP mobility in WLAN > > > > > > Hi, > > > > Where can I get call-flows for SIP session management in a > > wireless LAN > > (802.11)? 3GPP only addresses the issues for cellular > > networks. Or are they > > too trivial to be addressed specially? I am specially interested in > > situations of handoffs (in this case, the IP changes as soon > > as the host > > shifts from the zone around one hotspot to another). Should > > SIP bother at > > all to detect IP changes or should the control be completely > > outside SIP? I > > mean should it be some other module that has the > > responsibility of informing > > the SIP stack in the mobile host about the IP changes, so > > that the host may > > then send a re-INVITE with a new SDP but the call still > > remains active? > > > > regards > > Rajarshi > > > > > > Rajarshi Chakraborty > > B-196, IIT Campus, > > Kharagpur, > > West Bengal, India > > PIN-721302 > > > > > > > > > > > > ----Original Message Follows---- > > From: "Drage, Keith (Keith)" > > To: "'Ashish Naik'" , "Santharam, > > Arun [CC]" > > , "Sip@Ietf. Org" > > Subject: RE: [Sip] Session Mobility in SIP > > Date: Thu, 8 May 2003 14:42:24 +0100 > > > > Your best starting point to see the architecture is 3GPP TS > > 23.228, with > > reference to 3GPP TS 23.002 to see how these entities fit > > together into the > > entire 3GPP architecture. > > > > The SIP protocol application is covered in 3GPP TS 24.229 > > with example flows > > in 3GPP TS 24.228. > > > > These documents may be found at: > > > > ftp://ftp.3gpp.org/Specs/latest/Rel-5/ > > > > > > 3GPP uses these specifications over GPRS to provide mobility. > > > > There is a parallel set of 3GPP2 specifications, > > substantially of common > > text, that uses the same architecture over mobile IP, instead > > of GPRS. These > > documents are currently in 3GPP2 comment and review. > > > > regards > > > > Keith > > > > > > > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > -----Original Message----- > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > Sent: 08 May 2003 06:23 > > To: Santharam, Arun [CC]; Sip@Ietf. Org > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > ok. Is there any specific document on IETF and 3GPP that can > > explain how it > > is being addressed ? > > > > > > Ragards, > > Ashish Naik > > CoE Mobile Computing > > ----------------------------------- > > Phone 4018100 Ext 3070 > > > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > > Of Santharam, > > Arun [CC] > > Sent: Wednesday, April 09, 2003 9:42 PM > > To: Ashish Naik; Sip@Ietf. Org > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > Ashish, > > > > > > > > Please find comments inline. > > > > > > > > Thank you > > > > arun > > > > > > > > -----Original Message----- > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > Sent: Wednesday, April 09, 2003 4:01 AM > > To: Sip@Ietf. Org > > Subject: [Sip] Session Mobility in SIP > > > > > > > > How is SIP going to address session mobility ? Is there any > > initiative taken > > up for this ? > > > > > > > > > This has been addressed in 3GPP standards. Please refer to > > the 3GPP All > > IP architecture specifications. > > > > > > > > SIP is said to be a better alternative than Mobile IP. Can I > > have some > > latest development document references ? > > > > > > > > > > > > > SIP is not going to replace Mobile IP. It is going to > > leverage Mobile IP > > for session management in 3G wireless networks. > > > > > > > > > > > > Regards, > > Ashish Naik > > ------------------- > > CoE Mobile Computing > > Phone: 4018100 Ext 3070 > > > > > > > > > > ********************************************************* > > Disclaimer > > > > This message (including any attachments) contains confidential > > information intended for a specific individual and purpose, and is > > protected by law. If you are not the intended recipient, you should > > delete this message and are hereby notified that > > any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, > > is strictly prohibited. > > > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > > > > > > > ********************************************************* > > Disclaimer > > > > This message (including any attachments) contains confidential > > information intended for a specific individual and purpose, and is > > protected by law. If you are not the intended recipient, you should > > delete this message and are hereby notified that > > any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, > > is strictly prohibited. > > > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > _________________________________________________________________ > > Mobile, masti, magic! Cool ringtones & logos. > > http://www.msn.co.in/mobile/ > > Get noticed > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 03:24:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01170 for ; Tue, 27 May 2003 03:24:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4R7OMT24312 for sip-archive@odin.ietf.org; Tue, 27 May 2003 03:24:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R7O5B24284; Tue, 27 May 2003 03:24:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4N4QXB03579 for ; Fri, 23 May 2003 00:26:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11954 for ; Fri, 23 May 2003 00:58:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19J4c3-00014v-00 for sip@ietf.org; Fri, 23 May 2003 00:57:03 -0400 Received: from bosvwl02.infy.com ([216.52.49.36] helo=bosvwl02.infosys.com) by ietf-mx with smtp (Exim 4.12) id 19J4c2-00014Z-00 for sip@ietf.org; Fri, 23 May 2003 00:57:02 -0400 Received: from 192.168.200.83 by bosvwl02.infosys.com (InterScan E-Mail VirusWall NT); Fri, 23 May 2003 00:59:38 -0400 Received: from mohmsg01.ad.infosys.com ([192.168.122.42]) by INDHUBBHS03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 May 2003 10:27:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 23 May 2003 10:27:54 +0530 Message-ID: <2B721C6525F0D411B1E900B0D0226BDD025173A2@mohmsg01.ad.infosys.com> Thread-Topic: How SIP sessions are maintained in Push to talk? Thread-Index: AcMgXC9e49zCJ7k0TdaOt8GsKChgoQAAJ2ZgACLDAbA= From: "Deepti Nayak" To: X-OriginalArrivalTime: 23 May 2003 04:57:55.0133 (UTC) FILETIME=[DF3C96D0:01C320E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4N4QXB03580 Subject: [Sip] FW: How SIP sessions are maintained in Push to talk? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Hi, > > In push to talk services: Based on who is available, the user can simply push a button and start a Push-To-Talk dialog in a walkie-talkie or chat room-like mode. > Whenever a user presses a button, he can start speaking instantly. Terminator need not answer this call. > > If we assume that sessions are maintained in PTT through SIP, then whenever a user presses a button, an invite message is sent to the terminator. Then without getting an 200OK message how can a session be established between the two parties? > > Regards, > Deepti > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 07:04:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07676 for ; Tue, 27 May 2003 07:04:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RB4k207634 for sip-archive@odin.ietf.org; Tue, 27 May 2003 07:04:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RB3vB07604; Tue, 27 May 2003 07:03:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RB0KB07469 for ; Tue, 27 May 2003 07:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07550; Tue, 27 May 2003 06:59:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kc9p-00036Y-00; Tue, 27 May 2003 06:58:17 -0400 Received: from uni03du.unity.ncsu.edu ([152.1.13.103]) by ietf-mx with esmtp (Exim 4.12) id 19Kc9o-00036V-00; Tue, 27 May 2003 06:58:17 -0400 Received: (from prsinha@localhost) by uni03du.unity.ncsu.edu (8.8.4/EC02Jan97) id GAA01101; Tue, 27 May 2003 06:59:49 -0400 (EDT) Date: Tue, 27 May 2003 06:59:49 -0400 (EDT) From: Prabhas Ranjan Sinha To: Henry Sinnreich cc: "'Santharam, Arun [NTWK SVCS]'" , "'Rajarshi Chakraborty'" , drage@lucent.com, ashishn@mahindrabt.com, sip@ietf.org, sipping@ietf.org Subject: Re: [Sip] RE: [Sipping] RE: SIP mobility in WLAN In-Reply-To: <001001c31fb0$5e437450$307b32a6@hsinnreich2> Message-ID: References: <001001c31fb0$5e437450$307b32a6@hsinnreich2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > > The other alternative is to have application layer mobility for SIP as > published in several papers at Columbia University and Telcordia. I > don't believe you need mobile IP for all scenarios or that is the best > option under all circumstances. > > The last word on this may not be over yet. > > Henry Henry, Could you please elaborate on it more w.r.t pros and cons or refer me to to any publication which can talk about it ? I have read that people forsee that Mobile IP could be the most suitable mechanism for mobility across multiple subnets of WLAN network. Prabhas > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Santharam, Arun [NTWK SVCS] > > Sent: Monday, May 19, 2003 1:35 PM > > To: Rajarshi Chakraborty; drage@lucent.com; > > ashishn@mahindrabt.com; sip@ietf.org > > Cc: sipping@ietf.org > > Subject: [Sipping] RE: SIP mobility in WLAN > > > > > > > > If we follow the SIP implementation on Mobile IP then the SIP > > stack should not have to bother about the mobility aspect. > > The SIP stack should be notified of IP changes/handoff > > information (if relevant for the SIP stack) by the underlying > > stack. This may prompt a SIP registration and subsequent call flows. > > > > My 2 cents ... > > arun > > > > > > > -----Original Message----- > > > From: Rajarshi Chakraborty [mailto:rajarshi_chakraborty@hotmail.com] > > > Sent: Sunday, May 18, 2003 11:42 PM > > > To: drage@lucent.com; ashishn@mahindrabt.com; Santharam, Arun > > > [NTWK SVCS]; sip@ietf.org > > > Cc: sipping@ietf.org > > > Subject: SIP mobility in WLAN > > > > > > > > > Hi, > > > > > > Where can I get call-flows for SIP session management in a > > > wireless LAN > > > (802.11)? 3GPP only addresses the issues for cellular > > > networks. Or are they > > > too trivial to be addressed specially? I am specially interested in > > > situations of handoffs (in this case, the IP changes as soon > > > as the host > > > shifts from the zone around one hotspot to another). Should > > > SIP bother at > > > all to detect IP changes or should the control be completely > > > outside SIP? I > > > mean should it be some other module that has the > > > responsibility of informing > > > the SIP stack in the mobile host about the IP changes, so > > > that the host may > > > then send a re-INVITE with a new SDP but the call still > > > remains active? > > > > > > regards > > > Rajarshi > > > > > > > > > Rajarshi Chakraborty > > > B-196, IIT Campus, > > > Kharagpur, > > > West Bengal, India > > > PIN-721302 > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > From: "Drage, Keith (Keith)" > > > To: "'Ashish Naik'" , "Santharam, > > > Arun [CC]" > > > , "Sip@Ietf. Org" > > > Subject: RE: [Sip] Session Mobility in SIP > > > Date: Thu, 8 May 2003 14:42:24 +0100 > > > > > > Your best starting point to see the architecture is 3GPP TS > > > 23.228, with > > > reference to 3GPP TS 23.002 to see how these entities fit > > > together into the > > > entire 3GPP architecture. > > > > > > The SIP protocol application is covered in 3GPP TS 24.229 > > > with example flows > > > in 3GPP TS 24.228. > > > > > > These documents may be found at: > > > > > > ftp://ftp.3gpp.org/Specs/latest/Rel-5/ > > > > > > > > > 3GPP uses these specifications over GPRS to provide mobility. > > > > > > There is a parallel set of 3GPP2 specifications, > > > substantially of common > > > text, that uses the same architecture over mobile IP, instead > > > of GPRS. These > > > documents are currently in 3GPP2 comment and review. > > > > > > regards > > > > > > Keith > > > > > > > > > > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > -----Original Message----- > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > Sent: 08 May 2003 06:23 > > > To: Santharam, Arun [CC]; Sip@Ietf. Org > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > ok. Is there any specific document on IETF and 3GPP that can > > > explain how it > > > is being addressed ? > > > > > > > > > Ragards, > > > Ashish Naik > > > CoE Mobile Computing > > > ----------------------------------- > > > Phone 4018100 Ext 3070 > > > > > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > > > Of Santharam, > > > Arun [CC] > > > Sent: Wednesday, April 09, 2003 9:42 PM > > > To: Ashish Naik; Sip@Ietf. Org > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > > > > Ashish, > > > > > > > > > > > > Please find comments inline. > > > > > > > > > > > > Thank you > > > > > > arun > > > > > > > > > > > > -----Original Message----- > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > Sent: Wednesday, April 09, 2003 4:01 AM > > > To: Sip@Ietf. Org > > > Subject: [Sip] Session Mobility in SIP > > > > > > > > > > > > How is SIP going to address session mobility ? Is there any > > > initiative taken > > > up for this ? > > > > > > > > > > > > > This has been addressed in 3GPP standards. Please refer to > > > the 3GPP All > > > IP architecture specifications. > > > > > > > > > > > > SIP is said to be a better alternative than Mobile IP. Can I > > > have some > > > latest development document references ? > > > > > > > > > > > > > > > > > > > SIP is not going to replace Mobile IP. It is going to > > > leverage Mobile IP > > > for session management in 3G wireless networks. > > > > > > > > > > > > > > > > > > Regards, > > > Ashish Naik > > > ------------------- > > > CoE Mobile Computing > > > Phone: 4018100 Ext 3070 > > > > > > > > > > > > > > > ********************************************************* > > > Disclaimer > > > > > > This message (including any attachments) contains confidential > > > information intended for a specific individual and purpose, and is > > > protected by law. If you are not the intended recipient, you should > > > delete this message and are hereby notified that > > > any disclosure, copying, or distribution of this > > > message, or the taking of any action based on it, > > > is strictly prohibited. > > > > > > ********************************************************* > > > Visit us at http://www.mahindrabt.com > > > > > > > > > > > > > > > ********************************************************* > > > Disclaimer > > > > > > This message (including any attachments) contains confidential > > > information intended for a specific individual and purpose, and is > > > protected by law. If you are not the intended recipient, you should > > > delete this message and are hereby notified that > > > any disclosure, copying, or distribution of this > > > message, or the taking of any action based on it, > > > is strictly prohibited. > > > > > > ********************************************************* > > > Visit us at http://www.mahindrabt.com > > > > > > _________________________________________________________________ > > > Mobile, masti, magic! Cool ringtones & logos. > > > http://www.msn.co.in/mobile/ > > > Get noticed > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Prabhas +++++++++++++ CSEL Technology Enterprise Programme London Business School Baker Street, London NW1 6DD ***************************************** There is no wisdom greater than kindness. ***************************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 10:47:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14809 for ; Tue, 27 May 2003 10:47:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4REl0g25416 for sip-archive@odin.ietf.org; Tue, 27 May 2003 10:47:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4REk8B25383; Tue, 27 May 2003 10:46:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4REh5B25282 for ; Tue, 27 May 2003 10:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14661 for ; Tue, 27 May 2003 10:43:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kfdo-0004pe-00 for sip@ietf.org; Tue, 27 May 2003 10:41:28 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Kfdn-0004pV-00 for sip@ietf.org; Tue, 27 May 2003 10:41:27 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4REgnT3016139; Tue, 27 May 2003 16:42:49 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 May 2003 16:43:19 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'Jonathan Rosenberg'" Cc: Sanjay Sinha , sip@ietf.org Subject: RE: [Sip] Question on RFC 3263 Date: Tue, 27 May 2003 16:39:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, >Actually, before that even happens the client transaction will simply >terminate at the UAC. See: > >http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-00.txt > >but in any case, the UAS shouldnt terminate the call just because the >18x never got a PRACK. What if the UAS includes an SDP in the reliable 18x? Shall it assume that the UAC will terminate the call if it doesn't receive an SDP when it expect to do so? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 12:13:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18602 for ; Tue, 27 May 2003 12:13:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RGDDc32574 for sip-archive@odin.ietf.org; Tue, 27 May 2003 12:13:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RGCNB32515; Tue, 27 May 2003 12:12:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RG9QB32376 for ; Tue, 27 May 2003 12:09:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18267 for ; Tue, 27 May 2003 12:09:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgzO-0005ns-00 for sip@ietf.org; Tue, 27 May 2003 12:07:50 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19KgzN-0005mx-00 for sip@ietf.org; Tue, 27 May 2003 12:07:49 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4RG8p6n030108 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 27 May 2003 11:08:52 -0500 From: "Dean Willis" To: "'Prabhas Ranjan Sinha'" , Subject: RE: [Sip] WLAN & SIP Date: Tue, 27 May 2003 11:08:36 -0500 Message-ID: <001a01c3246a$3af90f00$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RG9QB32377 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Prabhas asked: > > Is there any draft on SIP usage in WLAN arena ? > Any help would be appreciated. > I suppose "Just use it -- we don't really care whether the IP traffic is over WLAN, ethernet, frame relay, barbed wired, or avian carrier" isn't the answer you're looking for. But really, the IETF (outside of task specific areas like the Performance Implications of Link Characteistics working group) isn't generally concerned with specific lower-layer aspects. The short answer is that SIP works just fine over 802.11b (I'm using it that way right now) and should work over "a" and "g" just fine too. 3GPP (www.3gpp.org) is doing some work on extending IMS Release 6 (Internet Multimedia Subsystem) which uses SIP onto WLAN. However, I'm not yet completely certain that what they mean by WLAN and what you mean by WLAN are the same thing -- they seem to be mostly worred about the sort of WLAN that would be installed by mobile operators in hotspots and tied to one's mobile phone account. Consequently, they're interested in things like using the mobile's SIM card for authentication over WLAN, differential access pricing by service, Q0S interworking with UMTS, and all of the usual 3G-mobile-phone type things. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 13:35:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20913 for ; Tue, 27 May 2003 13:35:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RHYdd05326 for sip-archive@odin.ietf.org; Tue, 27 May 2003 13:34:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHUnB05037; Tue, 27 May 2003 13:30:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHS4B04923 for ; Tue, 27 May 2003 13:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20390 for ; Tue, 27 May 2003 13:27:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KiDR-0006Kz-00 for sip@ietf.org; Tue, 27 May 2003 13:26:26 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=f1ee40-19.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19KiDR-0006Kd-00 for sip@ietf.org; Tue, 27 May 2003 13:26:25 -0400 Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id RAA21983 for ; Tue, 27 May 2003 17:27:29 GMT Received: from idc1exc0002.corp.global.level3.com ([10.1.8.18]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 27 May 2003 11:27:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 27 May 2003 11:27:28 -0600 Message-ID: <11FD90E74279C0489ECB6793F227C847E86159@idc1exc0002.corp.global.level3.com> Thread-Topic: a question on section 18.2.2 in RFC 3261 Thread-Index: AcMkdT8nW9n8Rno5QTSsh0t4fXQ44w== From: "Wang, Jin-Gen" To: X-OriginalArrivalTime: 27 May 2003 17:27:28.0832 (UTC) FILETIME=[3F4D7400:01C32475] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RHS4B04924 Subject: [Sip] a question on section 18.2.2 in RFC 3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Section 18.2.2 specifies: "18.2.2 Sending Responses The server transport uses the value of the top Via header field in order to determine where to send a response. It MUST follow the following process: o If the "sent-protocol" is a reliable transport protocol such as TCP or SCTP, or TLS over those, the response MUST be sent using the existing connection to the source of the original request that created the transaction, if that connection is still open. This requires the server transport to maintain an association between server transactions and transport connections. If that connection is no longer open, the server SHOULD open a connection to the IP address in the "received" parameter, if present, using the port in the "sent-by" value, or the default port for that transport, if no port is specified. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. " Since the Via header has enough information (IP address + port + transport protocol) for an application to send back response messages, what is the design idea behind the above decision to request an application to send back responses using an existing connection if the connection is still open, other than (may be) optimization in implementation? In other words, from SIP protocol point of view, why is such request a MUST requirement? Thanks. Jin-Gen Wang Level 3 Communications, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue May 27 14:03:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22086 for ; Tue, 27 May 2003 14:03:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RI38x07517 for sip-archive@odin.ietf.org; Tue, 27 May 2003 14:03:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RI22B07474; Tue, 27 May 2003 14:02:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RI0nB07382 for ; Tue, 27 May 2003 14:00:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22006 for ; Tue, 27 May 2003 14:00:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kij8-0006lY-00 for sip@ietf.org; Tue, 27 May 2003 13:59:10 -0400 Received: from monolith.ryker.org ([216.194.67.78]) by ietf-mx with esmtp (Exim 4.12) id 19Kij7-0006lV-00 for sip@ietf.org; Tue, 27 May 2003 13:59:09 -0400 Received: from monolith.ryker.org (localhost [127.0.0.1]) by monolith.ryker.org (8.12.9+Sun/8.12.2) with ESMTP id h4RI0htr026383; Tue, 27 May 2003 12:00:43 -0600 (MDT) Received: (from ryker@localhost) by monolith.ryker.org (8.12.9+Sun/8.12.2/Submit) id h4RI0hNi026382; Tue, 27 May 2003 12:00:43 -0600 (MDT) X-Authentication-Warning: monolith.ryker.org: ryker set sender to ryker@ryker.org using -f Date: Tue, 27 May 2003 12:00:43 -0600 From: Ryan Kereliuk To: "Wang, Jin-Gen" Cc: sip@ietf.org Subject: Re: [Sip] a question on section 18.2.2 in RFC 3261 Message-ID: <20030527180043.GA26339@ryker.org> References: <11FD90E74279C0489ECB6793F227C847E86159@idc1exc0002.corp.global.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11FD90E74279C0489ECB6793F227C847E86159@idc1exc0002.corp.global.level3.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , On Tue, May 27, 2003 at 11:27:28AM -0600, Wang, Jin-Gen wrote: > > Since the Via header has enough information (IP address + port + > transport protocol) for an application to send back response messages, > what is the design idea behind the above decision to request an > application to send back responses using an existing connection if the > connection is still open, other than (may be) optimization in > implementation? In other words, from SIP protocol point of view, why is > such request a MUST requirement? There are a variety of reasons why this is good including traversal of of NAT/PAT devices. I think the motivation for the text as written, however, was to head off potential scaling and performance problems associated with doubling the number of TCP/SCTP/TLS connections in use. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 30 10:46:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11090 for ; Fri, 30 May 2003 10:46:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEjf909104 for sip-archive@odin.ietf.org; Fri, 30 May 2003 10:45:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEh8B08996; Fri, 30 May 2003 10:43:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEbtB08678 for ; Fri, 30 May 2003 10:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10723; Fri, 30 May 2003 10:37:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkzI-0005EH-00; Fri, 30 May 2003 10:36:08 -0400 Received: from terra.polito.it ([130.192.3.81] helo=polito.it) by ietf-mx with esmtp (Exim 4.12) id 19LkzH-0005EE-00; Fri, 30 May 2003 10:36:08 -0400 Received: from [130.192.1.21] (HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1b2) with ESMTP-TLS id 7855459; Fri, 30 May 2003 16:30:55 +0200 Message-ID: <3ED75A29.8070500@polito.it> Date: Fri, 30 May 2003 15:18:33 +0200 From: Corrado Derenale Reply-To: derenale@polito.it User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vesa.torvinen@ericsson.fi CC: jari.arkko@ericson.fi, aki.niemi@nokia.com, sipping@ietf.org, sip@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020104090105060907060505" Subject: [Sip] SIP and EAP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms020104090105060907060505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, I saw the Torval proposal for authenticate SIP messages with EAP. The IETF document draft-torvinen-http-eap-02.txt Was that proposal been inserted in a new draft or RFC? We are working to find an extensible authentication schema for SIP and are we now evaluating that old proposal. Thank you in advance, Corrado Derenale. --------------ms020104090105060907060505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV4zCC BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV 6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6 Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ 506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW 1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm 053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+ Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci 6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE +ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0 cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3 LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0 ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6 RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U 79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn CaPNvqphRz5KhJGOTJpc8CZ+UDCCBgkwggTxoAMCAQICAgEZMA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMjEw MzEwNzAwMDBaFw0wMzEyMzEwOTAwMDBaMHwxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh IGUgSW5mb3JtYXRpY2ExGjAYBgNVBAMTEUNvcnJhZG8gIERlcmVuYWxlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo9UqtuwtaPmMSHeee4DPi2fiRCbSUCG32jlAYeAqoXvx 3rBwfDWHoZvvSn73sYlHptbHdQpp/M0N1RkCSDQGMxSvzoXhy3GYrM63Oy/Tjpfe8R05gnVn 6Q4x9CGNr5Zm5RZWOp12KY2jCb9Q4+krFESFSgB6PUBr/WJnCM4NotvhrYBsdjl1Jaww0A9Y Dyc70Igw9ZqEJ1n5iK3EA8kcv3HyA+NkANXZbz0nCuPkcCw/ixvbGmne09TFTDxwZeXAZtS5 FthofBMk6XOfKE5kgv+6qSUGOh9/myZ3xIS0smbI3BlFqlCawfRrK6YbNjGJRDY7t9hqcrFf Vw1GcwiPowIDAQABo4ICqjCCAqYwgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0 cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA1BgNVHREELjAsgRJkZXJlbmFs ZUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYwMDQzMTcwgc0GA1UdIASBxTCBwjBDBgor BgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9v dC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsGAQUFBwIBFhxo dHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUfv1U IDpaQBgx9HOFgy8jgA6oWikwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmPLzeghMUwDQYJ KoZIhvcNAQEFBQADggEBAMe3Au36OVIuXcODCOye1r9cPdvyy7DzQuGqJEP3JPt06c+WEMzH mtJK2rb879X03wOsHxP4QyQxhiplQUkpw/9nx895PHZhOGm7gagpDuIu9UeFC6Pxn64i0iQV phyxUYtY0veDDLXngYbZpgTuD96ljonB1hRlZqopndrY3J/lIk5zqEei31Di5SslYhT2jsEw bQ+vhNtdo7+1Jpzj/movT5zvkD6gdBuwQqHG6oaLaoPECYOpvN8UW0Xy7J1mX/S3+G86HF2R 4xhNzl2LOnnsXhLPkOwucZVzy/G7c764T9OAdnB5djgd/u9afP11wkHjVIOxu8DFlF9oiRGf lx4wggYJMIIE8aADAgECAgIBGTANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJJVDEeMBwG A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMDMxMDcwMDAwWhcNMDMxMjMx MDkwMDAwWjB8MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5v MTEwLwYDVQQLEyhEaXBhcnRpbWVudG8gZGkgQXV0b21hdGljYSBlIEluZm9ybWF0aWNhMRow GAYDVQQDExFDb3JyYWRvICBEZXJlbmFsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKPVKrbsLWj5jEh3nnuAz4tn4kQm0lAht9o5QGHgKqF78d6wcHw1h6Gb70p+97GJR6bW x3UKafzNDdUZAkg0BjMUr86F4ctxmKzOtzsv046X3vEdOYJ1Z+kOMfQhja+WZuUWVjqddimN owm/UOPpKxREhUoAej1Aa/1iZwjODaLb4a2AbHY5dSWsMNAPWA8nO9CIMPWahCdZ+YitxAPJ HL9x8gPjZADV2W89Jwrj5HAsP4sb2xpp3tPUxUw8cGXlwGbUuRbYaHwTJOlznyhOZIL/uqkl Bjoff5smd8SEtLJmyNwZRapQmsH0ayumGzYxiUQ2O7fYanKxX1cNRnMIj6MCAwEAAaOCAqow ggKmMIGVBglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8v d3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5v cmcvY2EvaXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZI AYb4QgEBBAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3Au ZXVyb3BraS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9j YS9pdC8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwu ZGVyMAwGA1UdEwEB/wQCMAAwNQYDVR0RBC4wLIESZGVyZW5hbGVAcG9saXRvLml0oBYGCisG AQQBlWICAQGgCBYGMDA0MzE3MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMGCCsG AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw cy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0by5p dC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFH79VCA6WkAYMfRzhYMvI4AOqFop MB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IBAQDH twLt+jlSLl3Dgwjsnta/XD3b8suw80LhqiRD9yT7dOnPlhDMx5rSStq2/O/V9N8DrB8T+EMk MYYqZUFJKcP/Z8fPeTx2YThpu4GoKQ7iLvVHhQuj8Z+uItIkFaYcsVGLWNL3gwy154GG2aYE 7g/epY6JwdYUZWaqKZ3a2Nyf5SJOc6hHot9Q4uUrJWIU9o7BMG0Pr4TbXaO/tSac4/5qL0+c 75A+oHQbsEKhxuqGi2qDxAmDqbzfFFtF8uydZl/0t/hvOhxdkeMYTc5dizp57F4Sz5DsLnGV c8vxu3O+uE/TgHZweXY4Hf7vWnz9dcJB41SDsbvAxZRfaIkRn5ceMYICxTCCAsECAQEwazBl MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQD Ey1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgEZMAkG BSsOAwIaBQCgggEvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAzMDUzMDEzMTgzM1owIwYJKoZIhvcNAQkEMRYEFHCtD3YXdakJepxAkUhfHpjeJlTXMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYD VQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xp dGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgEZMA0GCSqGSIb3 DQEBAQUABIIBAJSds7qDuU3WCafwaCjHC9AobRL4dicbGM2wVn8x0/dkNST9p9Cz9QSmZ/Tm JLUtFRoMy8BA8GU04ilLBM9MRkj03Pb3vHcSRL+Qi5Oxgcm67HtCYTBQJe1tVIH+P8oD7k1s 30d/0eKRWkXargyr+nzvfOt/0iXhqaapM/bRo/wMQgdNa9i0vTCtVXCQI3jAT1DULLvnIgtg yn1bP8i4WLXBD3rg3obur5j2hFKDcIBWDzUdjMXLDYJGG+503r+q9rypv/Txr7bfsvehY4vf A4bPyxT9s99KdFEgNNUnU/V8/j3mUkTLeTJNB0YYpR0CjqAnTTuqUMVRZDZK9Gg9OiAAAAAA AAA= --------------ms020104090105060907060505-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 30 14:13:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19709 for ; Fri, 30 May 2003 14:13:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UICue25043 for sip-archive@odin.ietf.org; Fri, 30 May 2003 14:12:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UI6rB23894; Fri, 30 May 2003 14:06:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UI5AB23806 for ; Fri, 30 May 2003 14:05:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19261 for ; Fri, 30 May 2003 14:05:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LoDs-0007D2-00 for sip@ietf.org; Fri, 30 May 2003 14:03:25 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19LoDr-0007Cz-00 for sip@ietf.org; Fri, 30 May 2003 14:03:24 -0400 Received: from Natarajucl1127 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HFP004EIOSO9M@mta0.huawei.com> for sip@ietf.org; Sat, 31 May 2003 02:02:49 +0800 (CST) Date: Fri, 30 May 2003 23:34:12 +0530 From: "Nataraju A.B." To: sip@ietf.org Message-id: <007901c326d5$e0e4dad0$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <11FD90E74279C0489ECB6793F227C847E86159@idc1exc0002.corp.global.level3.com> <20030527180043.GA26339@ryker.org> Content-Transfer-Encoding: 7BIT Subject: [Sip] Why do we need 3-way handshake for INVITE transaction.... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello All, I have a doubt why do we really need 3-way handshaking for INVITE transacation. whereas most of the others employ 2-way handshaking (BYE/200, UPDATE/200...). According to my knowledge one of the reason could be offer-answer mechanism involved in INVITE transactions. Thanx in advance, Regards, -Nataraju A.B. Huawei Technologies Ind Pvt Ltd, Bangalore-560008, +98455.95744 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 30 15:09:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22865 for ; Fri, 30 May 2003 15:09:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UJ9CO29517 for sip-archive@odin.ietf.org; Fri, 30 May 2003 15:09:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJ6dB28565; Fri, 30 May 2003 15:06:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJ5qB28515 for ; Fri, 30 May 2003 15:05:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22348; Fri, 30 May 2003 15:05:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LpAc-0000DY-00; Fri, 30 May 2003 15:04:06 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19LpAb-0000DU-00; Fri, 30 May 2003 15:04:05 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 30 May 2003 14:00:51 UT Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... To: "Nataraju A.B." Cc: sip@ietf.org, sip-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: "Vishal Phirke" Date: Fri, 30 May 2003 15:03:53 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 05/30/2003 03:01:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Apart from offer-answer mechanism, INVITE transactions differ from other transactions in following ways: 1. They take more time and often an user intervention is required. 2. Invites can be forked. And if multiple destinations send 200 OK, you don't want to end up with multiple connections. Instead, 3-way handshake allows the decision of accepting one of them delayed till Ack is sent by the originator of the request. Hence, it is very important to do reliable handshake at the time of session establishment. -Vishal "Nataraju A.B." cc: Sent by: Subject: [Sip] Why do we need 3-way handshake for INVITE sip-admin@ietf.or transaction.... g 05/30/2003 02:04 PM Hello All, I have a doubt why do we really need 3-way handshaking for INVITE transacation. whereas most of the others employ 2-way handshaking (BYE/200, UPDATE/200...). According to my knowledge one of the reason could be offer-answer mechanism involved in INVITE transactions. Thanx in advance, Regards, -Nataraju A.B. Huawei Technologies Ind Pvt Ltd, Bangalore-560008, +98455.95744 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 mailnull@www1.ietf.org Fri May 30 15:21:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23956 for ; Fri, 30 May 2003 15:21:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UJKVI30165 for sip-archive@odin.ietf.org; Fri, 30 May 2003 15:20:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJHtB30001; Fri, 30 May 2003 15:17:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJGYB29908 for ; Fri, 30 May 2003 15:16:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23722; Fri, 30 May 2003 15:16:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LpL2-0000Ll-00; Fri, 30 May 2003 15:14:52 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19LpL1-0000Lc-00; Fri, 30 May 2003 15:14:52 -0400 Received: from Natarajucl1127 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HFP00D8NS4508@mta0.huawei.com>; Sat, 31 May 2003 03:14:31 +0800 (CST) Date: Sat, 31 May 2003 00:45:53 +0530 From: "Nataraju A.B." Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... To: Vishal Phirke Cc: sip@ietf.org, sip-admin@ietf.org Message-id: <000d01c326df$e4c760a0$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT vishal, does ur 2nd point mean that the SIP application might select one of the 'n' replies to the INVITE request (if it was not intenede for multi-party call). even in this case it is logical to derive that application will selecet the first response and reject the later 2xx responses OR will the application wait for some time before sending the ACK back to callee. Regards, -Nataraju A.B. ----- Original Message ----- From: "Vishal Phirke" To: "Nataraju A.B." Cc: ; Sent: Saturday, May 31, 2003 12:33 AM Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... > > Apart from offer-answer mechanism, INVITE transactions differ from other > transactions in following ways: > 1. They take more time and often an user intervention is required. > 2. Invites can be forked. And if multiple destinations send 200 OK, you > don't want to end up with multiple connections. Instead, 3-way handshake > allows the decision of accepting one of them delayed till Ack is sent by > the originator of the request. > Hence, it is very important to do reliable handshake at the time of session > establishment. > -Vishal > > > > "Nataraju A.B." > i.com> cc: > Sent by: Subject: [Sip] Why do we need 3-way handshake for INVITE > sip-admin@ietf.or transaction.... > g > > > 05/30/2003 02:04 > PM > > > > > > > Hello All, > > I have a doubt why do we really need 3-way handshaking for INVITE > transacation. > whereas most of the others employ 2-way handshaking (BYE/200, > UPDATE/200...). > > According to my knowledge one of the reason could be offer-answer mechanism > involved in INVITE transactions. > > Thanx in advance, > > Regards, > -Nataraju A.B. > Huawei Technologies Ind Pvt Ltd, > Bangalore-560008, > +98455.95744 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Fri May 30 16:02:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25532 for ; Fri, 30 May 2003 16:02:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UK1x732763 for sip-archive@odin.ietf.org; Fri, 30 May 2003 16:01:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJxSB32625; Fri, 30 May 2003 15:59:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJwfB32556 for ; Fri, 30 May 2003 15:58:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25385; Fri, 30 May 2003 15:58:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lpzn-0000oT-00; Fri, 30 May 2003 15:56:59 -0400 Received: from gateway.hns.com ([208.236.67.14]) by ietf-mx with esmtp (Exim 4.12) id 19Lpzm-0000oQ-00; Fri, 30 May 2003 15:56:58 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h4UJvLeY029758; Fri, 30 May 2003 15:57:22 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h4UJvFCM003327; Fri, 30 May 2003 15:57:16 -0400 (EDT) To: "Vishal Phirke" Cc: "Nataraju A.B." , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 30 May 2003 15:57:13 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 05/30/2003 03:55:18 PM, Serialize complete at 05/30/2003 03:55:18 PM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , On 05/30/2003 03:03:53 PM, "Vishal Phirke" wrote: > 2. Invites can be forked. And if multiple destinations send > 200 OK, you > don't want to end up with multiple connections. Instead, 3-way > handshake > allows the decision of accepting one of them delayed till Ack > is sent by > the originator of the request. > I dont think this is a valid reason for 3-way handshakes. By definition, all 200 OKs are proxied back. Its upto the caller UA to then send BYE/OK to callees that it does not want to talk to due to forking. Therefore, the ACK is sent to all of them and doesnt help in delaying the decision. regds arjun _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri May 30 16:14:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26008 for ; Fri, 30 May 2003 16:14:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UKEK101976 for sip-archive@odin.ietf.org; Fri, 30 May 2003 16:14:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKBeB01776; Fri, 30 May 2003 16:11:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UK9MB01617 for ; Fri, 30 May 2003 16:09:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25821 for ; Fri, 30 May 2003 16:09:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LqA7-0000vW-00 for sip@ietf.org; Fri, 30 May 2003 16:07:39 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19LqA7-0000vT-00 for sip@ietf.org; Fri, 30 May 2003 16:07:39 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 30 May 2003 15:04:25 UT Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: "Vishal Phirke" Date: Fri, 30 May 2003 16:07:28 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 05/30/2003 04:05:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Well...As per my understanding, the dialogs will be established as soon as UA receives 200 OK. The application will generally accept first 200 OK, sending ACK and will reject others by sending BYE. What I was trying to get to is sending an ACK will make sure that both parties know that the other party is ready for session. However, for other requests, which are within dialog, the end points already know that the other end point is ready to accept its requests. -Vishal "Nataraju A.B." i.com> cc: sip@ietf.org, sip-admin@ietf.org Sent by: Subject: Re: [Sip] Why do we need 3-way handshake for sip-admin@ietf.or INVITE transaction.... g 05/30/2003 03:15 PM vishal, does ur 2nd point mean that the SIP application might select one of the 'n' replies to the INVITE request (if it was not intenede for multi-party call). even in this case it is logical to derive that application will selecet the first response and reject the later 2xx responses OR will the application wait for some time before sending the ACK back to callee. Regards, -Nataraju A.B. ----- Original Message ----- From: "Vishal Phirke" To: "Nataraju A.B." Cc: ; Sent: Saturday, May 31, 2003 12:33 AM Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... > > Apart from offer-answer mechanism, INVITE transactions differ from other > transactions in following ways: > 1. They take more time and often an user intervention is required. > 2. Invites can be forked. And if multiple destinations send 200 OK, you > don't want to end up with multiple connections. Instead, 3-way handshake > allows the decision of accepting one of them delayed till Ack is sent by > the originator of the request. > Hence, it is very important to do reliable handshake at the time of session > establishment. > -Vishal > > > > "Nataraju A.B." > i.com> cc: > Sent by: Subject: [Sip] Why do we need 3-way handshake for INVITE > sip-admin@ietf.or transaction.... > g > > > 05/30/2003 02:04 > PM > > > > > > > Hello All, > > I have a doubt why do we really need 3-way handshaking for INVITE > transacation. > whereas most of the others employ 2-way handshaking (BYE/200, > UPDATE/200...). > > According to my knowledge one of the reason could be offer-answer mechanism > involved in INVITE transactions. > > Thanx in advance, > > Regards, > -Nataraju A.B. > Huawei Technologies Ind Pvt Ltd, > Bangalore-560008, > +98455.95744 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Fri May 30 16:25:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26447 for ; Fri, 30 May 2003 16:25:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UKOnJ02535 for sip-archive@odin.ietf.org; Fri, 30 May 2003 16:24:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKMPB02464; Fri, 30 May 2003 16:22:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKLWB02417 for ; Fri, 30 May 2003 16:21:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26251; Fri, 30 May 2003 16:21:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LqLt-00012C-00; Fri, 30 May 2003 16:19:49 -0400 Received: from [61.144.161.2] (helo=mta1.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19LqLs-00011R-00; Fri, 30 May 2003 16:19:49 -0400 Received: from Natarajucl1127 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0HFP002T0UYGHX@mta1.huawei.com>; Sat, 31 May 2003 04:15:54 +0800 (CST) Date: Sat, 31 May 2003 01:50:50 +0530 From: "Nataraju A.B." Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... To: Arjun Roychowdhury , Vishal Phirke Cc: sip@ietf.org, sip-admin@ietf.org, Sip-implementors@cs.columbia.edu Message-id: <006501c326e8$f7622b60$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: "Arjun Roychowdhury" To: "Vishal Phirke" Cc: "Nataraju A.B." ; ; Sent: Saturday, May 31, 2003 1:27 AM Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... > On 05/30/2003 03:03:53 PM, "Vishal Phirke" wrote: > > > 2. Invites can be forked. And if multiple destinations send > > 200 OK, you > > don't want to end up with multiple connections. Instead, 3-way > > handshake > > allows the decision of accepting one of them delayed till Ack > > is sent by > > the originator of the request. > > > > I dont think this is a valid reason for 3-way handshakes. By definition, > all 200 OKs are proxied back. Its upto the caller UA > to then send BYE/OK to callees that it does not want to talk to due to > forking. Therefore, the ACK is sent to all of them and doesnt > help in delaying the decision. [ABN] what could be the logic which the application might use to reject the responses, I mean which one out of 'n' 200-OK response for INVITE will be accepted and rest all will be rejected. The application only intended to contact the calle, but it does not have any information about the callee information (which one to select). will this be driven by a local policy ???? Regards, -Nataraju A.B. > > regds > arjun > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 mailnull@www1.ietf.org Fri May 30 18:21:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01627 for ; Fri, 30 May 2003 18:21:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UMLKb11950 for sip-archive@odin.ietf.org; Fri, 30 May 2003 18:21:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UMIcB11796; Fri, 30 May 2003 18:18:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UMFNB11635 for ; Fri, 30 May 2003 18:15:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01477; Fri, 30 May 2003 18:15:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ls81-00029o-00; Fri, 30 May 2003 18:13:37 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19Ls81-00029l-00; Fri, 30 May 2003 18:13:37 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 30 May 2003 17:10:24 UT Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... To: "Arjun Roychowdhury" Cc: "Nataraju A.B." , sip@ietf.org, sip-admin@ietf.org, X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: "Vishal Phirke" Date: Fri, 30 May 2003 18:13:24 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 05/30/2003 06:11:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think the problem with the forking is, when an INVITE is forked and you actually want to setup multiple calls. In such a case application will send INVITE without SDP body and each 200 OK will carry an offer in SDP to which application can respond via using ACK with separate media ports for each connection. If 3-way handshake is not supported, setting up multiple calls with one INVITE is not possible. -Vishal "Arjun Roychowdhury" To: "Vishal Phirke" , > sip@ietf.org, sip-admin@ietf.org Sent by: Subject: Re: [Sip] Why do we need 3-way handshake for sip-admin@ietf.or INVITE transaction.... g 05/30/2003 03:57 PM On 05/30/2003 03:03:53 PM, "Vishal Phirke" wrote: > 2. Invites can be forked. And if multiple destinations send > 200 OK, you > don't want to end up with multiple connections. Instead, 3-way > handshake > allows the decision of accepting one of them delayed till Ack > is sent by > the originator of the request. > I dont think this is a valid reason for 3-way handshakes. By definition, all 200 OKs are proxied back. Its upto the caller UA to then send BYE/OK to callees that it does not want to talk to due to forking. Therefore, the ACK is sent to all of them and doesnt help in delaying the decision. regds arjun _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 mailnull@www1.ietf.org Sat May 31 01:12:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11941 for ; Sat, 31 May 2003 01:12:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V5Bgu05296 for sip-archive@odin.ietf.org; Sat, 31 May 2003 01:11:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V59XB05229; Sat, 31 May 2003 01:09:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V580B05181 for ; Sat, 31 May 2003 01:08:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11893 for ; Sat, 31 May 2003 01:07:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyZL-0004zQ-00 for sip@ietf.org; Sat, 31 May 2003 01:06:15 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LyZK-0004zH-00 for sip@ietf.org; Sat, 31 May 2003 01:06:14 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V57RZE005147; Sat, 31 May 2003 01:07:28 -0400 (EDT) Message-ID: <3ED8388B.6000306@dynamicsoft.com> Date: Sat, 31 May 2003 01:07:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jos=E9_Soler_Lucas?= CC: "'sip@ietf.org'" Subject: Re: [Sip] Doubt about SIP Specific Event Notification behaviour References: <0FAFFBDC8353D211B00A00104B0CDCBF01C9F697@comsrv.com.dtu.dk> In-Reply-To: <0FAFFBDC8353D211B00A00104B0CDCBF01C9F697@comsrv.com.dtu.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h4V57RZE005147 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4V580B05182 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The spec doesnt call this out, since I have no idea why such a thing would happen. But the right thing to do is undoubtedly (c), have the server terminate the subscription by sending a NOTIFY with a terminated state. -Jonathan R. José Soler Lucas wrote: > Hi everyone, > > trying to imagine a service based on the SUBSCRIBE - NOTIFY methods of > SIP described in RFC 3265 I have came across a doubt that I was not able > to find a respose to through the different documents I have checked. > Could anyone out there please give me any hint on the matter?: > > Imagine I have a SIP client that subscribes to a certain event happening > in a server. The subscription is acepted and performs properly. After a > moment, while the subscription is still active, there is an internal > problem in the server that prevents further NOTIFYes towards the > subscribing client. The question is: > > a) Does the server send a 5xx message towards the client? or > b) Does the server send a NOTIFY with a "pending" status indicating a > temporal suspension of the subscription? or > c) Does the server send a NOTIFY with a "terminated" status forcing the > end of the subscription? > d) Should the server send rather [5xx] followed by > [NOTIFY(status=pending/terminated)]? > > If the answer is (a), what should the behavior of the client then be, to > assume the subscription as terminated? > > Thanks in advance for your help. > Best regards, > > josé > > -------------------------------------------- > José Soler Lucas, M.Sc.Telecom.E. > PhD Student > Networks Competence Area > Research Center COM (Communications, Optics and Materials) > Technical University of Denmark > Building 343, DK 2800 Kgs. Lyngby, Denmark. > Phone: +45 45 25 38 08 (direct) > Fax: +45 45 93 65 81 > E-mail: jsoler@com.dtu.dk > Web: http://www.com.dtu.dk/ > ---- > Cellular: +45 22 27 48 22 > -------------------------------------------- > > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat May 31 01:24:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12219 for ; Sat, 31 May 2003 01:24:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V5OIs05746 for sip-archive@odin.ietf.org; Sat, 31 May 2003 01:24:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5MCB05672; Sat, 31 May 2003 01:22:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5L0B05623 for ; Sat, 31 May 2003 01:21:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12167 for ; Sat, 31 May 2003 01:20:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lylv-00054G-00 for sip@ietf.org; Sat, 31 May 2003 01:19:15 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Lylu-00053R-00 for sip@ietf.org; Sat, 31 May 2003 01:19:14 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V5KSZE005150; Sat, 31 May 2003 01:20:29 -0400 (EDT) Message-ID: <3ED83B98.9010604@dynamicsoft.com> Date: Sat, 31 May 2003 01:20:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Kereliuk CC: "Wang, Jin-Gen" , sip@ietf.org Subject: Re: [Sip] a question on section 18.2.2 in RFC 3261 References: <11FD90E74279C0489ECB6793F227C847E86159@idc1exc0002.corp.global.level3.com> <20030527180043.GA26339@ryker.org> In-Reply-To: <20030527180043.GA26339@ryker.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The reason was simple - pretty much all protocols where you send a request on TCP expect a response on TCP under normal conditions (normal being, the connection still exists). Anything else is going to be more complicated for no gain. -Jonathan R. Ryan Kereliuk wrote: > On Tue, May 27, 2003 at 11:27:28AM -0600, Wang, Jin-Gen wrote: > >>Since the Via header has enough information (IP address + port + >>transport protocol) for an application to send back response messages, >>what is the design idea behind the above decision to request an >>application to send back responses using an existing connection if the >>connection is still open, other than (may be) optimization in >>implementation? In other words, from SIP protocol point of view, why is >>such request a MUST requirement? > > > There are a variety of reasons why this is good including traversal of > of NAT/PAT devices. I think the motivation for the text as written, > however, was to head off potential scaling and performance problems > associated with doubling the number of TCP/SCTP/TLS connections in use. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat May 31 01:28:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12315 for ; Sat, 31 May 2003 01:28:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V5SCf06019 for sip-archive@odin.ietf.org; Sat, 31 May 2003 01:28:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5Q9B05893; Sat, 31 May 2003 01:26:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5PLB05818 for ; Sat, 31 May 2003 01:25:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12237; Sat, 31 May 2003 01:25:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lyq8-00055h-00; Sat, 31 May 2003 01:23:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Lyq7-00055V-00; Sat, 31 May 2003 01:23:36 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V5O8ZE005154; Sat, 31 May 2003 01:24:08 -0400 (EDT) Message-ID: <3ED83C74.6060106@dynamicsoft.com> Date: Sat, 31 May 2003 01:24:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishal Phirke CC: Arjun Roychowdhury , "Nataraju A.B." , sip@ietf.org, sip-admin@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vishal Phirke wrote: > I think the problem with the forking is, when an INVITE is forked and you > actually want to setup multiple calls. > In such a case application will send INVITE without SDP body and each 200 > OK will carry an offer in SDP to which application can respond via using > ACK with separate media ports for each connection. If 3-way handshake is > not supported, setting up multiple calls with one INVITE is not possible. This is not the case. The INVITE can contain an offer, and if forked, you get multiple answers. The caller then gets media from multiple sources to the same port, which it can disambiguate using SSRC. If it wants to move each dialog to a different port, it can then do a re-invite if it wants to. The reason the three way handshake is needed has everything to do with the long delays in responding to an invite. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat May 31 02:02:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15708 for ; Sat, 31 May 2003 02:02:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V62Mb08423 for sip-archive@odin.ietf.org; Sat, 31 May 2003 02:02:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V60GB07768; Sat, 31 May 2003 02:00:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5xkB07706 for ; Sat, 31 May 2003 01:59:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12681 for ; Sat, 31 May 2003 01:59:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LzNR-0005DP-00 for sip@ietf.org; Sat, 31 May 2003 01:58:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LzNQ-0005D8-00 for sip@ietf.org; Sat, 31 May 2003 01:58:00 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V5x8ZE005171; Sat, 31 May 2003 01:59:09 -0400 (EDT) Message-ID: <3ED844A8.5040802@dynamicsoft.com> Date: Sat, 31 May 2003 01:59:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (LMF)" CC: Sanjay Sinha , sip@ietf.org Subject: Re: [Sip] Question on RFC 3263 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christer Holmberg (LMF) wrote: > Hi, > > >> Actually, before that even happens the client transaction will >> simply terminate at the UAC. See: >> >> http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-00.txt >> >> >> but in any case, the UAS shouldnt terminate the call just because >> the 18x never got a PRACK. > > > What if the UAS includes an SDP in the reliable 18x? Shall it > assume that the UAC will terminate the call if it doesn't receive > an SDP when it expect to do so? Why would the UAC expect an SDP? In any case, as I said genreally a call is not terminated because a 18x never gets a prack. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat May 31 09:46:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01630 for ; Sat, 31 May 2003 09:46:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4VDkNJ14904 for sip-archive@odin.ietf.org; Sat, 31 May 2003 09:46:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDfQB14771; Sat, 31 May 2003 09:41:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDdtB14686 for ; Sat, 31 May 2003 09:39:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01581 for ; Sat, 31 May 2003 09:39:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M6Yj-0007KI-00 for sip@ietf.org; Sat, 31 May 2003 09:38:09 -0400 Received: from web12206.mail.yahoo.com ([216.136.173.90]) by ietf-mx with smtp (Exim 4.12) id 19M6Yj-0007KF-00 for sip@ietf.org; Sat, 31 May 2003 09:38:09 -0400 Message-ID: <20030531133950.55308.qmail@web12206.mail.yahoo.com> Received: from [193.95.59.234] by web12206.mail.yahoo.com via HTTP; Sat, 31 May 2003 15:39:50 CEST Date: Sat, 31 May 2003 15:39:50 +0200 (CEST) From: =?iso-8859-1?q?hajer=20ferjani?= To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Question on rfc 3313 : sip extension for media authorization Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all and thanks for previous help , in section 7 of rfc 3313 it is said that "the use of media authorization makes it possible to control the usage of network resources". Isn't this possible by means of RSVP which carry enough information to identify flows and resources being used ? also, it seems to me that the integration of Qos admission control with call signaling brings additional session setup delay and additionnal messages exchange, since there is exchange of REQ/DEC messages within the phase of resource reservation by RSVP (refer to section 6. Examples)and authorization could by performed at this stage. Please clarify me. Is there something wrong or missing with my understanding ? any help appreciated. Great thanks and Regards. Hajer. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.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 mailnull@www1.ietf.org Sat May 31 09:57:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01883 for ; Sat, 31 May 2003 09:57:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4VDv0N15289 for sip-archive@odin.ietf.org; Sat, 31 May 2003 09:57:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDk7B14873; Sat, 31 May 2003 09:46:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDjKB14845 for ; Sat, 31 May 2003 09:45:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01597 for ; Sat, 31 May 2003 09:45:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M6dy-0007Ko-00 for sip@ietf.org; Sat, 31 May 2003 09:43:34 -0400 Received: from web12203.mail.yahoo.com ([216.136.173.87]) by ietf-mx with smtp (Exim 4.12) id 19M6dx-0007Kl-00 for sip@ietf.org; Sat, 31 May 2003 09:43:33 -0400 Message-ID: <20030531134515.49582.qmail@web12203.mail.yahoo.com> Received: from [193.95.59.234] by web12203.mail.yahoo.com via HTTP; Sat, 31 May 2003 15:45:15 CEST Date: Sat, 31 May 2003 15:45:15 +0200 (CEST) From: =?iso-8859-1?q?hajer=20ferjani?= To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] question on draft-sinnreich-sip-qos-osp-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, somebody knows what is the current state of draft-sinnreich-sip-qos-osp-01 ? Or if there's some further work on the linkage between call setup using sip and end-to-end Qos setup. thanks in advance. Hajer. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.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